All Below is draft that I presented at the end of the interim meeting today.
Sorry for the audio issues I had during the call. My apologies. We have for many years had 6to4 softwire tunneling of IPv6 NLRI over an IPv4 core. So now with new green filed & brown field deployments of v6 in the core we are seeing more 4to6 softwire tunneling of IPv4 NLRI over an IPv6 core MPLS LDPv6 or SRv6. So in the slides I presented with respect to the core side peering today with v4 core all your SAFIs 1/128 1/129 2/128 2/129 were over IPv4 PE-RR peer IPv4 NH or IPv6 mapped IPv4 but with IPv6 core the same SAFIs 1/128 1/129 2/128 2/129 are now over an IPv6 peer with IPv6 NH. The net-net change is nill as far as PE-RR core peering there so there is not any savings as for elimination of peering OPEX and IP addressing savings. The major gain with this draft is with the edge peering for both Service Providers & Enterprises where now with BGP being used a transport for both IPv4 & IPv6 AFI we can eliminate the IPv4 peering at the edges. This would as well eliminate dual stacking on the PE-CE customer connections so they are "IPv6 only" just as are our PE-RR peering is "IPv6 only". This would be inline with the RFC 5565 softwire framework of a single protocol core & edge. This would yield OPEX cost savings as well as resolve IPv4 addressing address depletion issues with IXP's or any network. Also a savings with NMS monitoring of IPv4 peering. I would like to poll all vendors regarding this concept as to support of this feature in the context of PE-CE "IPv4 peer elimination" and if the existing RFC 5549 encoding of IPv4 NLRI in IPv6 NH as an IPv6 address 16/32 byte for AFI 1/1 or 24/48 byte for AFI 1/128 is supported for adding IPv4 AFI 1/1 to IPv6 NH Peer so that the single protocol IPv6 peer would carry both IPv4 & IPv6 NLRI. Please provide any comments and feedback. Kind regards Gyan Cell - 202 734-1000 ---------- Forwarded message --------- From: Mishra, Gyan S <gyan.s.mis...@verizon.com> Date: Mon, Apr 27, 2020 at 6:37 PM Subject: Fwd: [E] New Version Notification for draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-00.txt To: Hayabusanew <hayabusa...@gmail.com> ---------- Forwarded message --------- From: <internet-dra...@ietf.org> Date: Mon, Apr 27, 2020 at 6:35 PM Subject: [E] New Version Notification for draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-00.txt To: Gyan S. Mishra <gyan.s.mis...@verizon.com> A new version of I-D, draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-00.txt has been successfully submitted by Gyan S. Mishra and posted to the IETF repository. Name: draft-mishra-bess-ipv4nlri-ipv6nh-use-cases Revision: 00 Title: IPv4 Network Layer Reachability Information with IPv6 Next Hop Use Cases Document date: 2020-04-27 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-2D00.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4bdUQJ2y41iH_vLflg8-Ar3aHn_kwth38WKtAU2fMbo&s=uYzQU_eDDYqqBrYz3XxFcZoSkwq-rFuZL8_MzfRsmb4&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=4bdUQJ2y41iH_vLflg8-Ar3aHn_kwth38WKtAU2fMbo&s=hYfL8pgPkZvO5vCv5GUow-UGCOTvbKdPtpOz1CQM8PQ&e= Htmlized: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D00&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=4bdUQJ2y41iH_vLflg8-Ar3aHn_kwth38WKtAU2fMbo&s=4G_ULMczbDywlDg3SB0nXXsaKb7v5FtcqR_vg7Z8koc&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=4bdUQJ2y41iH_vLflg8-Ar3aHn_kwth38WKtAU2fMbo&s=v8hzCzhPOtGFFNszOJBCkc123ZJT2G6xhGEWixqqqdE&e= Abstract: As Enterprises and Service Providers upgrade their brown field or green field core to an IPv6 transport such as an MPLS LDPv6 core or SRv6 core, 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 customers. IXPs (Internet Exchange points) are also facing IPv4 address depletion at their peering points, which are large Layer 2 transit backbones that service providers peer and exchange IPv4 and IPv6 (Network Layer Reachability Information) NLRI. Today these transit exchange points are dual stacked. One proposal to solve this issue is to use [RFC5549] to carry IPv4 (Network Layer Reachability Information) NLRI in an IPv6 next hop and eliminate the IPv4 peering completely using the concept of [RFC5565] softwire mesh framework. So now with the MP-BGP reach capability exchanged over IPv4 AFI over IPv6 next hop peer we can now advertise IPv4(Network Layer Reachability Information) NLRI over IPv6 peering using the [RFC5565] softwire mesh framework. 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 carrying 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*Silver Spring, MD 20904 *IETF & ISOC Member since 2015* https://www.ietf.org/ https://www.internetsociety.org/ -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mis...@verizon.com
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
