Hi SPRING WG,
During the PCE session there was a presentation about signaling per-SL (Segment
List) reverse paths, see
https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-03#section-4.5.
I received comments to bring this up in the SPRING WG.
In the simplest case, you have two SR Policies in opposite directions,
something like this:
SR policy POL1 <headend = PE1, endpoint = PE2>
Candidate-path CP1
SID-List = <ABC>
SR policy POL2 <headend = PE2, endpoint = PE1>
Candidate-path CP1
SID-List = <CBA>
Where <ABC> and <CBA> are two segment lists that can be considered "opposites"
of each other, maybe traversing the same links in reverse, or maybe just the
same nodes, etc.
However, if the SR Policies have multiple segment lists, it gets more
complicated:
SR policy POL1 <headend = PE1, endpoint = PE2>
Candidate-path CP1
SID-List = <ABC>
SID-List = <DEF>
SR policy POL2 <headend = PE2, endpoint = PE1>
Candidate-path CP1
SID-List = <CBA>
SID-List = <FED>
Where <ABC> and <CBA> are opposites, also <DEF> and <FED> are opposites.
REQ 1: It should be possible to express that multiple reverse SLs correspond to
the same forward SL. For example, if the forward SL is using Node Segment(s)
with ECMP and reverse SLs use Adjacency Segments to cover multiple ECMP paths
in reverse.
REQ 2: It should be possible to express that SL 1 is a reverse of SL 2, but SL
2 is *not* a reverse of SL 1. I.e., not mutually reverse.
REQ 3: Having a set of reverse SL(s) associated to every forward SL is useful
even if there is no actual SR Policy in the reverse direction. I.e., if there's
just a unidirectional "forward" SR Policy that needs to know the return paths
for each of its SLs.
Currently SR Policy Architecture does not talk about reverse SLs. I'm
requesting the WG to review the proposal and decide if we should standardize
this.
Thanks,
Mike.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
