[dev] CLI configuration format for the new SR-TE daemon with PCEP
olivier.dugeon at orange.com
olivier.dugeon at orange.com
Mon Nov 30 19:32:53 UTC 2020
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
>
> Thank you very much for your feedback.
>
> Regards,
> Sebastien Merle.
>
>
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev
--
Orange logo <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20201130/56760e1f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: small_logo.png
Type: image/png
Size: 219 bytes
Desc: not available
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20201130/56760e1f/attachment.png>
More information about the dev
mailing list