On 01-Mar-20 07:25, Robert Raszuk wrote: > Hi John, > > I respectfully will disagree with your assessment. > > Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of SRv6 > operation. If this would be deprecated, moved to historic or made illegal - > games over. But if this is still legal then ultimate destination for a packet > is what it listed in outer IPv6 header DA. That's pretty basic. Now what the > destination in the header will do with the packet is completely different > story. > > Reason #2 - "a node can’t be both the penultimate, and the ultimate, node." > Of course it can. You are looking flat ..
But I've been told by several people that this is not the use case. I believe the little diagram I sent yesterday is the use case. And the trick in the description of PSP is what I pointed out yesterday too: deleting the header when segments-left == 0 but the destination address is not yet set to the final one: https://mailarchive.ietf.org/arch/msg/spring/n46VuroVGvRurIgGNLZxFbAHvIo/ The thing is, it can be coded and I fully believe there is running code. Also, answering your question "what harm does it do?" I think the answer objectively is "none, unless you want to use AH". Making a packet smaller on the last hop cannot break PMTUD. So I think the text needs to admit the trick it's playing on RFC 8200. Then the IETF can choose whether to let that trick pass. Brian > If you look at different layers the same node is in fact acting in multiple > roles - I can easily count 3 but with TI-LFA it could be even more. > > The same node is ultimate destination for the outer header > in the same time > The same node is penultimate destination for SR path > in the same time > The same node is just regular IPv6 transit from the perspective of the > original non encapsulated packet > > Kind regards, > R. > > > > > > > > > > > On Sat, Feb 29, 2020 at 6:46 PM John Scudder <j...@juniper.net > <mailto:j...@juniper.net>> wrote: > > Robert, > > I think your comment (emphasis added): > >> we are dealing here with an *encapsulated* packet which _has as its >> ultimate destination_ SR node X. That SR node X is to perform or not PSP. > > Is wrong. It contradicts everything else that’s been said in the hundreds > of messages that have gone before, not to mention the plain language of > draft-ietf-spring-srv6-network-programming-10. The word “penultimate” itself > is enough to prove this: by definition a node can’t be both the penultimate, > and the ultimate, node. It’s a contradiction in terms, like saying 0 equals > 1. > > Now, if node X were to remove the RH /and perform the decapsulation/ that > would be a different story, but the whole point of PSP is that X removes the > RH and then sends the encapsulated packet on to Y which performs the > decapsulation. (This point was made in one of the other threads recently, but > I’ve lost track of by whom and which thread.) As far as I can tell, this > non-controversial behavior is described in 4.16.3 of the draft and referred > to as “USD”. > > —John > >> On Feb 29, 2020, at 6:06 AM, Robert Raszuk <rob...@raszuk.net >> <mailto:rob...@raszuk.net>> wrote: >> >> Dear Jinmei, >> >> Even if RFC8200 section 4 text would say: >> >> "Extension headers cannot be added to a packet after it has left its >> source node and extension headers cannot be removed from a packet until it >> has arrived at its ultimate destination". >> >> PSP would be still not be violating anything said in this sentence. >> Reason being is that we are dealing here with an *encapsulated* packet which >> has as its ultimate destination SR node X. That SR node X is to perform or >> not PSP. So it is still fully compliant with the specification. >> >> IMHO the only grey area as pointed by Brian is if RFC8200 section 4.4 >> really mandates you to look at segments_left before processing the packet or >> it is equally legal to look at that value after local processing occurs. >> Definition says: >> >> >> Segments Left 8-bit unsigned integer. Number of route >> segments remaining, i.e., number of explicitly >> listed intermediate nodes still to be visited >> before reaching the final destination. >> >> which to me really means that as long as you recognize given routing >> header type you can decrement this value and if zero remove it. >> >> Besides that is a minor detail - as NPG draft could be updated to say: >> >> S14.1. If (Segments Left Before Local Decrement == 1) { >> S14.2. Update the Next Header field in the preceding header to the >> Next Header value of the SRH >> S14.3. Decrease the IPv6 header Payload Length by the Hdr Ext Len >> value of the SRH >> S14.4. Remove the SRH from the IPv6 extension header chain >> S14.5. } >> >> Many thx, >> R. >> >> On Sat, Feb 29, 2020 at 2:28 AM 神明達哉 <jin...@wide.ad.jp >> <mailto:jin...@wide.ad.jp>> wrote: >> >> At Fri, 28 Feb 2020 07:54:28 +0000, >> "Xiejingrong (Jingrong)" <xiejingr...@huawei.com >> <mailto: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 >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org <mailto:spring@ietf.org> >> https://www.ietf.org/mailman/listinfo/spring >> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3UdazBorQ$> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> i...@ietf.org <mailto:i...@ietf.org> >> Administrative Requests: >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$ >> >> <https://urldefense.com/v3/__https://www..ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$> >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
