> No, we're not talking about "conceptual" decapsulation. Well if you want to take what has been said here to 6man after holidays no one will stop you there.
But let's keep in mind that a lot of forwarding engines takes input from various sources and generate a complete outbound rewrite of the packet header from given offset. No one I know at data plane is playing with atomic bits or octets overrides in the packets. Leave alone that data plane does not even do full processing on entire packets normally. All it does is to copy packet header leaving the payload in fast local DRAM and just saving pointer to it. So literally if we agree that IPv6 packet can be encapsulated before it reaches final destination - what really happens at each segment endpoint if you zoom in is a decapsulation and encapsulation operation. Hence full compliance with all IPv6 specs. IETF drafts usually never go to that level of detail as they do not have to. Besides even what I just described above significantly differes in pipeline processing vs run-to-completion NPUs. So sure after Santa arrives we can argue about all of that for a long time. But IMHO it would be best if first we really all well understand what are we really after ... Cheers, Robert On Sat, Dec 21, 2019 at 8:22 PM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > 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
