<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">+1 to Olivier’ comments. <br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 30, 2020, at 11:32 AM, <<a href="mailto:olivier.dugeon@orange.com" class="">olivier.dugeon@orange.com</a>> <<a href="mailto:olivier.dugeon@orange.com" class="">olivier.dugeon@orange.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class=""><font face="Helvetica, Arial, sans-serif" class="">Hello Sebastien,</font></p><p class=""><font face="Helvetica, Arial, sans-serif" class="">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.</font></p><p class=""><font face="Helvetica, Arial, sans-serif" class="">So, instead of 'pcc
peer ...' why not using 'peer ...' directly and 'pce' instead of
'pce-peer' when describing the PCE characteristics ?</font></p><p class=""><font face="Helvetica, Arial, sans-serif" class="">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.</font></p><p class=""><font face="Helvetica, Arial, sans-serif" class="">Regards</font></p><p class=""><font face="Helvetica, Arial, sans-serif" class="">Olivier<br class="">
</font></p>
<div class="moz-cite-prefix">Le 18/11/2020 à 18:00, Sebastien Merle
a écrit :<br class="">
</div>
<blockquote type="cite" cite="mid:1f37668a-ca38-0aa7-ab97-324742af0226@netdef.org" class="">Hi,
<br class="">
<br class="">
I am writing on behalf of the developers behind the pull request
for the new
<br class="">
experimental daemon pathd. It adds segment routing traffic
engeneering policies
<br class="">
and an optional dynamic module for PCEP support to FRR.
<br class="">
<br class="">
During the review, the question of the CLI configuration format
was discussed,
<br class="">
and we wanted to submit the last proposal to be sure the community
was agreeing with it.
<br class="">
<br class="">
Here is a simple but artificially exhaustive example of pathd
configuration with
<br class="">
the pcep module enabled:
<br class="">
<br class="">
```
<br class="">
segment-routing
<br class="">
traffic-eng
<br class="">
segment-list SL1
<br class="">
index 10 mpls label 1111 nai node 1.1.1.1
<br class="">
index 20 mpls label 2222 nai node 2.2.2.2
<br class="">
!
<br class="">
policy color 4 endpoint 10.10.10.4
<br class="">
name r4
<br class="">
binding-sid 104
<br class="">
candidate-path preference 100 name exp41 explicit
segment-list SL1
<br class="">
candidate-path preference 200 name dyn41 dynamic
<br class="">
bandwidth 1234
<br class="">
affinity exclude-any 0x01
<br class="">
pcep metric bound abc 16
<br class="">
pcep required metric bnc 123
<br class="">
pcep objective-function mcp msn mll mrup
<br class="">
!
<br class="">
!
<br class="">
pcep
<br class="">
config-group COMMON
<br class="">
source-address ip 10.10.10.10
<br class="">
timer keep-alive 50
<br class="">
!
<br class="">
config-group CONF1
<br class="">
config-group COMMON
<br class="">
tcp-md5-auth SECRET
<br class="">
timer keep-alive 30
<br class="">
!
<br class="">
pce-peer PCE1
<br class="">
config-group COMMON
<br class="">
address ip 10.10.10.1
<br class="">
pce-initiated
<br class="">
!
<br class="">
pce-peer PCE2
<br class="">
config-group CONF1
<br class="">
address ip 10.10.10.2
<br class="">
msd 32
<br class="">
sr-draft07
<br class="">
!
<br class="">
pcc
<br class="">
peer PCE1 precedence 10
<br class="">
peer PCE2 precedence 20
<br class="">
!
<br class="">
!
<br class="">
!
<br class="">
!
<br class="">
```
<br class="">
<br class="">
Some explanation about why the configuration format was chosen:
<br class="">
<br class="">
* 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.
<br class="">
* `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`.
<br class="">
* The `pce-peer` are not defined under `pcc` for two reasons:
<br class="">
1. This works around using vtysh without transaction, where we
can't be sure when we have all the configuration to start the pcc.
<br class="">
2. The idea is to later support per-prefix selection of the
PCE:
<br class="">
<br class="">
```
<br class="">
pcc
<br class="">
peer PCE1 precedence 10
<br class="">
group GROUP1 priority 10
<br class="">
prefix 4.5.3.0/24
<br class="">
peer PCE2 precedence 10
<br class="">
peer PCE1 precedence 20
<br class="">
!
<br class="">
group GROUP2 priority 20
<br class="">
prefix 4.5.3.0/24
<br class="">
peer PCE3 precedence 10
<br class="">
peer PCE1 precedence 20
<br class="">
!
<br class="">
!
<br class="">
```
<br class="">
<br class="">
The list of possible commands that can be specified under
`config-group` and `pce-peer` is:
<br class="">
* `sr-draft07` (Enable backward compatibility with segment
routing draft07 PCEs)
<br class="">
* `pce-initiated` (Enable PCE-intitated LSP support)
<br class="">
* `tcp-md5-auth WORD`
<br class="">
* `address <ip A.B.C.D | ipv6 X:X::X:X> [port
(1024-65535)]`
<br class="">
* `source-address [ip A.B.C.D | ipv6 X:X::X:X] [port
(1024-65535)]`
<br class="">
* `config-group WORD`
<br class="">
* `timer [keep-alive (1-63)] [min-peer-keep-alive (1-255)]
[max-peer-keep-alive (1-255)] ...`
<br class="">
* `msd (1-32)`
<br class="">
<br class="">
Link to the pull request:
<a class="moz-txt-link-freetext" href="https://github.com/FRRouting/frr/pull/7351">https://github.com/FRRouting/frr/pull/7351</a>
<br class="">
<br class="">
Thank you very much for your feedback.
<br class="">
<br class="">
Regards,
<br class="">
Sebastien Merle.
<br class="">
<br class="">
<br class="">
_______________________________________________
<br class="">
dev mailing list
<br class="">
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
<br class="">
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a>
<br class="">
</blockquote>
<div class="moz-signature">-- <br class="">
<a style="text-decoration:none;" href="http://www.orange.com/" class=""> <span id="cid:part1.DB566B89.2959A7E1@orange.com"><small_logo.png></span>
</a><p style="line-height:10px;margin:0px" class=""> </p>
<span style="font-weight: bold; font-family: Arial, sans-serif; font-size: 10pt;" class=""> Olivier Dugeon<br class="">
</span> <span style="font-family: Arial, sans-serif; font-size: 10pt;" class=""> Orange Expert, Future
Networks <br class="">
Open Source Referent <br class="">
Orange/IMT/OLN/WTC/IEE/iTeQ<br class="">
</span><p style="line-height:20px;margin:0px" class=""> </p>
<span style="font-family: Arial, sans-serif; font-size: 10pt;" class=""> fixe : +33 2 96 07 28
80<br class="">
mobile : +33 6 82 90 37 85<br class="">
</span> <span style="margin:0px 0 20px 0;" class=""> <a style="margin:0px
0 20px 0;font-family:Arial,
sans-serif;font-size:10pt;color:#FF6600;text-decoration:none;" href="mailto:olivier.dugeon@orange.com" class="">olivier.dugeon@orange.com</a>
</span> </div>
<pre class="">_________________________________________________________________________________________________________________________
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.
</pre></div>
_______________________________________________<br class="">dev mailing list<br class=""><a href="mailto:dev@lists.frrouting.org" class="">dev@lists.frrouting.org</a><br class="">https://lists.frrouting.org/listinfo/dev<br class=""></div></blockquote></div><br class=""></body></html>