Add support for MPLS-TP

[italobusi]

Update the MPLS-TE YANG models to allow supporting also MPLS-TP:

• Develop a new MPLS-TE Topology YANG model supporting both generic MPLS-TE and MPLS-TP nodes/links
• Update MPLS-TE Tunnel YANG model to support the setup of both generic MPLS-TE and MPLS-TP Tunnels/LSPs

[italobusi]

@tsaad-dev , @xufengliu : Please check initial proposals and open issues on:

https://github.com/italobusi/te

Let's have a review of the proposal and open issues before creating a Pull Request

[italobusi]

I would like to make some progress on this issue.

One of the issue we discovered was the fact that some capabilities are not reported by IGP so it may be difficult to report them in the topology model.

The work-around could be to rely on some a-priori knowledge on whether the MPLS topologies are MPLS-TE or MPLS-TP.

My concern is that this work-around will not work in case MPLS-TE and MPLS-TP topologies co-existing in the same list, as show in this slide:

te-tp-topology-coexistence-00.pptx

IMHO, we can define the capabilities not reported by IGP as optional such that if not reported the behavior is implicitly MPLS-TE (as of today where these attributes are not present)

Bidirectional LSP

What about an attribute reporting the type of LSPs being supported (bits):

• unidirectional LSP
• bidirectional associated LSPs
• bidirectional co-routed LSPs
• native bidirectional LSPs

In future we may add p2mp LSPs bitmap

This attribute is optional: if not known, nothing is reported. MPLS-TE path computation may assume any type is supported (and discover that there are some restrictions when attempting to setup the LSP), while MPLS-TP may avoid these links/nodes.

Granularity: per-node? per-LTP? per-Link?

ECMP/Load-Balancing

Add an attribute like load-balancing-type (enum):

• per-flow
• per-LSP

Possible alternative: make it a bitmap?

If both flags are set, it means that it is possible to configure per-flow versus per-LSP load-balancing on each LSP.
If no flag is set, it means that there is no load-balancing on that link (e.g., no LAG).

Optional: if not known, nothing is reported. MPLS-TE path computation may ignore it while MPLS-TP path computation may avoid these links/nodes.

Granularity: per-node? per-LTP? per-Link?

PHP

Add an attribute like label-pop-type (bits):

• PHP
• UHP

If both flags are set, it means that it is possible to request the setup of an LSP requiring UHP.

Optional: if not known, nothing is reported. MPLS-TE path computation may ignore it while MPLS-TP path computation may avoid these links/nodes.

Granularity: per-node? per-LTP? per-Link?

GAL

Support for GAL seems more related to OAM so it might be worthwhile postponing this discussion to a later stage when MPLS-TP OAM is discussed

[italobusi]

2020-06-19 TEAS Call: Bidirectional LSP

LSPs can be either unidirectional or bidirectional only.
Associated, co-routed or not, are always two unidirectional LSPs associated by the tunnel.

Assumption: all bidirectional links can support bidirectional LSPs and all the links can support unidirectional LSPs and it is always possible to associated unidirectional LSPs as long as they belong to the same tunnel.

[italobusi]

2020-06-19 TEAS Call: ECMP/Load-Balancing

Add a load-balancing-type (enum) attribute for bundled links. Default: per-flow.

Need to augment both device and topology models.

[italobusi]

2020-06-19 TEAS Call: PHP

Add a uhp-incapable (empty) attribute for LTP.

MPLS-TP should not select LTPs which are uhp-incapable.

[italobusi]

2020-06-19 TEAS Call

Agreed to follow option 2: