Dear BESS WG & Chairs I have updated the draft and it is close to being ready for WGLC planning for the fall timeframe as discussed when I presented at IETF 120 last week. Also some cleanup in the draft to make it more readable in preparation for WGLC. Awaiting testing completion by Cisco & Huawei. Also SRv6 Compression CSID Next SID endpoint flavor applicability testing by all vendors.
Updates: Removed RFC 8950 section- Added section for SRv6 Compression CSID Next SID flavor test cases- Updated Vendor list - removed Arista Testing update - Test 1-4 is now just Unicast SAFI 1 , Test 5-128 IP VPN Juniper & Nokia 100% completed- Cisco & Huawei - plan to completed in Fall timeframe Added section for Typed NLRI that are N/A for the draft & updated AFI/SAFI table for Typed NLRI being N/A · MCAST-VPN [RFC6514 <https://datatracker.ietf.org/doc/html/rfc6514>] · MCAST-VPLS [RFC7117 <https://datatracker.ietf.org/doc/html/rfc7117>] · EVPN [RFC7432 <https://datatracker.ietf.org/doc/html/rfc7432>] · BGP-LS [RFC7752 <https://datatracker.ietf.org/doc/html/rfc7752>] · CAR [Color-aware routing draft <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-10>] *When this draft was created we combined 3 drafts since the work all pertained to the same concept of the following:* *3 design concepts:* 1-IPv4 Only PE design - Single IPv4 peer carrying both IPV4 & IPv6 NLRI w/ IPv4 only interface(Optimized dual stacking) 2-IPv6 Only PE design - Single IPv6 peer carrying both IPV4 & IPv6 NLRI w/ IPv6 only interface(Optimized dual stacking) 3-IPv4 Only PE design - IPv4 next hop encoding proposed to use instead of using mix of ipv4 mapped ipv6 address for next hop and a variety of other encodings to now standardize to use IPv4 address as the next hop identical parity with simplicity to RFC 8950 IP4v4 NLRI over IPv6 next hop. The eventual goal of this draft once it progresses to RFC is to make this design an industry wide paradigm shift to using this new alternative dual stacking methodology for the two commonly used SAFI "Unicast" and "IP VPN" tested in detail with the 12 test cases and as vendors get comfortable with the proliferation of the IPv4 Only PE design & IPv6 Only PE design which both are applicable for "IPv4 core" or "IPv6 core" which is the beauty behind it and the tremendous CAPEX and OPEX savings, is that operators can go down the list of SAFIs supported by this solution in the table at the end of the draft and work with their vendors on additional testing and proliferation of any of the other SAFIs that are supported in the future. My Future plans are to publish an operations draft in RTGWG, GROW and SRv6OPS for this solution and as well present this work at Operator Groups worldwide. Original adopted draft: draft-ietf-bess-ipv6-only-pe-design-04 ! these 3 drafts were combined and all 3 are being replaced by 1. IPv6 ONLY PE design - single IPv6 peer to carry both IPv4 & IPv6 NLRI with IPv6 only interface draft-mishra-bess-ipv6-only-pe-design-all-safi-04-> IPR attached (BCP) 2. IPv4 ONLY PE design - single IPv6 peer to carry both IPv4 & IPv6 NLRI with IPv6 only interface draft-mishra-bess-ipv4-only-pe-design-all-safi-05--> IPR attached (Standards Track) This draft also has IANA allocation for IPv4 next hop encoding proposal for IPv4 address next hop 3. Original adopted draft draft-ietf-bess-ipv6-only-pe-design-04 -->IP4 -> IPR attached (BCP) New draft (Standards Track) *draft-ietf-bess-v4-v6-**pe**-all-safi* *IPv4-Only PE Design Next Hop Encoding Standardization:* - RFC 4798 (6PE) section 2 defines how the next hop should be encoded for IPv6 NLRI over an IPv4 next hop using IPv4 mapped IPv6 address ::FFFF:192.168.1.1. RFC 4659 BGP MPLS VPNs section 3.2.1.2 defines VPN SAFI next hop encoding of IPv4 mapped IPv6 address ::FFFF:192.168.1.1. - RFC 5549 and now updated by RFC 8950 defines the IPv6 next hop encoding to carry IPv4 NLRI over an IPv6 next hop. The IPv6 next hop encoding defined is not an IPv6 mapped IPv4 address. The IPv6 next hop encoding is 16/32 byte ( RFC 2545 – NH address = IPv6 address + Link Local address) for Unicast SAFI 1, Multicast SAFI 2 and BGP-LU SAFI 4, and 24/48 byte (RFC 2545 – NH address / IPv6 address + link local address) for VPN SAFI 128, MVPN SAFI 129. The IANA BGP Capability codepoint defined with RFC 5549 is value 5 for Extended Next hop encoding. - The industry implementation uses a mix of IPv4 mapped IPv6 address for IPv6 NLRI carried over an IPv4 address next hop and uses 4 byte field for IPv4 next hop address for Unicast SAFI 1, Multicast SAFI2 and BGP-LU SAFI 4, and 12 byte next hop field, 4 byte IPv4 address plus 8 byte RD (Route Distinguisher) set to 0 for VPN SAFI 128, MVPN SAFI 129. - This draft standardizes the encoding to use an IPv4 address next hop and uses 4 byte field for IPv4 next hop address for Unicast SAFI 1, Multicast SAFI2 and BGP-LU SAFI 4, and 12 byte next hop field, 4 byte IPv4 address plus 8 byte RD (Route Distinguisher) set to 0 for VPN SAFI 128, MVPN SAFI 129. - This draft standardizes that encoding to ensure interoperability with IANA BGP Capability codepoint allocation thus providing parity between the RFC 5549/RFC 8950 IPv6 next hop encoding where the next hop address follows the underlay core which is an IPv6 core and how the next hop here being an IPv6 address and not following the NLRI with IPv6 mapped IPv4 address. Now with this draft the next hop encoding follows the underlay core which is an IPv4 core and so now the next hop being an IPv4 address and not following the NLRI with an IPv4 mapped IPv6 address. So this parity between IPv4 next encoding and IPv6 next hop encoding savings in OPEX and operations troubleshooting as well as interoperability that all vendor implementations now use the same IPv4 next hop encoding is the reason the encoding must be standardized. - This IPv4 next hop encoding is applicable for IPv6 NLRI for both iBGP control plane (CP) peering as well as eBGP PE-CE, PE-PE in-line control / data plane (CP-DP) peering which is used for IPv4-Only PE design. - Completed research on vendors using IPv4 mapped IPv6 address versus IPv4 next hop and within the same vendor in many cases with the same SAFI I have even noticed a mix of both options in the RIB and FIB programming which this standardization to use IPv4 next hop will cleanup discrepancies even within the same vendor on the same platforms as well as all platforms across all vendors. IANA BGP Capability - New codepoint for IPv4 Next hop encoding https://www.iana.org/assignments/capability-codes/capability-codes.xhtml We will plan to have one of the 4 vendors add the IPv4 next hop encoding implemented prior to WGLC. Thank you Gyan ---------- Forwarded message --------- From: <internet-dra...@ietf.org> Date: Mon, Jul 29, 2024 at 2:11 AM Subject: [bess] I-D Action: draft-ietf-bess-v4-v6-pe-all-safi-01.txt To: <i-d-annou...@ietf.org> Cc: <bess@ietf.org> Internet-Draft draft-ietf-bess-v4-v6-pe-all-safi-01.txt is now available. It is a work item of the BGP Enabled ServiceS (BESS) WG of the IETF. Title: IPv4-Only and IPv6-Only PE Design DESIGN ALL SAFI Authors: Gyan Mishra Sudha Madhavi Adam Simpson Mankamana Mishra Jeff Tantsura Shuanglong Chen Name: draft-ietf-bess-v4-v6-pe-all-safi-01.txt Pages: 54 Dates: 2024-07-28 Abstract: As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP- BGP)now plays an important role in the transition of their Provider (P) core network as well as Provider Edge (PE) Inter-AS peering network from IPv4 to IPv6. Operators must have flexiblity to continue to support IPv4 customers when both the Core and Edge networks migrate to IPv6. As well as must be able to support IPv6 networks in cases where operators decide to remain on an IPv4 network or during transition. This document details the External BGP (eBGP) PE-PE Inter-AS and PE- CE Edge peering IPv4-Only PE design where both IPv4 and IPv6 all supported SAFI NLRI can be advertised over a single IPv4 peer and IPv6-Only PE Design where all supported SAFI NLRI can be advertised over a single IPv6 peer. This document also defines a new IPv4 BGP next hop encoding standard that uses an IPv4 address as the next hop and not an IPv4 mapped IPv6 address. This document also provides vendor specific test cases for the IPv4-Only peering design and IPv6-Only PE design as well as test results for the four major vendors stakeholders in the routing and switching indusrty, Cisco, Juniper, Nokia and Huawei. With the test results provided for the IPv6-Only Edge peering design, the goal is that all other vendors around the world that have not been tested will begin to adopt and implement the design. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-v4-v6-pe-all-safi/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-bess-v4-v6-pe-all-safi-01 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-v4-v6-pe-all-safi-01 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
