Clarify configuration of bidirectional tunnels

[italobusi]

The when statement is not aligned with the definition of the bidirectional leaf in the tunnel list:

    leaf co-routed {
      when "/te:te/te:tunnels/te:tunnel/te:bidirectional = 'true'" {
        description
          "Applicable to bidirectional tunnels only.";
      }

    leaf bidirectional {
      type boolean;
      default "false";
      description
        "Indicates a bidirectional co-routed LSP.";
    }
  }

Initial discussion has lead to the conclusion that there is a need to clarify how the model supports the different typed of bidirectional tunnels

[italobusi]

2023-01-20 TE Call (Aihua, Igor, Italo, Xufeng)

Unidirectional tunnel:

• all primary and secondary paths are in one direction
• no primary-reverse and no secondary-reverse paths
• realized only by unidirectional LSPs

Bidirectional tunnels:

• all primary and secondary paths are bidirectional
  • path constraints in two directions
    • symmetric
    • asymmetric
  • path properties in two directions
    • symmetric (only if path constraints are symmetric)
    • asymmetric
• realized by:
  • bidirectional LSPs
    • symmetric bandwidth
    • asymmetric bandwidth (RFC 6387)
  • pairs of associated unidirectional LSPs (one in each direction)
    • co-routed
    • independently routed

Proposal:

1. redefine the bidirectional leaf to indicate whether the tunnel is bidirectional (true) or unidirectional (false)

2. define the co-routed leaf, to indicate whether the paths are co-routed or independently routed, only for the primary path (applicable to the primary path and all its secondary path candidates)

      +--rw co-routed        boolean (when bidirectional is true)

Bidirectional co-routed paths can be realized either by bidirectional LSPs or pairs of associated unidirectional LSPs. It is up to the server to decide.

Bidirectional independently routed paths can only be realized by pairs of associated unidirectional LSPs.

Unidirectional paths can only be realized by unidirectional LSPs.

Discussion to continue next week

[tsaad-dev]

2023-01-27 TE Call (Aihua, Igor, Italo, Pavan, Sergio, Tarek, Rakesh)

AI (team): to revisit next week to address new usecase that Italo describes:
- bidirectional path with asymetric properties
AI (Tarek): add non-associated in the description of bidirectional leaf.
AI (Tarek): moved co-routed to only primary and make it boolean (default false).

Unidirectional tunnel:

• all primary and secondary paths are in one direction
• no primary-reverse and no secondary-reverse paths
• realized only by unidirectional LSPs

bidirectional: false
(path)co-routed: false
no primary/secondary reverse paths.

Bidirectional tunnels:

• bidirectional co-routed LSP
• As-is:
  bidirectional: true

1. Associated bidirectional (co-routed - single-sided)

• As is:
  Tunnel-associations:
  Single-Sided Associated Bidirectional LSP (A)
  bidirectional: false
  Path:
  co-routed (primary): true

2. Associated bidirectional (non co-routed - single-sided)

• As is:
• 1 Tunnel entry in the controller tunnel list:
  Tunnel-associations:
  Single-Sided Associated Bidirectional LSP (A)
  bidirectional: false
  Path:
  co-routed (primary): false
  [TS]: Italo may be adding a new association type for 'any' associated bidirectional

3. Bidirectional non-associated (co-routed - single-sided)

• As is:
  Tunnel-associations:
  bidirectional: true
  Path:
  co-routed (primary): n/a

[italobusi]

• @italobusi check that the approach is working also when the TE tunnel model is used on the controller NBI to provide a network view

[italobusi]

• @italobusi check that the approach is working also when the TE tunnel model is used on the controller NBI to provide a network view

I have prepared few examples to check the current approach, considering the configuration/state at the controller NBI as well as the configuration/state at PE1 and PE2 routers:

unidir-bidir-tunnel-examples-00.json.txt

Legenda:

• tunnel-X is the configuration of a tunnel at the controller NBI
• tunnel-X-state is the state of a tunnel at the controller NBI
• tunnel-X-PE1/tunnel-X-PE2 is the configuration or the state of a tunnel at the PE1/PE2 routers

There are few issues but the approach seems working as long as RSVP-TE is used within the network.

I have some doubts about how to extend this approach when other mechanisms are used within the network such as static LSP configuration or SR path.

I have prepared few examples to check an alternative approach, considering the configuration/state at the controller NBI as well as the configuration/state at PE1 and PE2 routers:

unidir-bidir-tunnel-alternative-examples-00.json.txt

At the first glance, this approach seems not too much different than the previous one from PE1/PE2 perspective but it makes the controller NBI more generic and decoupled from the use of RSVP-TE within the network

[italobusi]

My understanding is that we have agreed to:

1. keep the current definition for the co-routed leaf;
2. change the description of the bidirectional leaf as follow:

OLD

te/ietf-te.yang

Lines 665 to 671 in 4c8ba4b

	leaf bidirectional {
	type boolean;
	default "false";
	description
	"Indicates a bidirectional co-routed LSP (non-associated
	LSP case).";
	}

NEW

     leaf bidirectional { 
       type boolean; 
       default "false"; 
       description 
         "Indicates a bidirectional tunnel."; 
     } 

Let's confirm the agreement next week

[italobusi]

Additional comments:

te/ietf-te.yang

Lines 1006 to 1007 in 4c8ba4b

	container primary-reverse-path {
	when "../../../te:bidirectional = 'false'";

I think that when statement should check that the bidirectional leaf is 'true'

NEW

 container primary-reverse-path { 
   when "../../../te:bidirectional = 'true'"; 

te/ietf-te.yang

Lines 1013 to 1014 in 4c8ba4b

	container candidate-secondary-reverse-paths {
	when "../../../../te:bidirectional = 'false'";

The when statement is always true given the when statement above

NEW

 container candidate-secondary-reverse-paths {