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

[Mark Smith <[e-mail]>]

On Wed, 4 Mar 2020, 09:59 Robert Raszuk, <[e-mail]> 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 <[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
>>>>>
>>>>