Re: [bess] [E] New Version Notification for draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-08.txt

[Gyan Mishra <[e-mail]>]

Hi Mankamana

I updated the name of the draft which replaces the old name for WG Adoption
call:

This is a more pertinent name for a BCP specification.

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases/

Old name:
draft-mishra-bess-ipv4nlri-ipv6nh-use-cases

New name:
draft-mishra-bess-deplment-guidlin-ipv4nlri-ipv6nh

Kind Regards

Gyan


On Mon, Mar 22, 2021 at 3:30 PM Mankamana Mishra (mankamis) <
[e-mail]> wrote:

> Hi Gyan,
>
> After our BESS session , this draft has been put in queue. Usually one by
> one draft will be polled from queue
>
>
>
> Mankamana
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Friday, March 19, 2021 at 6:51 AM
> *To: *"Bocci, Matthew (Nokia - GB)" <[e-mail]>, "Mankamana
> Mishra (mankamis)" <[e-mail]>, "Stephane Litkowski (slitkows)" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>
> *Cc: *BESS <[e-mail]>
> *Subject: *Fwd: [E] New Version Notification for
> draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-08.txt
> *Resent-From: *<[e-mail]>
> *Resent-To: *<[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>
> *Resent-Date: *Friday, March 19, 2021 at 6:51 AM
>
>
>
> Dear Chairs
>
>
>
> I would like to ask for WG Adoption call for draft below:
>
>
>
>
> https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases/
>
>
>
>
>
> Thank. You
>
>
>
> Gyan
>
>
>
> ---------- Forwarded message ---------
> From: *Gyan Mishra* <[e-mail]>
> Date: Mon, Feb 22, 2021 at 5:22 PM
> Subject: Fwd: [E] New Version Notification for
> draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-08.txt
> To: BESS <[e-mail]>, <[e-mail]>, <
> [e-mail]>, Jeff Tantsura <
> [e-mail]>, Mankamana Mishra (mankamis) <[e-mail]>,
> Lili Wang <[e-mail]>, Simpson, Adam 1. (Nokia - US/Mountain
> View) <[e-mail]>, Qing Yang <[e-mail]>,
> Chenshuanglong <[e-mail]>, Pengshuping (Peng Shuping) <
> [e-mail]>, Greg Mirsky <[e-mail]>, Michael
> McBride <[e-mail]>, Adrian Farrel <
> [e-mail]>, Ron Bonica <[e-mail]>, Kaliraj
> Vairavakkalai <[e-mail]>, Aijun Wang <[e-mail]>,
> Huaimo Chen <[e-mail]>, Gengxuesong (Geng Xuesong) <
> [e-mail]>, Xiejingrong <[e-mail]>, Jeffrey
> (Zhaohui) Zhang <[e-mail]>, zhang.zheng <[e-mail]>,
> Tony Li <[e-mail]>, Tony Przygienda <[e-mail]>,
> Toerless Eckert <[e-mail]>, Rabadan, Jorge (Nokia - US/Mountain
> View) <[e-mail]>
>
>
>
>
>
> Dear BESS WG, Chairs & AD
>
>
>
> I have updated the IPv4 NLRI over IPv6 Next hop use case interop draft
> with significant updates that strictly focuses on the primary use case.
>
>
>
> I added a section on the RFC 8950 updates to RFC 5549.  As this draft
> focus is solely on SAFI 1 IPv4 NLRI over IPv6 NH the updates in RFC 8950
> are not related to this SAFI as they only pertain to SAFI 128 & 129 which
> are out of scope of this interop testing.
>
>
>
> We confirmed early last year during a call with Stephane Litkowski that
> the next hop encoding defined in both RFC 5549 update RFC 8950 includes any
> BGP peer next hop encoding so inclusive of external as well as internal BGP.
>
>
>
> This use case draft will focus primarily on the main goal of the draft
> which is the PE-CE Edge peering use case that exists in any Operator both
> Enterprise or Service Provider Data Center.
>
>
>
> Option # 1 AFI/SAFI 1/1 IPv4 Unicast -  This is the main use case and
> primary SAFI to be tested called out by the draft.
>
>
>
> The MAJOR benefit with this draft is the elimination of all IPv4 peering
> at the edge, so IPv6 can now be the ubiquitous transport within the core as
> well as now at the edge.   This use case draft addresses worldwide IPv4
> address depletion issues that plague operators around the world.  Thus
> helps with the further proliferation of IPv6. This draft also now cuts down
> the 1 for1 IPv4 & IPv6 peering on dual stacked edges in half thus
> drastically reducing OPEX and maintenance cost for operators.
>
>
>
> With this new enhancement of now IPv6 transport style peering at the edge
> operators as well as customers can now take advantage of the much needed
> per flow load balancing BGP Multpath ECMP capability that can be employed
> with the IPv6 flow label RFC 6437 5-tuple input key to hash function for
> uniform load balancing.  This will also provide operators with another
> significant benefit to move quickly to IPv6 as now a new value added
> offering of per flow load balancing can occur at  L3 at the edge  providing
> a viable alternative to EVPN for DCI all active multi home as well as can
> enhance ACTN &  SR  / MPLS Network slicing for 5G & DETNET as well as
> future APN marking capabilities.
>
>
>
> ! IPv4 NLRI over IPv6 NH
>
>
> https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-ipv6nh-use-cases/
>
>
>
> Please review the draft and provide comments.  I will be presenting the
> draft at IETF 110.  Presentation attached.  (Mankamana - Please see
> attachment for IETF 110)
>
>
>
> As we have made significant progress with this draft with 5 major vendors
> on board now, I would like to request chairs for a  WG Adoption poll during
> IETF 110.
>
>
>
> We have added QA lab points of contact  from the following 5 vendors below
> all of which have confirmed support of the eBGP PE-CE edge peering use case
> for next hop encoding of IPv4 NLRI over IPv6 next hop.
>
>
>
> I have updated the draft from Standards Track to BCP.  The goal of this
> draft is to provide operators a comfort level based on QA testing from the
> 5 major vendors below that they can now start the proliferation of this new
> BCP across all operator networks.
>
>
>
> We had to limit the testing and number of vendors to a reasonable set to
> capture the majority of the industry with the MAJOR vendors interop testing
> to make this logistically feasible.  The goal is that the other vendors
> across the globe will support and follow suit to help with the
> proliferation of IPv6 and elimination of IPv4 at the edge.
>
>
>
> Authors:
>
> Gyan Mishra - Primary Author - Editor Verizon
>
> Jeff Tantsura-  Apstra - Technical SME
>
>
>
> 5 vendors POCs Co-authors for interoperability testing:
>
> Mankamana Mishra - Cisco
>
> Lili Wang - Juniper
>
> Qing Yang - Arista
>
> Chenshuanglong- Huawei
>
> Adam Simpson - Nokia
>
>
>
>  Warm welcome to the QA interoperability testing team!!
>
>
>
>
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> ---------- Forwarded message ---------
> From: *Mishra, Gyan S* <[e-mail]>
> Date: Mon, Feb 22, 2021 at 6:20 PM
> Subject: Fwd: [E] New Version Notification for
> draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-08.txt
> To: Gyan S. Mishra <[e-mail]>
>
>
>
>
>
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, Feb 22, 2021 at 6:14 PM
> Subject: [E] New Version Notification for
> draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-08.txt
> To: Adam Simpson <[e-mail]>, Gyan Mishra <
> [e-mail]>, Jeff Tantsura <[e-mail]>, Lili
> Wang <[e-mail]>, Mankamana Mishra <[e-mail]>, Qing
> Yang <[e-mail]>, Shuanglong Chen <[e-mail]>
>
>
>
>
> A new version of I-D, draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-08.txt
> has been successfully submitted by Gyan Mishra and posted to the
> IETF repository.
>
> Name:           draft-mishra-bess-ipv4nlri-ipv6nh-use-cases
> Revision:       08
> Title:          IPv4 NLRI with IPv6 Next Hop Use Cases
> Document date:  2021-02-22
> Group:          Individual Submission
> Pages:          13
> URL:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D08.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=LxogRCq2s223dBbhKt5DcJfHu4meDCz0beysNdrDiMA&s=A-N39xPuUYwA_GRz71tJlTsy6t2p9V_2rbW-EZmwTZA&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=LxogRCq2s223dBbhKt5DcJfHu4meDCz0beysNdrDiMA&s=GTWBonCmR3CyCnjLmbT4iE45otpEOgrUP0pWYunL7-I&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=LxogRCq2s223dBbhKt5DcJfHu4meDCz0beysNdrDiMA&s=KSdoBqsaQo9tom9HL7huoOwNBzpKDwmYkP_dJKaDzG0&e=
> Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D08&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=LxogRCq2s223dBbhKt5DcJfHu4meDCz0beysNdrDiMA&s=tssyOYOYNrjNO6w2jVgT-LadZBus5z-nzmo-2prklLc&e=
> Diff:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dbess-2Dipv4nlri-2Dipv6nh-2Duse-2Dcases-2D08&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=LxogRCq2s223dBbhKt5DcJfHu4meDCz0beysNdrDiMA&s=Lx7HzdD4pBEuPFELnA29-B-sT5ZcXPUjAZjreoHshw8&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
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect, SME & Protocol Design Expert*
>
>
> *Data Center Planning | Common Core | Development & Engineering Lab
> Services Global Technology Services | ITNUC*
>
>
>
>
> *O 240 970-6287 M 301 502-1347 13101 Columbia Pike Rm 304-D *Silver
> Spring, MD 20904
>
>
>
> *IETF  & ISOC Member since 2015*
>
> https://www.ietf.org/
>
> https://www.internetsociety.org/
>
>
>
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
> *M 301 502-1347 13101 Columbia Pike *
>
> Silver Spring, MD
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>


-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*