Hi Mike, You are right that the SR Policy architecture draft does not talk about reverse SLs. But it also doesn't talk about bidirectional paths or aspects like the use of association objects for disjoint paths. At one point in time, some of us (WG members) were of the view that these aspects may be covered in the standards track draft but such topics were moved out to an informational draft draft-filsfils-spring-sr-policy-considerations as these were use-cases.
Specifically on the point of "reverse SL", I think that the term is misleading. The SLs in a given SR Policy are always ordered in the forward direction (head to tail). This is not being changed. That there is another SR Policy with an SL having a reverse order of segment is more of a path computation constraint. There is no change or update required for this to the SR Policy architecture. Today, we already have protocol mechanisms defined for various constraints and their use-cases - those again are not covered by the SR Policy architecture document (some are in the companion information document that we stopped updating at a point). In summary, there is nothing that I see in this new/proposed work that changes what we have in the SR Policy document. Whether we need to start a new document (not standards but informational in my view as this is a use-case), I leave it to the WG and chairs. My preference would be to incorporate such use-cases in the existing informational draft if the WG does want to take up this work. Thanks, Ketan On Sat, 13 Nov 2021 at 07:40, Mike Koldychev (mkoldych) <mkoldych= 40cisco....@dmarc.ietf.org> wrote: > 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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
