Re: [spring] Regaining Focus on SRv6 and SRv6+

[Gyan Mishra <[e-mail]>]

Can someone give an example or use case of when SR insertion would be required by an intermediary node in an SRv6 domain?

Sometimes when dealing with complex subjects and discussions for me it makes sense to start with basics and work your way back up to reasons why decisions were made for a protocol or specifications.


So the main business justification and driver in the advent for SPRING WG and SR-MPLS for Service Providers is to be able to Traffic engineer and color L3 vpn flows natively without complexity that exists today with adding separate loopback for ibgp FEC destinations to provide per-vrf TE feature.  There maybe others but I believe that has always been the major pitfall with mpls.

So now with Spring WG SR-MPLS provides label stacking source route capabilities so L3 VPN’s can be naively TE’ed via FRR or Ti LFA 50ms fast reroute capability that was missing with MPLS.

Fast forwarding to SRv6 and what that provides via SRH IPv6 destination swapping in source routing native traffic engineering not only for new green field Service Provider MPLS core’s but for the internet as well as enterprises with now being able to extend the SRv6 domain ubiquitously to any part of the network from Data center to Access now having traffic engineering capabilities which is very powerful and is why SRv6 should be and is on the standards and not Experimental track.  SRv6 also with the inherent traffic engineering capabilities for any node on the network that can be part of the SRv6 domain really make IPv6 a must and more attractive and a bigger push I believe industry wide for all enterprises worldwide to migrate quickly to IPv6 so they can reap the benefits of SRv6.

Back to the SR insertion just thinking outside the box but from a use case standpoint where SR insertion would be beneficial an thinking maybe for TE tunnel stitching done LDP over TE for end to end targeted LDP session protection now with that same tunnel stitching using SRv6 if you had to stitch SRv6 tunnels together within an SR domain that would require SR insertion as any egress PE node along the path doing a USP or PSP would now have to be capable of performing SR insertion.

There maybe other critical use cases and that is why the Spring WG has the stance of SR insertion being mandatory.

I think when the SRv6 programming RFCs were written that violated the 6man WG RFC 8200 with EH only being allowed by the source node to insert EH and no other node when Spring WG decided to make this a requirement for SRv6 functionality they should have asked for 6man WG consensus approval and at that time RFC 8200 could have been updated to allow this one exception for EH for SR insertion by and node along the path.  Unfortunately this was not done that way from the beginning and now we are trying to fix what should have been fixed from the beginning.

Regards,

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/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

Sent from my iPhone

> On Sep 7, 2019, at 11:39 AM, Xiejingrong <[e-mail]> wrote:
> 
> +1.
> I didn't see the possibility of handling packets with EH in fast path without the indication of SRv6 SID in the preceding FIB lookup. This is uniquely introduced in SRH and SRv6 networking programming draft. 
> The only 'problem' rising on the list, the V6 TI LFA,  has been uniquely considered in the SRv6 for long, and has the encap scheme at the bottom line, if the EH insertion need some more tech discussion. 
> I didn't see any advantage or benefit of another v6 encapsulation for SR. 
> 
> Thanks
> Jingrong
> From:Zafar Ali (zali) <[e-mail]>
> To:Huzhibo <[e-mail]>;Robert Raszuk <[e-mail]>;Ron Bonica <rbonica=[e-mail]>
> Cc:spring <[e-mail]>;6man <[e-mail]>
> Date:2019-09-07 22:33:40
> SubjectRe: [spring] Regaining Focus on SRv6 and SRv6+
> 
> Hi, 
>  
> I agree on Huzhibo on his observation on SRv6 SIDs and their benefit for scaling, among other aspects he mentioned. 
>  
> CRH based solution, on the other hand, inherits all the characteristics of a “mapping table” based solution, including scaling. Here is a partial list:
>  
> MPLS over UDP Redone:
>  
> Many have pointed out that CRH does all this to achieve what can be achieved using already defined, adopted, and deployed specification. Like Dirk mentioned: "No need to re-invent MPLS over UDP using a different encapsulation inappropriately named "SRv6+".
> Please see:
> Comments from Dirk: https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM
> Many emails from Robert, including https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo
>  
> Need for new Routing Extension Header for SR:
>  
> Not to mention the need for defining a new routing extension header for Segment Routing. Where 6man working group has defined SRH: the work started in March 2014. The 6man WG spent a lot of efforts (1000s of email, dozens of document revision, dozens of IETF presentations, control plan work that is adopted by multiple workgroups, etc.). Not to mention - Implementation on 12 hardware platforms, including Merchant Silicon. Multiple providers have deployed the SRv6 network programming solution and its SRH encapsulation with line-rate performance carrying a significant amount of commercial traffic. Several independent public interoperability reports documenting successful interoperability of implementation from multiple vendors exist. In this regard, please also see Like Dan's email: https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4.
>  
> Need for Control Plane Extensions for all protocols:
>  
> All the routing protocols require extensions to carry the mapping table.
> Changes in BGP, ISIS, OSPF, BGP-LS, PCE, etc. and all control plan protocols are required. Some extension has been already proposed and were presented at IETF105. 
> Not to mention new extensions for manageability.
>  
> OAM:
>  
> We have already established on this mailing tread that MPLS like OAM tool kit is also needed for debuggability. 
> ICMP error processing does not work for CRH. 
>  
> Incomplete Solution/ TI-LFA:
>  
> The CRH solution is incomplete. E.g., it does not talk about TI-LFA and how protection works with O(50 msec) performance in this solution. 
>  
> Scaling:
>  
> Overall, CRH based solution does not scale in a large-scale network. 
> In a large-scale multi-domain interconnect, a seamless MPLS like solution is needed for the CRH to work. Specifically, the CRH suffers from the large label stack and protection/ convergence challenges.  
> CRH based solution will also impact the size of the FIB. It requires a SID to IPv6 address mapping table (not to mention lookup). This requires more memory and causes FIB scaling issues. Not to mention, the code complexity in an IP implementation. 
> Similar to FIB, RIB will need to introduce a new route table/entry type for ID mapping in case of CRH. That requires more memory and causes RIB scaling issues. Not to mention, the code complexity in an IP implementation. 
> Etc.
>  
> Performance:
>  
> I also agree with Cheng Li https://mailarchive.ietf.org/arch/msg/spring/XK0F40oEuZv-3ule-X5685d_6Mc, “I don’t think the performance of processing TLVs in DOH will be good, seems very complicated.” 
> I agree and to add the need for processing multiple extension headers.  
>  
> Ecosystem:
>  
> CRH has no ecosystem, no public proof of concept on hardware with linerate performance. SRv6 and SRH based implementation has a large ecosystem. The SRv6 ecosystem includes several open-source implementations: (Linux: Kernel and srext module, FD.io: VPP, Apps: Snort, iptables and nftables, tcpdump and Wireshark). All this took the industry over 5 years to get to that level of maturity and adoption. 
>  
> Summary:
>  
> In summary, nothing adds up; it makes no sense.
>  
> It will take more than hijacking an email thread for the authors of CRH to justify why 6man should define a new routing extension header for Segment Routing. 
>  
> Thanks
>  
> Regards … Zafar 
>  
> From: ipv6 <[e-mail]> on behalf of Huzhibo <[e-mail]>
> Date: Saturday, September 7, 2019 at 12:58 AM
> To: Robert Raszuk <[e-mail]>, Ron Bonica <rbonica=[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: RE: [spring] Regaining Focus on SRv6 and SRv6+
>  
> Hi Robert:
>  
> Agree with you.
> SRv6 is a completely different technology from SR MPLS. The biggest difference is that SRv6's Sid itself has routing capabilities. For example, it is aggregatable, it is programmable, it is globally unique over a larger scope. of. Sid's routing capabilities bring many benefits to the network. For example: network scalability, reliability, and simplified Overlay programming. So, I think that any optimization we do for SRv6 should not sacrifice Sid's own routing capabilities. If we just want to solve the interoperability problem between MPLS network and IP network, we can solve this problem in the field of SR MPLS.
>  
> Thank you,
> Zhibo
>  
> From: spring [mailto:[e-mail]] On Behalf Of Robert Raszuk
> Sent: Friday, September 06, 2019 9:33 PM
> To: Ron Bonica <rbonica=[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+
>  
> Dear Ron,
>  
> I think you forgot few main points in the summary: 
>  
> * Many operators use SR-MPLS successfully and it has been both standardized and successfully deployed in the network with interoperable implementations 
>  
> * The overhead on the data plane of SRv6+ is very comparable to overhead of SR-MPLS
>  
> * The control plane extensions BGP, IGP are available for SR-MPLS and non are available for SRv6+
>  
> * SRv6+ requires a new mapping of SIDs to prefixes to be distributed by control plane 
>  
> * If operators choose not to use MPLS transport SR-MPLS can be easily transported over IPv4 or IPv6 vanilla data plane
>  
> * Extensions for additional applications like L3VPNs or L2VPNs will require another set of protocol and implementation changes. 
>  
> * If there are vendors who do not want to provide SR-MPLS SID mapping to IPv6 addresses in their control planes let's focus standardization and industry work in this direction. 
>  
> With all of the above I think it would be a serious mistake - at this point of time - to continue work on SRv6+ in the IETF. 
>  
> Thank you,
> Robert.
>  
>  
> On Fri, Sep 6, 2019 at 3:08 PM Ron Bonica <rbonica=[e-mail]> wrote:
> Folks,
>  
> We have explored many facets of SRv6 and SRv6, sometime passionately. I think that this exploration is a good thing. In the words of Tolkien, “All who wander are not lost.”
>  
> But it may be time to refocus on the following:
>  
> For many operators, SRv6 is not deployable unless the problem of header length is addressed
> Many objections the uSID proposal remain unanswered
> SRv6+ offers an alternative solution
>  
> Given these three facts, I think that it would be a mistake to discontinue work on SRv6+.
>  
>                                                                                    Ron
>  
>  
> Juniper Business Use Only
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------