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

From: Gyan Mishra <[email-masked]>
Date: Tue, 28 Apr 2020 12:30:39 -0400

All

Below is draft that I presented at the end of the interim meeting today.

Sorry for the audio issues I had during the call.  My apologies.

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

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

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

Please provide any comments and feedback.

Kind regards

Gyan
Cell - 202 734-1000

---------- Forwarded message ---------
From: Mishra, Gyan S <[email-masked]>
Date: Mon, Apr 27, 2020 at 6:37 PM
Subject: Fwd: [E] New Version Notification for
draft-mishra-bess-ipv4nlri-ipv6nh-use-cases-00.txt
To: Hayabusanew <[email-masked]>

---------- 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*Silver Spring, MD
20904

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

---

From: John Scudder <[email-masked]>
Date: Tue, 28 Apr 2020 18:16:45 +0000

Hi Gyan,

On Apr 28, 2020, at 12:32 PM, Gyan Mishra <[email-masked]> wrote:

Just BTW, I am about 99% sure your problem was the following. You were logged in to the call twice, from two devices. One device was muted, the other one wasn’t. Let’s call these devices A and B. My guess — this isn’t exposed by WebEx so I can’t be sure, but it’s consistent with the observed behavior — is that although A was muted, it still had the volume raised on its speaker; it was playing meeting audio. Furthermore it was playing the audio within range of B’s microphone. So, you got this feedback loop:

   your voice —> B mic —> webex —> A speakers —> B mic
                            ^                       |
                            |                       |
                            +——————————————————————-+

To avoid this in the future, use only one device for meeting audio. On the other device, disconnect from audio, or mute the mic AND the speakers. (And for people who end up as meeting host in this situation, once you understand the pathology, you can use the host tools to completely disconnect — not just mute, but expel from the meeting — the problem device, which will be the one that shows as having its mic muted.)

Hope this helps someone in the future,

—John

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 28 Apr 2020 15:25:47 -0400

Thank you John!

Agreed on your analysis.

Key is to disconnect from all other audio prior.

I was first connected via my cell and volume turned low and was on mute.
My phone accidentally came off mute so then I disconnected my phone from
webex completely.

Prior to disconnecting my cell I was also connected via my primary laptop
to be ready to present when my turn came up and my audio on my laptop was
via network.  I was also On my laptop I could hear everyone but nobody
could hear me.  I unmuted and muted a few times but could not get the audio
to work.

So then I connected my phone have had issues with dial back and low volume
which was happening so kept clicking from speaker to iPhone since I was
coming in very faint.  Then I can’t remember what I hit but everyone could
hear me but I heard a bad echo on my end which made it difficult to
present. Mankamana said everyone else did not hear the bad echo so that was
good but sounds like their was still some feedbacks as you mentioned
occurring.

I would not have had to flip to my cell if my laptop network Audio worked.

I presented last week on PIM WG and that went without a hitch.

Their is another WG call with LSR tomorrow.  I am not presenting but will
try to speak up in the discussion to test my pc audio issue.  Maybe was
some weird anomaly that would have cleared if I disconnected from webex and
reconnected.  That would have been better then switching to a different
audio source.

I figured it out my cell and computer both were using network audio so that
was caused  the echo issue.  If I turned off volume on my laptop since rx
was working but tx was broke that would have done it.  I guess if  I had
BFD on my pc audio link it would have taken the pc audio down and fixed the
issue graceful make before break failover to cell audio.😭

Kind regards

Gyan

On Tue, Apr 28, 2020 at 2:16 PM John Scudder <[email-masked]> wrote:

> Just BTW, I am about 99% sure your problem was the following. You were
> logged in to the call twice, from two devices. One device was muted, the
> other one wasn’t. Let’s call these devices A and B. My guess — this isn’t
> exposed by WebEx so I can’t be sure, but it’s consistent with the observed
> behavior — is that although A was muted, it still had the volume raised on
> its speaker; it was playing meeting audio. Furthermore it was playing the
> audio within range of B’s microphone. So, you got this feedback loop:
>
> To avoid this in the future, use only one device for meeting audio. On the
> other device, disconnect from audio, or mute the mic AND the speakers. (And
> for people who end up as meeting host in this situation, once you
> understand the pathology, you can use the host tools to completely
> disconnect — not just mute, but expel from the meeting — the problem
> device, which will be the one that shows as having its mic muted.)
>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347