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

[Gyan Mishra <[e-mail]>]

On Sun, Oct 13, 2019 at 10:04 PM 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.
>
> In your exmaple, if P2 performs SRv6 Ti-LFA by adding one more outer IPv6
> header, this is similar to MPLS label insertion.
>

 [Gyan]. Yes Agreed that with MPLS it is essentially encapsulation as a 4
the byte MPLS shim is placed between the Layer 2 link layer and Layer 3 IP
header. Where with SRv6 it’s an EH header routing type 4 for SRHv6 being
added immediately following the IPv6 header.  How both are analogous is
from a data plane forwarding and routing domain perspective where we are
essentially taking the services labeled at the bottom of the mpls label
stack and swapping out the topmost label LDP / TE and replacing with IPv6
data plane where the ingress PE doing the label imposition is now SRV6
origin source device performing initial EH insertion SRH headers to traffic
engineer the customer flow. With the updated specification we are now doing
encapsulation at the ingress PE node to conform with RFC 8200 so it’s
actually more like MPLS.

>
> Best Regards,
> Zhenqiang Li
> ------------------------------
> [e-mail]
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Date:* 2019-10-14 00:03
> *To:* Gyan Mishra <[e-mail]>
> *CC:* 6man <[e-mail]>
> *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
>
> --

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant