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

[Gyan Mishra <[e-mail]>]

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