[dev] CLI configuration format for the new SR-TE daemon with PCEP

[Sebastien Merle]

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.