Open italobusi opened 5 years ago
@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
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):
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):
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):
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
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.
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.
2020-06-19 TEAS Call: PHP
Add a uhp-incapable (empty) attribute for LTP.
MPLS-TP should not select LTPs which are uhp-incapable.
2020-06-19 TEAS Call
Agreed to follow option 2:
Update the MPLS-TE YANG models to allow supporting also MPLS-TP: