Thanks Joel. I have just posted a new version of the draft with those changes (rev15).
Cheers, Pablo. -----Original Message----- From: Joel M. Halpern <j...@joelhalpern.com> Sent: viernes, 27 de marzo de 2020 17:35 To: Pablo Camarillo (pcamaril) <pcama...@cisco.com> Cc: spring@ietf.org Subject: Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12 Thank you. That is good enough to proceed regarding my concern. Yours, Joel On 3/27/2020 12:24 PM, Pablo Camarillo (pcamaril) wrote: > Hi Joel, > > I think the following editorial change clarifies your point. Please let me > know. > > Thanks, > Pablo. > > > Diff: > ==== > > -> Section 4.16.1 PSP > .... > The PSP operation is deterministically controlled by the SR Source > Node. A PSP-flavored SID is used by the Source SR Node when it needs > to instruct the penultimate SR Segment Endpoint Node listed in the > SRH to remove the SRH from the IPv6 header. > > PSP allows, for example, for an egress PE to receive a packet with a > segment in the DA of the outer header without any need to process the > SRH. > <NEW>This is useful for example when the SRH contains too many SIDs > compared to the egress PE dataplane capability as advertised in the > IGP [§8.1]. In such case calculating an SRv6 policy to these nodes > needs to account for the availability of the PSP capability upstream > to these nodes.</NEW> > > SR Segment Endpoint Nodes receive the IPv6 packet with the > Destination Address field of the IPv6 Header equal to its SID > address. A penultimate SR Segment Endpoint Node is one that, as part > of the SID processing, copies the last SID from the SRH into the IPv6 > Destination Address and decrements Segments Left value from one to > zero. > .... > > -> Section 8.1 IGP > The End, End.T and End.X SIDs express topological behaviors and hence > are expected to be signaled in the IGP together with the flavors PSP, > USP and USD. > <OLD>The IGP also advertises the support for SRv6 capabilities of the > node.</OLD> <NEW>The IGP should also advertise the maximum SRv6 SID depth > (MSD) capability of the node for each type of SRv6 operation. In particular, > the SR source (e.g., H.Encaps), intermediate endpoint (e.g., End, End.X) and > final endpoint (e.g., End.DX4, End.DT6) behaviors. These capabilities are > factored in by an SR Source Node (or a controller) during the SR Policy > computation.</NEW> > ... > > > > -----Original Message----- > From: Joel Halpern Direct <jmh.dir...@joelhalpern.com> > Sent: martes, 17 de marzo de 2020 18:51 > To: Pablo Camarillo (pcamaril) <pcama...@cisco.com> > Cc: spring@ietf.org > Subject: Re: [spring] Question on > draft-ietf-spring-srv6-network-programming-12 > > Given that the requirement to be able to ignore the routing header predates > any of the SRv6 work, a natural reading would be that ignoring the header is > something the device can already do. In normal situations, the savings for > not doing a check that simple is very small. > > Having been told the cost was high, with no further explanation, I am > forced to assume the historical (unfortunate) behavior that made the > cost high. If that explanation is correct, then it has other > implications. If that is NOT the reason that the cost is high, please > state what the reason is for it having a high cost. We are asking > devices to support a special feature (PSP) to achieve the savings. We > owe it to folks to explain why we are asking for such a thing. (And > no, the fact that PSP is optional does not change things. If PSP > matters, then it matters. If it doesn't matter, then lets drop it.) > > Yours, > Joel > > On 3/17/2020 1:43 PM, Pablo Camarillo (pcamaril) wrote: >> Inline >> >> -----Original Message----- >> From: "Joel M. Halpern" <j...@joelhalpern.com> >> Date: Monday, 16 March 2020 at 20:23 >> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com> >> Cc: "spring@ietf.org" <spring@ietf.org> >> Subject: Re: [spring] Question on >> draft-ietf-spring-srv6-network-programming-12 >> >> The changes in section 4.16.1 do improve the clarity. >> >> Having said that, the text about motivating PSP reads: >> PSP allows, for example, for an egress PE to receive a packet >> with a segment in the DA of the outer header without any need to >> process the SRH. >> is a very weak and confusing explanation. Given that 8200 requires >> nodes to be able to ignore any routing header with SL=0, the text as >> written seems to be without benefit. >> >> Joel, how do you know whether you can ignore a routing header? >> I believe that the only option is for the router to process the routing >> header to check whether the Segments Left value is equal to zero. >> PSP avoids any routing header processing at the egress PE, as the quoted >> text above states. Hence the benefit. >> >> Thanks, >> Pablo. >> >> Yes, I have seen descriptions of >> the benefits from others on the list. But this text is not it. >> >> If indeed the benefit is a node where any extension header presence >> causes much slower processing (as was alluded to by other posters on >> the >> list) then it seems that should be acknowledged in the description. >> Doing something slowly is indeed still compliant to 8200. >> I have asked that we go a step further, and acknowledge that such nodes >> have other limitations and that if we are going to make allowance for >> them, we should call out those other issues as well. >> >> Yours, >> Joel >> >> On 3/16/2020 2:55 PM, Pablo Camarillo (pcamaril) wrote: >> > Hi Joel, >> > >> > Please check revision 13 of this document that clarifies the PSP >> section. >> > >> > About your last point: >> > For both SR-MPLS and SRv6, there are restrictions on the path to be >> used, in particular: >> > - the SR policy may only use SIDs instantiated on SR Endpoints. >> > - When computing the SR policy, there are additional restrictions to >> consider, such as the Maximum SID Depth (MSD) capability of nodes in the >> topology. (for SRv6, see section 4 of draft-ietf-lsr-isis-srv6-extensions). >> > >> > Regards, >> > Pablo. >> > >> > -----Original Message----- >> > From: "Joel M. Halpern" <j...@joelhalpern.com> >> > Date: Tuesday, 10 March 2020 at 19:26 >> > To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com> >> > Cc: "spring@ietf.org" <spring@ietf.org> >> > Subject: Re: [spring] Question on >> draft-ietf-spring-srv6-network-programming-12 >> > >> > Pablo, in your reply below you say that the text in 8200 is >> "crystal >> > clear". It requires an interesting lens to find something >> "crystal >> > clear" about which so many people have expressed so much >> disagreement. >> > While a lawyer may claim to a judge that text in a contract is >> crystal >> > clear, it is almost always hyperbole. That may be useful in >> other >> > contexts. It is not useful here. >> > >> > As far as I can tell, the text allows the interpretation that >> the PSP >> > protagonists have reached. It also allows other >> interpretations. In >> > the absence of clarity, I can not claim that PSP biolates 8200. >> But it >> > sure as heck is not "crystal clear". >> > >> > I also find the articulated use cases for PSP muddy. And as >> far as I >> > can tell, if the use cases are accurate, then there is a need >> for >> > greater clarity in the underlying drafts (NP because I do not >> want to >> > try call back the base SRH document) about the restrictions on >> paths >> > that can be used. >> > >> > Yours, >> > Joel >> > >> > On 3/10/2020 2:13 PM, Pablo Camarillo (pcamaril) wrote: >> > > Hi Chris, >> > > >> > > Thanks for going through the document. >> > > The behaviors 4.13 (End.B6.Encaps), 4.14 (End.B6.Encaps.Red) >> and 4.15 (End.BM) correspond to Binding SIDs [1]. >> > > >> > > As a result of 4.13 for example, the packet is encapsulated >> with a new IPv6 header and an SRH that contains the SR policy associated to >> the BSID. >> > > Once the new IPv6 header is pushed into the packet, the >> NET-PGM pseudocode passes this packet to the IPv6 module of the router for >> transmission. >> > > >> > > Normally the Upper-Layer Header should not be processed on a >> packet with a BSID, since you have just pushed an SR policy into the packet. >> > > That said, when the ultimate destination is BSID, then the >> Upper Layer Header processing is the same to End (4.1). >> > > >> > > Hope it clarifies. >> > > >> > > Thanks, >> > > Pablo. >> > > >> > > [1]. https://tools.ietf.org/html/rfc8402#section-5 >> > > >> > > >> > > -----Original Message----- >> > > From: spring <spring-boun...@ietf.org> on behalf of Christian >> Hopps <cho...@chopps.org> >> > > Date: Saturday, 7 March 2020 at 12:50 >> > > To: "spring@ietf.org" <spring@ietf.org> >> > > Cc: Christian Hopps <cho...@chopps.org> >> > > Subject: [spring] Question on >> draft-ietf-spring-srv6-network-programming-12 >> > > >> > > In sections 4.13, (implicitly in 4.14) and 4.15 a set of >> steps is indicated. As far as I can tell the processing of the IPv6 header >> chain in all cases is terminated. e.g., >> > > >> > > " >> > > When N receives a packet whose IPv6 DA is S and S is >> a local End.BM >> > > SID, does: >> > > >> > > S01. When an SRH is processed { >> > > S02. If (Segments Left == 0) { >> > > .... >> > > Interrupt packet processing and discard >> the packet. >> > > S04. } >> > > S05. If (IPv6 Hop Limit <= 1) { >> > > .... >> > > Interrupt packet processing and discard >> the packet. >> > > S07. } >> > > S09. If ((Last Entry > max_LE) or (Segments Left > >> (Last Entry+1)) { >> > > .... >> > > Interrupt packet processing and discard >> the packet. >> > > S11. } >> > > .... >> > > S15. Submit the packet to the MPLS engine for >> transmission to the >> > > topmost label. >> > > S16. } >> > > " >> > > >> > > The text then says: >> > > >> > > When processing the Upper-layer header of a packet >> matching a FIB >> > > entry locally instantiated as an SRv6 End.BM SID, >> process the packet >> > > as per Section 4.1.1. >> > > >> > > Why would I ever be processing the upper-layer header at >> this point? >> > > >> > > Thanks, >> > > Chris. >> > > _______________________________________________ >> > > 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 >> > > >> > >> > >> > >> >> _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
