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

On Mon, 14 Oct 2019, 13:05 li zhenqiang, <li_zhenqiang@hotmail.com> 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.

> Best Regards,
> Zhenqiang Li
> ------------------------------
> li_zhenqiang@hotmail.com
>
>
> *From:* Gyan Mishra <hayabusagsm@gmail.com>
> *Date:* 2019-10-14 00:03
> *To:* Gyan Mishra <hayabusagsm@gmail.com>
> *CC:* 6man <ipv6@ietf.org>
> *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 <hayabusagsm@gmail.com> 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 <nick@foobar.org> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>