Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> On Wed, 4 Mar 2020, 08:50 Robert Raszuk, <[e-mail]> 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 <[e-mail]>
>> wrote:
>>
>>> Hi Robert,
>>>
>>> On Wed, 4 Mar 2020, 07:11 Robert Raszuk, <[e-mail]> 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=
>>>> [e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>
>>>