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

[Gyan Mishra <[e-mail]>]

Dear, BESS, IDR, GROW

**I have added IDR & GROW to this email as this change benefits greatly
GROW(Global Routing Operations)**

This draft utilizes RFC 5549 next hop updated encoding draft update that is
used today for 4to6 Softwire mesh framework PE-P RR next hop encoding for
eBGP PE-CE peering where the IPv4 AFI 1/1  is stacked ontop of IPv6 AFI
2/1, thus eliminating the need for dual stacking PE-CE edge.  As stated
that RFC 5549 next hop encoding is predominantly used for PE-RR next hop
encoding for SAFI's stacked on IPv6 peer including VPN-IPv4 1/128 and MVPN
1/129.  This draft draws attention to the critical OPEX savings as well as
ensuring that all vendors support RFC 5549 encoding for eBGP PE-CE IPv6
next hop encoding for IPv4 NLRI to ensure the next hop is encoded correctly
per Stephane's updated RFC5549 draft which is almost ready for publication.

We have confirmed with Stepahanie that the RFC 5549 next hop encoding
updated draft works for any BGP peering carrying IPv4 NLRI over IPv6 next
hop so is agnostic of BGP internal versus external peering.

This draft ensures through vendor interoperability testing that the vendor
consortium represented on the IETF supports RFC 5549 next hop encoding for
this particular use case for carrying IPv4 NLRI over an IPv6 next hop in
the PE-CE eBGP peering scenario.  This use case is widespread across any
and all operator networks service providers and enterprises for both "core"
& "data center" and is relevant to any underlay IPv4, IPv6, MPLS, SR-MPLS,
SRv6 as the PE-CE customer edge is the same, but now with this draft there
is no longer dual stacked the edge which now can be "IPv6 Only".   This use
case with IPv4 elimination at the PE-CE edge helps tremendously with
proliferation of IPv6 and makes the entire core / edge now 100% IPv6
transport that can carry both IPv4 & IPv6 payload service overlay label.
This pushes IPv4 to the customer network only in the VPN overlay
encapsulation layer and keeps the transport underlay layer IPv4 Free.

With IPv4 address depletion issues with provisioning especially at large
IXP NAPs, this draft has worldwide benefits for internet service providers
so IPv4 can be 100% eliminated at the  internet transport layer.

For this change to gain traction and adoption across the public internet as
well a private networks we need to ensure that interoperability with the
next hop encoding works and is documented in this draft.

At this time we have one vendor Cisco which Mankamana Mishra is
representing for supporting this effort of support of this feature and
interoperability testing.

I would like to procure POC from each vendor listed below and any that I
may have missed please reply to all on this thread so I can get you added
to the vendor list.

I would like to kickoff  a Design Team for this effort for the Proof of
Concept collaboration between vendors so that we can get the process
started with logistics.

I will be presenting this draft at IETF 109 - BESS WG

!RFC 5549 Update - Ready for Publication
https://datatracker.ietf.org/doc/draft-ietf-bess-rfc5549revision/

Appendix A <https://tools.ietf.org/html/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-06#appendix-A>.
IPv4 NLRI IPv6 Next Hop Vendor Testing

   IPv4 NLRI with IPv6 Next Hop encoding is supported for all BGP peers
   both iBGP and eBGP.

   This section details the vendor support and interoperability test
   results for router and switch vendors as well as White Box vendors.
A.1 <https://tools.ietf.org/html/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-06#appendix-A.1>.
Router and Switch Vendors Support and Interoperability Test
      Results.

             +-----------------+---------+------------------+
             | Vendor          | Support | Interoperability |
             +-----------------+---------+------------------+
             | Nokia           |         |                  |
             | Arista          |         |                  |
             | Cisco           |   ***   |                  |
             | Ericsson        |         |                  |
             | Extremenetworks |         |                  |
             | HP              |         |                  |
             | Huawei          |         |                  |
             | Juniper         |         |                  |
             +-----------------+---------+------------------+


 Table 1: Vendor Interop


A.2 <https://tools.ietf.org/html/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-06#appendix-A.2>.
White Box Vendors Support and Interoperability Test Results.

        +----------------------------+---------+------------------+
        | Vendor                     | Support | Interoperability |
        +----------------------------+---------+------------------+
        | Cumulus Networks           |         |                  |
        | PICA8                      |         |                  |
        | Pluribus Networks Netvisor |         |                  |
        +----------------------------+---------+------------------+

                     Table 2: White Box Vendor Interop






---------- Forwarded message ---------
From: Mishra, Gyan S <[e-mail]>
Date: Mon, Nov 2, 2020 at 12:58 AM
Subject: Fwd: [E] New Version Notification for
draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-06.txt
To: Hayabusanew <[e-mail]>




---------- Forwarded message ---------
From: <[e-mail]>
Date: Mon, Nov 2, 2020 at 12:36 AM
Subject: [E] New Version Notification for
draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-06.txt
To: Mankamana Mishra <[e-mail]>, Jeff Tantsura <
[e-mail]>, Gyan Mishra <[e-mail]>



A new version of I-D, draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-06.txt
has been successfully submitted by Gyan Mishra and posted to the
IETF repository.

Name:           draft-mishra-bess-ipv4nlri-ipv6nh-use-cases
Revision:       06
Title:          IPv4 NLRI with IPv6 Next Hop Use Cases
Document date:  2020-11-01
Group:          Individual Submission
Pages:          16
URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D06.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=L0PwAGx0mUNp4TQYiyJ0aU40l3scPHNGMphrJ-PvCHw&s=_SJehRYrOqOs4OeQ5dIF9m1-NfCK7OyTBVr_ILreLOE&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=L0PwAGx0mUNp4TQYiyJ0aU40l3scPHNGMphrJ-PvCHw&s=4h_mHTgx0Ga_8G7967xBiHYAa0Pb8IKIQWTqWxiFA-4&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=L0PwAGx0mUNp4TQYiyJ0aU40l3scPHNGMphrJ-PvCHw&s=Z5tTwALxttTpW__xUb7r-We7mY8v98ZeFoesTKZYlsw&e=
Htmlized:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D06&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=L0PwAGx0mUNp4TQYiyJ0aU40l3scPHNGMphrJ-PvCHw&s=y7ANn6Lrn1MwRGRrs_E1xDVoI5FPr8Mryx4WnlHdgBY&e=
Diff:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D06&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=L0PwAGx0mUNp4TQYiyJ0aU40l3scPHNGMphrJ-PvCHw&s=xUpzey9TC0t-9MIVKKdrwNCMzskJpjIh2VKnNU5xGb0&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.

   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 now provides a 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/




-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD