Hi Brian, you've said Also, answering your question "what harm does it do?" I think the answer objectively is "none, unless you want to use AH".
On the other thread Ron and I have pointed that PSP does have decremental effect on the ability to perform OAM, particularly performance monitoring, and the use of the O-bit proposed in draft-ietf-6man-spring-srv6-oam <https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-03>is questionable. Though these may not be veied as harmful consequences of PSP but they clearly, in my opinion, are benefitial either. Regards, Greg On Sat, Feb 29, 2020 at 11:25 AM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > 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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
