Path computation for bidirectional tunnels

[italobusi]

During the discussion of open issue #16 , it has been not clear how path computation should be used to compute paths for bidirectional tunnels.

Action Points (for IETF 102):

• [x] See https://github.com/ietf-mpls-yang/te/issues/25
• [x] @carloperocchio: Update the model to re-use the bidirectional Boolean added to the TE tunnel model: closed with pull request #51

Action Points (after IETF 102):

• [x] Pending discussion of open issue #31
• [x] Check with the TE tunnel model authors how reverse primary and secondary paths are modeled: see https://github.com/ietf-mpls-yang/te/issues/34
• [x] Update the model to report path properties of forward and backward directions of computed bidirectional paths (pending discussion with TE Tunnel authors)
• [x] Check with the TE tunnel model authors how to know if associated bidirectional tunnels are supported
• [x] Check with the TE tunnel model authors how co-routed associated bidirectional tunnels are supported
• [x] Further discussion about path computation for co-routed associated tunnels

[italobusi]

Summary of the discussion during the call on April 19, 2018 (Carlo, Francesco, Italo and Sergio):

To compute the path for a native bidirectional tunnel: one bidirectional path is requested and one bidirectional path is returned. The path computation needs to know that the path is bidirectional to validate that the path meets the path constraints in both directions.

To compute the path for a not co-routed associated bidirectional tunnel: two independent unidirectional paths are requested (one for the forward and one for the backward direction) and two unidirectional path are returned

To be further investigated whether it would be useful to provide some information about the fact that the two paths will be associated to check that the end-points support association

To compute the path for a co-routed associated bidirectional tunnel: one bidirectional path is requested and one bidirectional path is returned.

The client can calculate the two unidirectional paths to use during Tunnel setup from the returned bidirectional path.

To be further investigated whether it would be useful to provide some information about the fact that the two paths will be associated to check that the end-points support association

Summary:

• need to add a Boolean to indicate whether the path to be computed is unidirectional or bidirectional
• check if there is a need for another Boolean to indicate whether the path to be computed will be used in an associated bidirectional tunnel

Action: check with TE Tunnel authors/contributors if there are other means to discover whether the endpoints support or not association

[italobusi]

@efralaz : I have one doubt.

In case of associated co-routed tunnel, should we allow the client to specify different path constraints for the paths in the forward and backward direction in addition to the fact that the two paths should be co-routed?

[italobusi]

Summary of the discussion during the call on May 17, 2018 (Francesco, Italo and Sergio):

The Boolean to indicate whether the path to be computed is unidirectional or bidirectional can be the same as the one recently added to the TE Tunnel model (the issue https://github.com/ietf-mpls-yang/te/issues/25 has been closed)

We need to update the model to report the different path properties (e.g., metrics) between the forward and reverse path directions

Action (Italo): raise an open issue with the TE tunnel model about the way reverse primary and secondary paths are modelled

There is no need to indicate the unidirectional paths will be used with associated bidirectional tunnels. The TE Tunnel/Topology model should provide information about whether associated bidirectional tunnels can or cannot be setup.

It seems that the latest update of the TE tunnel model does not allow setting up co-routed associated tunnels.

Action: check with TE Tunnel authors

Need further discussion about path computation for co-routed associated tunnels

[italobusi]

Let's wait for the resolution of open issue #52 and re-evaluate whehter further changes are needed

[italobusi]

The changes in pull request #60 to address open issue #52 do not resolve this issue

Wait for the resolution of open issue #49 and re-evaluate whether further changes are needed

[italobusi]

Since option 2 has been adopted for protected paths, need to develop a new association also for bidirectional tunnels : https://github.com/rvilalta/ietf-te-path-computation/issues/49#issuecomment-477248271

[italobusi]

It has been clarified how the TE tunnel model can support bidirectional tunnels. The changes proposed in PR #70 would provide similar capabilities for the path computation RPC

The only pending open issue is how to return asymmetric path properties in case symmetric path constraints are configured: see OI #65