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

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

--

 

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

_________________________________________________________________________________________________________________________

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.