On 20-Dec-19 22:18, Robert Raszuk wrote: > Hi Brian, > > Right, but the language in the PSP sub-section does not talk about > decapsulation. > > > Sure as in a way there is no decapsulation there. This is Segment N-1 node > not Final Segment End node.
If there is no decapsulation and the words mean what they say, then there is certainly a violation of RFC 8200. That needs to be said *explicitly* in the text so that the community can decide what to do about it. > > Of course the other way to look at this would be to conceptually describe > this as decapsulation at *each* segment end point and on most just copy the > SRH to a new IPv6 header and on PSP happening on Segment N-1 to not copy it. No, we're not talking about "conceptual" decapsulation. If a packet addressed to address A contains a packet addressed to address B, it isn't going to get to B unless A physically decapsulates it. (Since we're in a state where Segments Left == 0, we're already at the end of the segment list in the RH, so I don't see where Segment N-1 comes in.) Where are the diagrams showing example packets to illustrate exactly what happens during PSP? > > I think the root problem may be using the word "pop", which is relevant > in the MPLS label stack context but not here, without additional definition. > > > Well I agree. "POP" does not sound like the best terminology choice here for > SRH removal or deletion :). Now all what is needed for WG to convince Pablo > for massive editing .... Yes, but that is precisely because MPLS is designed to support a label stack with pushing and popping, and IPv6 is not designed that way. So "pop" really is completely false terminology when referring to an IPv6 header. If the explanation was that the original packet is fully decapsulated at the PSP node, so that the SRH disappears along with the rest of the encapsulating header, we wouldn't be having this conversation. > Happy Holidays, Indeed! Brian _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
