You are right Mark ... I fully admit I have no clue what so ever about "IPv6 being a virtual MAC layer in SR" nor " IPv6 being used as a virtual link layer".
I was only talking about MPLS on which topic I think I still have a little bit of remaining knowledge. Thx a lot, Robert On Tue, Mar 3, 2020 at 11:43 PM Mark Smith <markzzzsm...@gmail.com> wrote: > > > On Wed, 4 Mar 2020, 08:50 Robert Raszuk, <rob...@raszuk.net> wrote: > >> >> MPLS is not link layer. >> > > I did not say that. I described how MPLS uses link-layers. > > > It is Layer 2.5 if you really want to squeeze it to OSI. >> > >> Regardless of IPv4, IPv6 or MPLS MACs are replaced at each L3 hop >> > > IPv6 is your virtual MAC layer in SR. Then there is a MAC layer below that > IPv6 virtual MAC layer. > > You're not thinking about tunnels being virtual links and performing > link-layer operations on them in the context of the upper protocol - MPLS > or SR. > > > - but that has nothing to do with MPLS PHP. MPLS PHP is the result of LDP >> signalling implicit null label from adjacent LSR. >> >> And perhaps it may avoid unnecessary statements if you would read my >> entire note :) >> > > I did. > > You don't seem to fully understand the idea of IPv6 being used as a > virtual link layer, and then how an upper IPv6 layer should treat and > consider the lower IPv6 layers. > > Clue: the upper IPv6 layer should not be aware that there is an IPv6 "link > layer" below it. There is another link layer below the virtual lower IPv6 > link layer, and that is another clue - there isn't always just one one link > layer instance - tunnelling introduces more link-layers, stacked on top of > each other, and that isn't limited to two - you can tunnel inside a tunnel > inside a tunnel. That gets confusing and complicated however once you learn > how to think within a layer, ignoring the others momentarily, it then can > be coped with. > > You need to read and consider this Internet Draft. I wish it had existed > 20 years ago. > > IP Tunnels in the Internet Architecture > > > https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10 > > Regards, > Mark. > > > >> Best, >> R. >> >> >> >> >> >> On Tue, Mar 3, 2020 at 10:42 PM Mark Smith <markzzzsm...@gmail.com> >> wrote: >> >>> Hi Robert, >>> >>> On Wed, 4 Mar 2020, 07:11 Robert Raszuk, <rob...@raszuk.net> wrote: >>> >>>> Hi Ron, >>>> >>>> > MPLS PHP is a clear case of de-encapsulation. >>>> >>>> Purely looking at technical aspect that is not true at all. >>>> >>> >>> Ron is correct. >>> >>> >>> >>>> MPLS PHP does not remove label stack. MPLS PHP is just used to pop last >>>> label. After MPLS PHP packets continue with remaining label stack to the >>>> egress LSR (example L3VPN PE). >>>> >>> >>> When an MPLS packet is forwarded through an LSR, with any operation at >>> all performed on the label stack (including none), is the link layer header >>> (literally) preserved during that operation? >>> >>> If the ingress and egress LSR links are both Ethernet, does the LSR >>> ingress frame's SA and DA match the post LSR processing Ethernet frame's SA >>> and DA? >>> >>> If you believe they do, how can MPLS work going from an Ethernet link on >>> one side of an LSR to a PPP (or Frame Relay, etc.) on the other side? >>> Clearly an Ethernet frame can't travel over a PPP etc. link. >>> >>> At every MPLS LSR along the LSP the link layer frame is replaced, with >>> new SA and DA, even if the link layer encapsulation is the same. >>> >>> The label stack is carried from ingress to egress, possibility modified >>> by an operation such as pop. However the link layer encapsulation is never >>> carried "through" the LSR. >>> >>> PSP as described in SR NP is not the same as PHP in MPLS. >>> >>> Modelling this operation in RFC 8200 compliant IPv6, there would be >>> discrete and distinct IPv6 in IPv6 tunnels between each SR router in the SR >>> domain, and there would not be an Routing Headers in the outer tunnel IPv6 >>> packet. The EH chain ("stack") would be carried been discrete ingress and >>> egress IPv6 in IPv6 tunnels, possibly modified, however the ingress tunnel >>> outer header would be replaced at each SR router. >>> >>> These distinct tunnels between SR routers wouldn't necessarily have to >>> be preconfigured. If the SR routers are directly link layer attached, then >>> the outer tunnel header IPv6 addressing could be the mandatory interface >>> Link Local addresses - which IGPs are already using to identify and track >>> neighbours. >>> >>> For SR, there would have to be an EH that carries the SIDs list, however >>> it would be a Destination Options EH, not a routing header. It would be a >>> Destination Option because it is processed at the destination addesss of >>> the outer tunnel header. >>> >>> >>> Regards, >>> Mark. >>> >>> >>> >>>> > I don't think that you can compare MPLS PHP with SRv6 PSP >>>> >>>> But I agree with that. Both operations have very little in common from >>>> packet's standpoint or forwarding apect. Well maybe except "penultimate" >>>> word :) >>>> >>>> Kind regards, >>>> R. >>>> >>>> >>>> On Tue, Mar 3, 2020 at 8:30 PM Ron Bonica <rbonica= >>>> 40juniper....@dmarc.ietf.org> wrote: >>>> >>>>> Folks, >>>>> >>>>> I don't think that you can compare MPLS PHP with SRv6 PSP. MPLS PHP is >>>>> a clear case of de-encapsulation. We do that all the time. In SRv6 PSP, we >>>>> are removing something from the middle of a packet. That is quite a >>>>> different story. >>>>> >>>>> >>>>> Ron >>>>> >>>> _______________________________________________ >>>> 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
