All Please review the following draft I had presented on the interim IETF 107. In this version I updated the abstract and introduction.
This draft defines and important use case used today for encoding IPV4 1/1 or VPN IPv4 1/128 MVPN 1/129 NLRI in an IPV6 Next hop defined in RFC 5549 draft update and RFC 5565 4to6 softwire mesh framework. In the previous older version of next hop encoding schema to carry IPV4 NLRI over IPV6 the encoding was IPv4 mapped IPv6 address which has been updated with next hop encoding to be an IPV6 address 16/32 bits for IP or 24/48 bits IP VPN with RD set to 0. So the idea with this draft is to use the same concept of next hop encoding used today to stack SAFI on the PE-RR peer on a 6to4 softwire mesh v4 over v6 core with v6 next hop encoding, to now be applied to edge PE-CE peering for brown or green field 4to6 softwire mesh core. So now with this concept in use cases of v4 to be carried over a v6 core we can now use the IPv6 peering as a pure transport at the PE-CE “edge” to carry both IPv4 1/1 and IPv6 2/1 NLRI over a single IPv6 next hop peer. This allows all enterprise and Service Providers to eliminate all IPv4 PE-CE edge peering from their core. This also helps pave the way as a stepping stone for IPv4 elimination and IPv6 only customers. This concept has tremendous OPEX savings for operators as IPv4 peers no longer need to be supported to customers. Along with saving on IPv4 /31 P2P peer PE-CE addressing and allocation. This concept does not require IPv4 and IPv6 congruency, and the policy for v4 and v6 can be different, however it is recommended that the BGP policy be same other then address family context related policy. I am planning to add a vendor support section that today support the next hop encoding and vendors that do not and a status on support. As this concept of mixed address families of one AFI being carried by another has been around for a long time. The caveat here from a vendor support standpoint is this is the PE-CE peer and not the core control plane PE-RR peer which is the focus of RFC 5549 which has been around for a long time. I have done some basic testing on this concept with various vendor platforms and it seems the next hop encoding is what seems to be missing, that it does not seem to be set correctly and may need coding update to get it to work. I am also planning to add a deployment recommendation section related to IPv4 and IPv6 congruency. Please provide feedback and any comments on the concept and or technical issues or gaps that I am not aware of with this concept. My goal of course is to garner interest in this draft concepts and hopefully consensus and fInally WG adoption. Kind Regards Gyan ---------- Forwarded message --------- From: Mishra, Gyan S <[email protected]> Date: Sun, Jul 12, 2020 at 5:46 AM Subject: Fwd: [E] New Version Notification for draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-01.txt To: gsm hayabusa <[email protected]> ---------- Forwarded message --------- From: <[email protected]> Date: Sun, Jul 12, 2020 at 5:37 AM Subject: [E] New Version Notification for draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-01.txt To: Gyan S. Mishra <[email protected]> A new version of I-D, draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-01.txt has been successfully submitted by Gyan Mishra and posted to the IETF repository. Name: draft-mishra-bess-ipv4nlri-ipv6nh-use-cases Revision: 01 Title: IPv4 NLRI with IPv6 Next Hop Use Cases Document date: 2020-07-12 Group: Individual Submission Pages: 15 URL: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D01.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=uLnT9-IwiocDgWwuxK_vXy03fLWyBgsUVRV28RXxUvs&s=xbA9oZ1wgaGJE5psj8VVjJLkfBgX5NO92sUrtlXV0xw&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=uLnT9-IwiocDgWwuxK_vXy03fLWyBgsUVRV28RXxUvs&s=A4KH1xsY5Z-SutF2OFjRZp4iiCFtrv-oOsIq_gHkyOQ&e= Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=uLnT9-IwiocDgWwuxK_vXy03fLWyBgsUVRV28RXxUvs&s=D6yh_XsRKkUBQqLrvTXA4c8fqMXDFMemLNM0Qk4bxb8&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=uLnT9-IwiocDgWwuxK_vXy03fLWyBgsUVRV28RXxUvs&s=UTzpTmrs9OKqxKQDpqALujDGqsQaFftJBFYELHozqHI&e= Diff: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=uLnT9-IwiocDgWwuxK_vXy03fLWyBgsUVRV28RXxUvs&s=idg9tUorRUzWlzJK-H-NIFGFM_43akEYJj6jkF2hcww&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. Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). Historically the AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 or VPN-IPv4 Network Layer Reachability Information (NLRI). [RFC5549] specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 Protocol. [RFC5549] defines the encoding of the Next Hop to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. With this new MP-BGP capability exchange allows the BGP peering session to act as a pure transport to allow the session to carry Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI) for both IPv4 and IPv6. 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 also provides a possible 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 <https://www.google.com/maps/search/13101+Columbia+Pike+Rm+304-D+Silver+Spring,+MD+20904?entry=gmail&source=g>*Silver Spring, MD 20904 <https://www.google.com/maps/search/13101+Columbia+Pike+Rm+304-D+Silver+Spring,+MD+20904?entry=gmail&source=g> *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
