Re: Re: I-D Action: draft-smith-6man-in-flight-eh-insertion-harmful-00.txt

[li zhenqiang <[e-mail]>]

Agree. SRv6 is totally different from MPLS.
Since Gyan puts them together to do comparison, what I want to say is that encapsulating one more IPv6 outer header when needed if something like pushing one more MPLS label at the very top of the label stack in mechanism. However SRH insertion is definitely different from MPLS label stack push and SRH insertion doesn't comply with RFC8200.

One more concern in Gyan's example is PSP for SRv6. As mentioned in my previous mail , the benifits of PSP and USP are unclear, the behaviors of PSP and USP defined in srv6-network-programming draft may have problems.  In my understanding, only encapsulation and decapsulation of an outer IPv6 header are allowed. PSP and USP should be discussed further.

Best Regards,
Zhenqiang Li
________________________________
[e-mail]

From: Mark Smith<mailto:[e-mail]>
Date: 2019-10-14 15:13
To: li zhenqiang<mailto:[e-mail]>
CC: Gyan Mishra<mailto:[e-mail]>; 6man WG<mailto:[e-mail]>
Subject: Re: Re: I-D Action: draft-smith-6man-in-flight-eh-insertion-harmful-00.txt
On Mon, 14 Oct 2019 at 17:18, Mark Smith <[e-mail]> wrote:
>
>
>
> On Mon, 14 Oct 2019, 13:05 li zhenqiang, <[e-mail]> wrote:
>>
>> Hi Gyan,
>>
>> In my understanding, MPLS Label insertion is more like encapsulation, because the outer header is handled, one more label is added at the top. For SRv6 SRH insertion, the outer IPv6 header is still used, only destination address is updated when SRH is inserted.
>
>
>
> So the SA of this packet is now a lie.
>
>>
>> In your exmaple, if P2 performs SRv6 Ti-LFA by adding one more outer IPv6 header, this is similar to MPLS label insertion.
>
>
> There is no such thing as label insertion in MPLS.
>

To be more specific, when does this happen in MPLS to "insert" Label 2
(LB2): (LLF = Link Layer Frame)


[LLF SA:X, DA:Y] [MPLS LB1] [Payload]

<MPLS LSR processing>

[LLF SA:X, DA:Y] [MPLS LB2, LB1] [Payload]


Specifically note that the SA:X, DA:Y haven't changed.

This doesn't happen in MPLS. At each LSR, a new Link Layer Frame is
created and used upon egress. The SA and DA of that new LLF will be
different from the LSR ingress SA and DA. The SA of the new LLF will
be that of the current LSR, and the DA will be of the next LSR.

MPLS labels are not inserted into an existing LLF with the SA and DA
being left unchanged or the link-layer frame being entirely replaced,
even if if the ingress and egress interfaces are the same link-layer
type.

If that was the way MPLS worked, then it wouldn't be possible to have
an MPLS LSR with both an Ethernet interface and a Frame Relay
interface, because Ethernet frames can't travel across a Frame Relay
link or vice versa.

MPLS labels may be inserted into an existing set of labels within the
LSR, but they're never inserted into an existing Link-Layer frame that
is both received and then sent by that LSR.

Insertion of EHs into IPv6 packets is unprecedented in any protocol at
the network layer. It is not copying what has been done in before in
MPLS, so there is no similarity.


>>
>> Best Regards,
>> Zhenqiang Li
>> ________________________________
>> [e-mail]
>>
>>
>> From: Gyan Mishra
>> Date: 2019-10-14 00:03
>> To: Gyan Mishra
>> CC: 6man
>> Subject: Re: I-D Action: draft-smith-6man-in-flight-eh-insertion-harmful-00.txt
>>
>> Mark
>>
>> In tried to add this comment in-line but does not look like it came through.
>>
>> See below
>>
>> Comparing MPLS in flight label insertion to SRv6 in flight EH insertion below:
>>
>> We will use the Service Provider scenario for SRv6 to compare apples to apples use case since SRv6 has a much wider scope as it pertains to IPv6 data plane traffic engineering capabilities.
>>
>> Typical SP mpls core / SRv6 core with L3 VPN services CEs attached.
>>
>> So for both scenarios the the packet originates from the customer network.
>>
>> CE - customer edge originating packet
>> PE1 - ingress PE device performing label imposition or EH insertion for SRH header
>> P2 - LDP Remote LFA PLR node/path protection
>> Performs LDP tunneling to PQ node by inserting MPLS label for FRR link and node protection. For SRv6 Ti-LFA PLR node performs EH SRH header insertion for the “LFA” backup protected path during a link or node failure
>> P3 - PQ node tunnel for R-LFA
>> P4 - egress P performing MPLS PHP pop implicit null value 3 or SRv6 PSP SRH segment pop and removal of SRH EH header type 4
>> PE2 - egress PE label disposition of bottom of stack L3 VPN  labels for MPLS use case
>>
>> CE - PE1 - P1 - P2 - P3 - P4 - PE2 - CE
>>
>> So in both cases the MPLS LDP or SRv6 domain the MPLS PE does in flight label imposition similar to SRv6 on the same ingress PE SRv6 does in flight SRv6 EH SRH Routing header type 4 insertion.
>>
>> So in both cases the MPLS LDP or SRv6 domain the MPLS P2 “IP FRR PLR node”  does in flight label imposition similar to SRv6 on the same  P2 node SRv6 does in flight SRv6 EH SRH Routing header type 4 insertion as well for Ti-LFA 50ms FRR link and node protection.
>>
>> So basically both MPLS and SRv6 perform in flight insertion of a header mpls 4 byte shim for mpls scenario and SRv6 EH SRH Routing header type 4 influencing the packet.
>>
>> The major difference with mpls and why that in flight label insertion has never been an issue is that MPLS is considered “Layer 2 1/2” due to the label stack being placed between the L2 link layer header and the L3 header.  So impact to routing related to mpls shim not being removed or security implications don’t exist since in the mpls core you are not IP routing you are “label switching” so forwarding plane is at that “layer 2 1/2” swapping the local label with remote label along the LSP path to FEC destination.
>>
>> With SRv6 since the EH headers are all inserted after the IPv6 header and before the transport header their are MAJOR security implications with EH headers not being removed as the EH headers are part of the L3 routing functionality.
>>
>> One other major impact to EH insertion in flight with IPv6 is that SRv6 can be used ubiquitously in almost any scenario where traffic engineering is required.
>>
>> With mpls the downside but from a security perspective upside as why mpls label imposition insertion in flight is not impacting is that with mpls state has to be maintained hop by hop for mpls data plane forwarding plane with either LDP or TE topmost label so mpls forwarding plane due to this “mpls state” LFIB dependency cannot exist outside of the mpls domain the egress P must to a PHP or if Default implicit null mpls label value type 3 is used or explicit null where the label is preserved on the egress P and popped on the egress PE along with the entire label stack is popped “label disposition” so the egress PE on the PE-CE link can forward as native IP packet..
>>
>>
>> RFC R-LFA used with MPLS LDP IP FRR
>>
>> https://datatracker.ietf.org/doc/rfc7490/
>>
>> What I think needs to change and we need to discuss with Spring folks is on the PLR node doing the 2nd EH insertion for Ti-LFA  to achieve link and node protection 50ms failover they need to do another IPV6 header encapsulation.
>>
>> So the ingress PE in SRv6 domain would add the 1st outer layer IPv6 header but then on the Ti-LFA node now we would require from a 6MAN RFC 8200 a 2nd IPv6 encapsulation and the FRR steering would be done through the PQ node via the 2nd encapsulation and and the PQ node would remove the 2nd encapsulation which would contain the SRH Ti-LFA SID list for the traffic engineered path.
>>
>> In the Voyer draft addressing EH insertion we should also have them make a bore that Ti-LFA would not exist in every scenario using SRV6 due to the ubiquitous use cases of SRv6 so that 2nd encapsulation would only be required wherever the 2nd or I guess even 3rd or every time an EH SRH type 4 routing header is added for that matter a IPv6 encapsulation is required to satisfy IPv6.
>>
>> Regards
>>
>> Gyan
>>
>>
>> Sent from my iPhone
>>
>> On Oct 13, 2019, at 11:59 AM, Gyan Mishra <[e-mail]> wrote:
>>
>> Mark
>>
>> Few comments on the draft in-line and also comparison of MPLS label insertio=
>> n to SRV6 EH insertion.
>>
>> Sent from my iPhone
>>
>> On Oct 13, 2019, at 6:25 AM, Nick Hilliard <[e-mail]> wrote:
>>
>> =20
>>
>> Brian E Carpenter wrote on 13/10/2019 01:36:
>>
>> The packet is too dumb to know anything ;-). My question is how each
>>
>> node it traverses knows. Indeed, Mark's draft
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------