Subject: [bess] Fwd: [E] New Version Notification for draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-00.txt

From: Gyan Mishra <[email-masked]>
Date: Mon, 4 May 2020 18:47:24 -0400

All

Below is draft that I presented at the interim meeting last week.

We have had for many years  6to4 softwire tunneling of IPv6 NLRI over an
IPv4 core.

So now with new green filed & brown field deployments of IPv6 in the core
we are seeing more 4to6 softwire tunneling of IPv4 NLRI over an IPv6 core
MPLS LDPv6 or SRv6 flavors.

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 as well 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.

I also want to make sure with this RFC 5549 feature implementation, that
you can still add BGP policy for IPV4 and IPv6 over the IPv6 peer just as
you did before and that overall all the features and functionality, you
don’t lose anything capabilities when you eliminate the IPv4 peer.

Please provide any comments and feedback as well as any issues you see with
this idea of IPv4 peer elimination with carrying all v4 and v6 NLRI over
IPV6 peer.

Kind regards

Gyan Mishra
Verizon
Cell 301 502-1347

---------- Forwarded message ---------
From: <[email-masked]>
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 <[email-masked]>

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
<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/

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]