Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03

[Gyan Mishra <[e-mail]>]

Jeffrey

I would like to comment on Introduction motivation section.

1st paragraph comments

”This section provides some motivation for BGP signaling for native and
labeled multicast. One target deployment would be a Data Center that
requires multicast but uses BGP as its only routing protocol [RFC7938]. In
such a deployment, it would be desirable to support multicast by extending
the deployed routing protocol, without requiring the deployment of tree
building protocols such as PIM, mLDP, RSVP-TE P2MP, and without requiring
an IGP.
Additionally, compared to PIM, BGP based signaling has several advantage as
described in the following section, and may be desired in non-DC deployment
scenarios as well.”

In the data center typically almost 99.99% of the time it would be PIM and
I don’t know of anywhere that  MPLS is deployed within the single data
center.  I think the reference to MPLS mLDP, TE should be removed in
context of data center. Maybe you are trying to show every possibility I am
guessing or I think depict relevant use case showing replacement of mLDP or
PIM Rosen or P2MP TE.

I don’t see how you would deploy BGP only architecture in a data center
without an IGP.

Let’s say If you had a vxlan evpn super spine with 8 nodes and so now each
node would now sit in a different AS and each spine node would as well sit
in a separate AS.

I have tried building in Cisco VIRL vxlan evpn architecture carving up the
data center pods into separate BGP ASs and its very very complex to say the
least.

In a data center there maybe typical use cases which I have deployed -
let’s say where you have a single BGP AS that spans a single data center or
you have chopped up the data center into multiple PODs fault domains that
are BGP ASs onto themselves that are inter connected.   Further in either
scenario you have deployed vxlan evpn within each Pod and build a super
spine and leaf vxlan architecture with border leaf for your vxlan VNI NVE
anycast tunnels - typical vxlan design.  In that design you deploy SSM in
your underlay as well as use SSM in your overlay. In this typical vxlan
evpn design you use the centralized or distributed multicast model to build
your trees.

I don’t see a problem that is being solved replacinf SSM as your inter or
intra domain multicast routing protocol.

What would be the advantage of using bgp for signaling the trees with a
vxlan evpn architecture over using SSM in the overlay.

2nd paragraph comments

“PIM-SSM removes much of the complexity of PIM-ASM by moving source
discovery to the application layer. However, for various reasons, many
legacy applications and devices still rely upon network-based source
discovery. PIM-Port (PIM over Reliable Transport) solves the soft state
issue, though its deployment has also been limited for two reasons:”


I disagree with the SSM issues you raised as a motivation for this draft.

As you know ASM even with its complexity and pitfalls has been around since
Day 1 and it definitely has its drawbacks for sure.  I would say the
biggest drawback of ASM is that you have to maintain an RP control plane
mechanism for source discovery and propagation of the source SAs so the
shortest path tree switchover can occur.  Complexity in ASM which can be
enormous in an enterprise arena moreso then from a SP perspective.  ASM
complexity lies in building of a MSDP mesh topology.  I have built ASM
Anycast/MSDP topologies that have had over 10k peers.  The ASM complexity
is with source discovery for large enterprises.

SSM works very well and is now the definitive best practice with PIM WG ASM
mboned being shelved as historical.  The beauty of SSM is with the
elimination of the RP control plane and Anycast/MSDP for inter domain
multicast to work.

ASM deprecated for inter domain multicast:

https://tools.ietf.org/pdf/draft-ietf-mboned-deprecate-interdomain-asm-06.pdf


Within an enterprise migrating from ASM to SSM since RPs are eliminated and
MSDP source distribution is not needed with SSM you can collapse all of
your Multicast domains that has their own anycast RP can now all sit in the
single unified multicast domain across all administrative boundaries.

For inter domain SSM  if you really have to - BGP multicast NLRI can be
used for source propagation if necessary.

I have designed and deployed massive ASM architecture within Verizon
internally which I migrated to SSM and collapsed all the domains onto a
single multicast routing domain.


I think the draft had merit and I like the idea but I think the motivation
section needs to be cleaned up.

I really can’t see this being used in an enterprise data center scenario.
I think we have to first find a valid issue with SSM to look to replace it
or even propose an alternative.

Could this be used in an SP scenario providing EVPN services vxlan evpn or
pbb over MPLS core or even with SR SR-MPLS or SRv6. Integrate this solution
into existing MVPN mLDP, PIM, P2MP TE as an alternative solution.  This
sits in the vxlan evpn VRF overlay over the MPLS core so I think you could
apply the same end to end BGP signaling concepts for customers as a value
added service.

See forwarded below as well - inline comments.

Kind regards,

Gyan


On Mon, Jan 6, 2020 at 8:09 PM Jeffrey (Zhaohui) Zhang <[e-mail]>
wrote:

> Hi Gyan,
>
>
>
> Please see zzh> below.
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Monday, January 6, 2020 7:10 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [bess] WG adoption and IPR poll for
> draft-zzhang-bess-bgp-multicast-03
>
>
>
>
>
> Authors
>
>
>
> Would this draft also provide a move towards a stateless core migration of
> inband signaling provided by mLDP to now be provided by BGP.
>
>
>
> Zzh> This will still have per-tree state in the core. The only way to do
> efficient replication w/o per-tree state is BIER, at least so far.
>
> Understood. State issues are worse with in band and  better with out of
> band MVPN deployments for both PMSI-S and PMSI-I.  It would be nice to not
> have any  state and then BIER as you stated is the only option.
>


>
> Cisco and other vendors may support BGP C-Multicast signaling out of band
> signaling type 6 and 7 mVPN routes today.
>
>
>
> Zzh> MVPN type 6/7 routes (RFC 6514) routes are for signaling multicast
> over a “virtual LAN” (overlaid on top of the provider core). This draft is
> for signaling multicast through a network (of many hops) using BGP. In some
> way it is similar to mLDP inband signaling but nowadays in the SR era some
> people want to remove LDP/RSVP entirely.
>
>  Understood.  This draft is an attempt to eliminate the c-tree and p-tree
> created using Next Gen MVPN trees using  PIM Rosen, mLDP, P2MP TE and use
> BGP based trees using the similar “core tree” procedures.
>
> I thought this was covered in one of the other MVPN RFCs but maybe not.
>
>
>
> Could BGP also be used for SR SR-MPLS and SRv6 use cases to carry MVPN
> services out of band via BGP that was traditionally carried over mLDP or
> PIM.
>
>
>
> Zzh> Not exactly sure what you’re asking; but this draft is about
> establishing a multicast tree (native or labeled PIM-like tree or mLDP-like
> P2MP tunnel), which could be used however/wherever it makes sense – e.g. w/
> or w/o MVPN.
>
    In the draft was mentioned mLDP replacement so for that i was thinking
SR maybe a use case.

> Zzh> Jeffrey
>
>
>
> Kind regards,
>
>
>
> Gyan
>
>
>
> On Mon, Jan 6, 2020 at 9:15 AM <[e-mail]> wrote:
>
> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for and
> draft-zzhang-bess-bgp-multicast-03 [1] ..
>
> For information, it’s companion document
> (draft-zzhang-bess-bgp-multicast-controller-02) is also polled for WG
> adoption in a separate email.
>
>
>
> Please review the draft and post any comments to the BESS working group
> list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this Document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document won't
> progress without answers from all the authors and contributors.
>
> Currently, there are no IPR disclosures against this document.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll for adoption closes on *** 20th January 2020 ***
>
>
>
> Regards,
>
> Matthew and Stephane
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast__;!!NEt6yMaO-gk!Q6rFB6ImtuZ93rr2rq9fS3WH3JcBQmWafp3Ng5bn8fDIzx_9HiNIf1DeZ7EDvK3Y$>
>
>
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!Q6rFB6ImtuZ93rr2rq9fS3WH3JcBQmWafp3Ng5bn8fDIzx_9HiNIf1DeZ6wWVdFQ$>
>
> --
>
> Gyan S. Mishra
>
> IT Network Engineering & Technology
>
> Verizon Communications Inc. (VZ)
>
> 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> United States
>
> Phone: [phone]
>
> Email: [e-mail]
>
> www.linkedin.com/in/networking-technologies-consultant
> <https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!Q6rFB6ImtuZ93rr2rq9fS3WH3JcBQmWafp3Ng5bn8fDIzx_9HiNIf1DeZxMOqhNO$>
>
>
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant