Hi Jingrong,
Can you help provide some clarification on the use cases for PSP flavor with end.X and end.T functions. Under Ref1 where it mentions end.X and end.T functions to use PSP knob as well if desired. How would that work with any P node using the PSP function? https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21 4.21.1 <https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21.1>. PSP: Penultimate Segment Pop of the SRH After the instruction 'update the IPv6 DA with SRH[SL]' is executed, the following instructions must be added: 1. IF updated SL = 0 & PSP is TRUE 2. pop the top SRH ;; Ref1 Ref1: The received SRH had SL=1. When the last SID is written in the DA, the End, End.X and End.T functions with the PSP flavour pop the first (top-most) SRH. Subsequent stacked SRH's may be present but are not processed as part of the function. Also trying to understand the reason given for PSP function for legacy final destination egress PE not being SRv6 capable. Since every PE in an SR domain both SRv6 or SR-MPLS identical to MPLS would be both a SR source node and final destination node of an LSP. I am using the MPLS term LSP with SR as the concept of FEC destination which now is a prefix SID still exists that all traffic to egress final destination PE is forwarded to. Since LSPs built to FEC destination are uni directional as they are with MPLS and that would be the case as well for SR paths - the idea that the final destination PE would lack hardware capability for SRH processing does not make sense as the source and final destination node are one and the same. Am I missing something? Kind Regards Gyan On Fri, Feb 28, 2020 at 9:14 PM Xiejingrong (Jingrong) < xiejingr...@huawei.com> wrote: > Got it. > Thanks for your clarification of your point. > > Jingrong > > -----Original Message----- > From: 神明達哉 [mailto:jin...@wide.ad.jp] > Sent: Saturday, February 29, 2020 9:28 AM > To: Xiejingrong (Jingrong) <xiejingr...@huawei.com> > Cc: Ted Lemon <mel...@fugue.com>; Pablo Camarillo (pcamaril) < > pcama...@cisco.com>; Brian E Carpenter <brian.e.carpen...@gmail.com>; Bob > Hinden <bob.hin...@gmail.com>; Joel M. Halpern <j...@joelhalpern.com>; > spring@ietf.org; 6...@ietf.org > Subject: Re: Suggest some text //RE: [spring] Request to close the LC and > move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming > > At Fri, 28 Feb 2020 07:54:28 +0000, > "Xiejingrong (Jingrong)" <xiejingr...@huawei.com> wrote: > > > The design of PSP for the benefits of deployment is based on the > > understanding that it does not violate section 4 of RFC8200. In case > > the RFC8200 text may be modified in the future, the PSP may also need to > change accordingly. > > No, it violates Section 4 of RFC8200. It's a pity that we have to discuss > it at this level due to the poor editorial work then (I was also > responsible for that as one of those reviewing the bis draft), but anyone > who involved the discussion should know the intent of this text intended to > say (borrowing from Ron's text) "Extension headers cannot be added to a > packet after it has left the its source node and extension headers cannot > be removed from a packet until it has arrived at its ultimate > destination". It might look "an attempt of blocking an innovation by a > small group of vocal fundamentalists", but if you see the responses without > a bias, you'd notice that even some of those who seem neutral about the > underlying SRv6 matter interpret the text that way. > > I'd also note that simply because PSP violates RFC8200 doesn't immediately > mean it (PSP) "needs to change". It can update RFC8200 with explaining why > it's necessary and justified. That's what I requested as you summarized: > > > Jinmei: it should say it updates this part of RFC8200 and explain why > it's justified. > > And, since PSP at least wouldn't break PMTUD, I guess the update proposal > will have much more chance to be accepted than a proposal including EH > insertion. On the other hand, pretending there's no violation will > certainly trigger many appeals and objections at the IETF last call (I'll > certainly object to it). In the end, it can easily take much longer, or > even fail, than formally claiming an update to RFC8200. > > -- > JINMEI, Tatuya > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mis...@verizon.com
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
