Dear BESS, I have updated the draft adding a Juniper point of contact "Lili Wang" as co-author to the draft to support the vendor interoperability testing.
We now have a point of contact for Cisco & Juniper and soon to be added contact for Arista & Nokia-ALU. We have good news to report that at this time so far 3 out of 5 vendors Cisco, Juniper & Nokia/ALU do support the PE-CE eBGP RFC 5549 IPv6 next hop encoding to carry IPv4 NLRI. Appendix A <https://tools.ietf.org/html/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-07#appendix-A>. IPv4 NLRI IPv6 Next Hop Vendor Testing IPv4 NLRI with IPv6 Next Hop encoding is supported for all BGP peers both iBGP and eBGP. This section details the vendor support of RFC5549 <https://tools.ietf.org/html/rfc5549> "PE-RR iBGP", "PE- CE eBGP" using GUA (Global Unicast Address), Link Local (LL) peering and Quality Assurance lab testing. This drafts goal is to ensure that all features and functionality works with "eBGP PE-CE" use case single peer carrying both IPv4 NLRI and IPv6 NLRI and that the routing policy features are all still fully functionality do not change. A.1 <https://tools.ietf.org/html/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-07#appendix-A.1>. Router and Switch Vendors Support and Quality Assurance Engineering Lab Results. +-----------+------------+--------------+---------------+-----------+ | Vendor | PE-RR iBGP | PE-CE eBGP | PE-CE eBGP LL | QA Tested | | | | GUI | | | +-----------+------------+--------------+---------------+-----------+ | Cisco | *** | *** | | | | Juniper | *** | *** | | | | Nokia/ALU | *** | *** | | | | Arista | | | | | | Huawei | | | | | +-----------+------------+--------------+---------------+-----------+ Table 1: Vendor Support A.2 <https://tools.ietf.org/html/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-07#appendix-A.2>. Router and Switch Vendors Interoperability Lab Results. This section details the vendor interoperability testing and support of RFC5549 <https://tools.ietf.org/html/rfc5549> that all features and functionality works with "eBGP PE- CE" use case with having a single peer carrying both IPv4 NLRI and IPv6 NLRI and that the routing policy features are fully tested for quality assurance. +-----------+-------+---------+-----------+--------+--------+ | Vendor | Cisco | Juniper | Nokia/ALU | Arista | Huawei | +-----------+-------+---------+-----------+--------+--------+ | Cisco | | | | | | | Juniper | | | | | | | Nokia/ALU | | | | | | | Arista | | | | | | | Huawei | | | | | | +-----------+-------+---------+-----------+--------+--------+ Table 2: Vendor Interop **Motivation for the draft** This draft utilizes RFC 5549 next hop updated encoding draft update that is used today for 4to6 Softwire mesh framework PE-P RR next hop encoding for eBGP PE-CE peering where the IPv4 AFI 1/1 is stacked ontop of IPv6 AFI 2/1, thus eliminating the need for dual stacking PE-CE edge. As stated that RFC 5549 next hop encoding is predominantly used for PE-RR next hop encoding for SAFI's stacked on IPv6 peer including VPN-IPv4 1/128 and MVPN 1/129. This draft draws attention to the critical OPEX savings as well as ensuring that all vendors support RFC 5549 encoding for eBGP PE-CE IPv6 next hop encoding for IPv4 NLRI to ensure the next hop is encoded correctly per Stephane's updated RFC5549 draft which is almost ready for publication. We have confirmed with Stepahanie that the RFC 5549 next hop encoding updated draft works for any BGP peering carrying IPv4 NLRI over IPv6 next hop so is agnostic of BGP internal versus external peering. This draft ensures through vendor interoperability testing that the vendor consortium represented on the IETF supports RFC 5549 next hop encoding for this particular use case for carrying IPv4 NLRI over an IPv6 next hop in the PE-CE eBGP peering scenario. This use case is widespread across any and all operator networks service providers and enterprises for both "core" & "data center" and is relevant to any underlay IPv4, IPv6, MPLS, SR-MPLS, SRv6 as the PE-CE customer edge is the same, but now with this draft there is no longer dual stacked the edge which now can be "IPv6 Only". This use case with IPv4 elimination at the PE-CE edge helps tremendously with proliferation of IPv6 and makes the entire core / edge now 100% IPv6 transport that can carry both IPv4 & IPv6 payload service overlay label. This pushes IPv4 to the customer network only in the VPN overlay encapsulation layer and keeps the transport underlay layer IPv4 Free. With IPv4 address depletion issues with provisioning especially at large IXP NAPs, this draft has worldwide benefits for internet service providers so IPv4 can be 100% eliminated at the internet transport layer. Kind Regards Gyan ---------- Forwarded message --------- From: Mishra, Gyan S <[email protected]> Date: Thu, Nov 19, 2020 at 2:56 AM Subject: Fwd: [E] New Version Notification for draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-07.txt To: Hayabusanew <[email protected]> ---------- Forwarded message --------- From: <[email protected]> Date: Thu, Nov 19, 2020 at 2:54 AM Subject: [E] New Version Notification for draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-07.txt To: Gyan Mishra <[email protected]>, Mankamana Mishra < [email protected]>, Lili Wang <[email protected]>, Jeff Tantsura < [email protected]> A new version of I-D, draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-07.txt has been successfully submitted by Gyan Mishra and posted to the IETF repository. Name: draft-mishra-bess-ipv4nlri-ipv6nh-use-cases Revision: 07 Title: IPv4 NLRI with IPv6 Next Hop Use Cases Document date: 2020-11-18 Group: Individual Submission Pages: 17 URL: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D07.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=W0oJ8rJFiz621ORe1GObdWqIeTijDwQDa9ByheMqSvA&s=jt1W2yiaGfWhHIf6I5rm6DLL44V-rQMygyynxAnvf8E&e= Status: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases_&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=W0oJ8rJFiz621ORe1GObdWqIeTijDwQDa9ByheMqSvA&s=6-_A2hNMZvHUo0tMmDJvsXUX5EHD6CEOXrkgoJON1Ls&e= Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=W0oJ8rJFiz621ORe1GObdWqIeTijDwQDa9ByheMqSvA&s=8PnwO5MaRqlS_XtzWjin72EGMncU7jqA-Pid0P09Xzw&e= Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D07&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=W0oJ8rJFiz621ORe1GObdWqIeTijDwQDa9ByheMqSvA&s=6XlDgfGkJffgMEEzwu_7ZxYHr-nuQ9Y9ViStjF4j2lM&e= Diff: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D07&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=W0oJ8rJFiz621ORe1GObdWqIeTijDwQDa9ByheMqSvA&s=_k6cCp_jgaYhSmoqpIT5-EtLUiOg1owr5GGB4VrZygc&e= Abstract: As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport such as MPLS LDPv6, SR- MPLSv6 or SRv6, Multiprotocol BGP (MP-BGP)now plays an important role in the transition of the core from IPv4 to IPv6 being able to continue to support legacy IPv4, VPN-IPv4, and Multicast VPN IPv4 customers. This document describes the critical use case and OPEX savings of being able to leverage the MP-BGP capability exchange usage as a pure transport allowing both IPv4 and IPv6 to be carried over the same BGP TCP session. By doing so, allows for the elimination of Dual Stacking on the PE-CE connections making the peering IPv6-ONLY to now carry both IPv4 and IPv6 Network Layer Reachability Information (NLRI). This document now provides a solution for IXPs (Internet Exchange points) that are facing IPv4 address depletion at these peering points to use BGP-MP capability exchange defined in [RFC5549] to carry IPv4 (Network Layer Reachability Information) NLRI in an IPv6 next hop using the [RFC5565] softwire mesh framework. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect & SME* *Data Center Planning | Common Core | Development & Engineering Lab ServicesGlobal Technology Services | ITNUC* *O 240 970-6287M 301 502-134713101 Columbia Pike Rm 304-D*Silver Spring, MD 20904 *IETF & ISOC Member since 2015* https://www.ietf.org/ https://www.internetsociety.org/ -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
