Skip to main content

IPv4-Only PE Design for IPv6-NLRI with IPv4-NH
draft-mishra-bess-ipv4-only-pe-design-02

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Gyan Mishra , Jeff Tantsura , Mankamana Prasad Mishra , Sudha Madhavi , Qing Yang , Adam Simpson , Shuanglong Chen
Last updated 2023-01-08 (Latest revision 2022-07-07)
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

As Enterprises and Service Providers try to decide whether or not to 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) Edge network from IPv4 to IPv6. Operators must be able to continue to support IPv4 customers when both the Core and Edge networks are IPv4-Only. This document details an important External BGP (eBGP) PE-CE Edge IPv4-Only peering design that leverages the MP-BGP capability exchange by using IPv4 peering as pure transport, allowing both IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session. The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this design change from a control plane perspective a single IPv4 is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv4 address need only be configured on the PE and CE interface for both IPv4 and IPv6 packet forwarding. This document provides a IPv4-Only PE design solution for use cases where operators are not yet ready to migrate to IPv6 or SRv6 core and would like to stay on IPv4-Only Core short to long term and maybe even indefinitely. With this design, operators can now remain with an IPv4-Only Core and do not have to migrate to an IPv6-Only Core. From a technical standpoint the underlay can remain IPv4 and still transport IPv6 NLRI to support IPv6 customers, and so does not need to be migrated to IPv6-Only underlay. With this IPv4-Only PE Design solution , IPv4 addressing only needs to be provisioned for the IPv4-Only PE-CE eBGP Edge peering design, thereby eliminating IPv6 provisioning at the Edge. This core and edge IPv4-Only peering design can apply to any eBGP peering, public internet or private, which can be either Core networks, Data Center networks, Access networks or can be any eBGP peering scenario. This document provides vendor specific test cases for the IPv4-Only peering design as well as test results for the five major vendors stakeholders in the routing and switching indusrty, Cisco, Juniper, Arista, Nokia and Huawei. With the test results provided for the IPv4-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 this new Best Current Practice for eBGP IPv4-Only Edge peering. This Best Current Practice IPv4-only eBGP peering design specification will help in use cases where operators are not yet ready to migrate to IPv6 or SRv6 core or for very lage operator core with thousdands of nodes where it maybe impractical to change the underlay infrastructure to IPv6, and can now keep the existing IPv4 data plane IP, MPLS or SR-MPLS underlay intact indefinitely. This document also defines a new IPv4 next hop encoding for IPv6 NLRI over IPv4 Next Hop to uses 4 byte IPv4 address for the next hop and not a IPv4 mapped IPv6 address. This encoding has been adopted by the industry but has not been standardized until now with this document.

Authors

Gyan Mishra
Jeff Tantsura
Mankamana Prasad Mishra
Sudha Madhavi
Qing Yang
Adam Simpson
Shuanglong Chen

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)