Les and Peter, I have also been pursuing the approach you suggest.
The following request to clarify draft-ietf-spring-segment-routing-09 on this topic was sent on Aug. 3rd. https://www.ietf.org/mail-archive/web/spring/current/msg02273.html Hopefully, we can get closure on these clarifications soon. Thanks, Chris -----Original Message----- From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Thursday, August 25, 2016 9:32 AM To: Peter Psenak (ppsenak) <[email protected]>; Chris Bowers <[email protected]>; OSPF List <[email protected]> Subject: RE: [OSPF] OSPFv2 SR draft Chris/Peter - > -----Original Message----- > From: OSPF [mailto:[email protected]] On Behalf Of Peter Psenak > (ppsenak) > Sent: Thursday, August 25, 2016 1:45 AM > To: Chris Bowers; OSPF List > Subject: Re: [OSPF] OSPFv2 SR draft > > Hi Chris, > > On 24/08/16 20:31 , Chris Bowers wrote: > > Peter, > > > > The text that you propose corresponds to part of the text that I > > proposed, > and it seems good to me. > > > > However, the last sentence of the text that I proposed in not addressed. > > ------ > > If router B does not advertise the > > SR-Algorithm TLV for algorithm X, then other routers should not > > forward traffic destined for a prefix-SID for algorithm X advertised > > by some router D using a path that would require router B to forward > > traffic using algorithm X. > > ------ > > Is this an oversight? > > not that I disagree with the statement that you want to add. > > The question is whether that belongs to the IGP SR draft, or whether > that should be specified in a different draft. > > There is already some text regarding the forwarding for a SR algorithm > in draft-ietf-spring-segment-routing section 3.2.1., which may not be > aligned with what you have in mind: > > "The ingress node of an SR domain validates that the path to a prefix, > advertised with a given algorithm, includes nodes all supporting the > advertised algorithm. In other words, when computing paths for a > given algorithm, the transit nodes MUST compute the algorithm X on > the IGP topology, regardless of the support of the algorithm X by the > nodes in that topology. As a consequence, if a node on the path does > not support algorithm X, the IGP-Prefix segment will be interrupted > and will drop packet on that node. It's the responsibility of the > ingress node using a segment to check that all downstream nodes > support the algorithm of the segment." > > Maybe we should add/modify the text in > draft-ietf-spring-segment-routing section 3.2.1, rather then adding anything > to the OSPF/ISIS SR drafts. > [Les:] I strongly agree with this approach. If one wants to understand how the MPLS dataplane works with SR then the following documents are relevant: https://www.ietf.org/id/draft-ietf-spring-segment-routing-09.txt https://www.ietf.org/id/draft-ietf-spring-segment-routing-mpls-05.txt https://www.ietf.org/id/draft-ietf-spring-segment-routing-ldp-interop-04.txt References to these documents can be included in the IGP drafts - but we should not try to repurpose the IGP drafts to cover material which is covered far more completely in the above drafts. If you feel there is something which needs to be added/revised to any of the above drafts to more accurately explain algorithm specific forwarding please make the comment in the context of one of those drafts. Les > thanks, > Peter > > > > > Thanks, > > Chris > > > > > > -----Original Message----- > > From: Peter Psenak [mailto:[email protected]] > > Sent: Monday, August 22, 2016 2:32 AM > > To: Chris Bowers <[email protected]>; OSPF List <[email protected]> > > Subject: Re: [OSPF] OSPFv2 SR draft > > > > Chris, > > > > what about this to be added in the Section 3.1: > > > > > > "A router receiving a Prefix-SID (defined in section 5) from a > > remote node > and with an SR algorithm value that such remote node has not > advertised in the SR-Algorithm sub-TLV MUST ignore the Prefix-SID sub-TLV." > > > > thanks, > > Peter > > > > > > On 19/08/16 23:33 , Chris Bowers wrote: > >> Peter, > >> > >> Please share the updated text that you plan to use with the WG, > >> since this > is a reasonably significant clarification. > >> > >> Thanks, > >> Chris > >> > >> -----Original Message----- > >> From: Peter Psenak [mailto:[email protected]] > >> Sent: Tuesday, August 16, 2016 10:02 AM > >> To: Chris Bowers <[email protected]>; OSPF List <[email protected]> > >> Subject: Re: [OSPF] OSPFv2 SR draft > >> > >> Hi Chris, > >> > >> I'll update the draft along those lines. > >> > >> thanks, > >> Peter > >> > >> > >> On 16/08/16 16:02 , Chris Bowers wrote: > >>> Peter, > >>> > >>> I suggest changing the paragraph to read as below to make this clearer. > >>> > >>> ===== > >>> The SR-Algorithm Sub-TLV is optional. It MAY only be advertised > >>> once > >>> in the Router Information Opaque LSA. If the SID/Label Range TLV, > >>> as > >>> defined in Section 3.2, is advertised, then the SR-Algorithm TLV > >>> MUST > >>> also be advertised. If a router C advertises a Prefix-SID > >>> sub-TLV for > algorithm X > >>> but does not advertise the SR-Algorithm Sub-TLV with > >>> algorithm X, > then > >>> a router receiving that advertisement MUST ignore the Prefix-SID > >>> advertisement from router C. If router B does not advertise the > >>> SR-Algorithm TLV for algorithm X, then other routers should not > >>> forward traffic destined for a prefix-SID for algorithm X > >>> advertised by > >>> some router D using a path that would require router B to > >>> forward > traffic using > >>> algorithm X. > >>> ===== > >>> > >>> Thanks, > >>> Chris > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Peter Psenak [mailto:[email protected]] > >>> Sent: Monday, August 15, 2016 6:40 AM > >>> To: Chris Bowers <[email protected]>; OSPF List <[email protected]> > >>> Subject: Re: [OSPF] OSPFv2 SR draft > >>> > >>> Hi Chris, > >>> > >>> sorry for the delay, I was on PTO during last two weeks. > >>> Please see inline: > >>> > >>> On 03/08/16 16:45 , Chris Bowers wrote: > >>>> Peter, > >>>> > >>>> Taking a looking at the whole paragraph into this sentence was > >>>> added, I am not sure how to interpret it. > >>>> > >>>> The SR-Algorithm Sub-TLV is optional. It MAY only be > >>>> advertised > once > >>>> in the Router Information Opaque LSA. If the SID/Label > >>>> Range TLV, > as > >>>> defined in Section 3.2, is advertised, then the > >>>> SR-Algorithm TLV > MUST > >>>> also be advertised. If the SR-Algorithm TLV is not advertised by > >>>> the > >>>> node, such node is considered as not being segment routing > capable. > >>>> > >>>> Is this sentence intended to imply that if a router does not > >>>> advertise the SR-Algorithm TLV including algorithm X, then any > >>>> prefix-SIDs for algorithm X advertised by that router will be > >>>> ignored by > other routers? > >>> > >>> in OSPF we do not have the SR capability TLV. We use SR-Algorithm > >>> TLV for that purpose. So if a router does not advertise the > >>> SR-Algorithm TLV for algorithm X, other routers should not send > >>> any SR traffic using SIDs that were advertised for algorithm X. > >>> > >>> If the router does not advertise any SR Algorithm TLV, then the > >>> node is not SR capable and no SR traffic should be forwarded to such a > >>> node. > >>> > >>> thanks, > >>> Peter > >>> > >>> > >>>> > >>>> If this is the intention, then it would be better to state is > >>>> more > explicitly. > >>>> > >>>> If not, then the intended meaning should be clarified. > >>>> > >>>> Thanks, > >>>> Chris > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: OSPF [mailto:[email protected]] On Behalf Of Peter > >>>> Psenak > >>>> Sent: Friday, July 22, 2016 3:30 AM > >>>> To: OSPF List <[email protected]> > >>>> Subject: [OSPF] OSPFv2 SR draft > >>>> > >>>> Hi All, > >>>> > >>>> following text has been added in the latest revision of the > >>>> OSPFv2 SR draft, section 3.1. > >>>> > >>>> "If the SR-Algorithm TLV is not advertised by node, such node is > >>>> considered as not being segment routing capable." > >>>> > >>>> Please let us know if there are any concerns regarding this addition. > >>>> > >>>> thanks, > >>>> Peter > >>>> > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/ospf > >>>> . > >>>> > >>> > >>> . > >>> > >> > >> . > >> > > > > . > > > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
