+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) <z...@cisco.com> To:Huzhibo <huzh...@huawei.com>;Robert Raszuk <rras...@gmail.com>;Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> Cc:spring <spring@ietf.org>;6man <6...@ietf.org> 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<http://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 <ipv6-boun...@ietf.org> on behalf of Huzhibo <huzh...@huawei.com> Date: Saturday, September 7, 2019 at 12:58 AM To: Robert Raszuk <rras...@gmail.com>, Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> Cc: "spring@ietf.org" <spring@ietf.org>, "6...@ietf.org" <6...@ietf.org> 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:spring-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Friday, September 06, 2019 9:33 PM To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> Cc: spring@ietf.org; 6...@ietf.org 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=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>> 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 i...@ietf.org<mailto:i...@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
