[dev] CLI configuration format for the new SR-TE daemon with PCEP
Jeff Tantsura
jefftant at gmail.com
Mon Nov 30 22:49:12 UTC 2020
+1 to Olivier’ comments.
> On Nov 30, 2020, at 11:32 AM, <olivier.dugeon at orange.com> <olivier.dugeon at orange.com> wrote:
>
> Hello Sebastien,
>
> After looking to Juniper and Cisco CLI for PCE, I found that Juniper used the "protocol pcep { pce <server_name> { destination-ipv4-address ... }" syntax, and Cisco used the "mpls-traffic pce peer ipv4 address ... " syntax for RSVP and "segment-routing pcc pce address ipv4... " for Segment Routing. Well, it is not because Cisco is using different syntax for the same purpose (certainly not the same developers) that we must do the same error.
>
> So, instead of 'pcc peer ...' why not using 'peer ...' directly and 'pce' instead of 'pce-peer' when describing the PCE characteristics ?
>
> Regarding the metric constraints, the 'pcep' tag sound strange for me. Indeed, the same constraints could be applied to a local computation without the need of the PCEP session. So,I would prefer to skip the 'pcep' tag and directly used the metric, objective-function ... tag for the syntax.
>
> Regards
>
> Olivier
>
> Le 18/11/2020 à 18:00, Sebastien Merle a écrit :
>> Hi,
>>
>> I am writing on behalf of the developers behind the pull request for the new
>> experimental daemon pathd. It adds segment routing traffic engeneering policies
>> and an optional dynamic module for PCEP support to FRR.
>>
>> During the review, the question of the CLI configuration format was discussed,
>> and we wanted to submit the last proposal to be sure the community was agreeing with it.
>>
>> Here is a simple but artificially exhaustive example of pathd configuration with
>> the pcep module enabled:
>>
>> ```
>> segment-routing
>> traffic-eng
>> segment-list SL1
>> index 10 mpls label 1111 nai node 1.1.1.1
>> index 20 mpls label 2222 nai node 2.2.2.2
>> !
>> policy color 4 endpoint 10.10.10.4
>> name r4
>> binding-sid 104
>> candidate-path preference 100 name exp41 explicit segment-list SL1
>> candidate-path preference 200 name dyn41 dynamic
>> bandwidth 1234
>> affinity exclude-any 0x01
>> pcep metric bound abc 16
>> pcep required metric bnc 123
>> pcep objective-function mcp msn mll mrup
>> !
>> !
>> pcep
>> config-group COMMON
>> source-address ip 10.10.10.10
>> timer keep-alive 50
>> !
>> config-group CONF1
>> config-group COMMON
>> tcp-md5-auth SECRET
>> timer keep-alive 30
>> !
>> pce-peer PCE1
>> config-group COMMON
>> address ip 10.10.10.1
>> pce-initiated
>> !
>> pce-peer PCE2
>> config-group CONF1
>> address ip 10.10.10.2
>> msd 32
>> sr-draft07
>> !
>> pcc
>> peer PCE1 precedence 10
>> peer PCE2 precedence 20
>> !
>> !
>> !
>> !
>> ```
>>
>> Some explanation about why the configuration format was chosen:
>>
>> * In the candidate path, the metric and objective function are prefixed with `pcep` because we didn't think this was generic enough for non-pcep candidate path.
>> * `config-group` is used to create a hierarchy of pcc/pce configuration so the common configuration does not have to be duplicated in every `pce-peer`.
>> * The `pce-peer` are not defined under `pcc` for two reasons:
>> 1. This works around using vtysh without transaction, where we can't be sure when we have all the configuration to start the pcc.
>> 2. The idea is to later support per-prefix selection of the PCE:
>>
>> ```
>> pcc
>> peer PCE1 precedence 10
>> group GROUP1 priority 10
>> prefix 4.5.3.0/24
>> peer PCE2 precedence 10
>> peer PCE1 precedence 20
>> !
>> group GROUP2 priority 20
>> prefix 4.5.3.0/24
>> peer PCE3 precedence 10
>> peer PCE1 precedence 20
>> !
>> !
>> ```
>>
>> The list of possible commands that can be specified under `config-group` and `pce-peer` is:
>> * `sr-draft07` (Enable backward compatibility with segment routing draft07 PCEs)
>> * `pce-initiated` (Enable PCE-intitated LSP support)
>> * `tcp-md5-auth WORD`
>> * `address <ip A.B.C.D | ipv6 X:X::X:X> [port (1024-65535)]`
>> * `source-address [ip A.B.C.D | ipv6 X:X::X:X] [port (1024-65535)]`
>> * `config-group WORD`
>> * `timer [keep-alive (1-63)] [min-peer-keep-alive (1-255)] [max-peer-keep-alive (1-255)] ...`
>> * `msd (1-32)`
>>
>> Link to the pull request: https://github.com/FRRouting/frr/pull/7351 <https://github.com/FRRouting/frr/pull/7351>
>>
>> Thank you very much for your feedback.
>>
>> Regards,
>> Sebastien Merle.
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev at lists.frrouting.org <mailto:dev at lists.frrouting.org>
>> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev>
> --
> <small_logo.png> <http://www.orange.com/>
>
> Olivier Dugeon
> Orange Expert, Future Networks
> Open Source Referent
> Orange/IMT/OLN/WTC/IEE/iTeQ
>
> fixe : +33 2 96 07 28 80
> mobile : +33 6 82 90 37 85
> olivier.dugeon at orange.com <mailto:olivier.dugeon at orange.com>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20201130/9c9d1a67/attachment-0001.htm>
More information about the dev
mailing list