CLI configuration format for the new SR-TE daemon with PCEP
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.
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@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@orange.com <mailto:olivier.dugeon@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.
+1 to Olivier’ comments.
On Nov 30, 2020, at 11:32 AM, <olivier.dugeon@orange.com> <olivier.dugeon@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@lists.frrouting.org <mailto:dev@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@orange.com <mailto:olivier.dugeon@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@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
participants (3)
-
Jeff Tantsura -
olivier.dugeon＠orange.com -
Sebastien Merle