On Wed, 4 Mar 2020, 09:59 Robert Raszuk, <rob...@raszuk.net> wrote: > > 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 didn't say you had no clue. Saying things like "MPLS is not link layer." suggests you think I have no clue, and that makes this conversation a waste of time. > 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
