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

From: Gyan Mishra <[email-masked]>
Date: Tue, 14 Jul 2020 00:26:22 -0400

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-masked]>
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-masked]>

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

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