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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Gyan,

Please see zzh> below.

From: Gyan Mishra <[e-mail]>
Sent: Tuesday, January 7, 2020 12:39 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03


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.

Zzh> Sure I can keep PIM only in this.

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

Zzh> That is outside the scope of this document; the rational and practice is well documented in RFC7938 (that the above quoted paragraph refers to).

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.

Zzh> Let’s put aside underlay/overlay thing but only look at multicast trees itself (a tree could be in the underlay itself, or the EVPN overlay is just “one hop” – a simulated LAN – of the tree).
Zzh> Some people don’t like to run PIM at all in their network. Some accept PIM, but want to consolidate to BGP after they deploy RFC7938.
Zzh> BGP signaling replacing PIM-SSM removes PIM refreshes and removes the PIM protocol. The latter matters only for those who really care about “removing another protocol”.
Zzh> BGP signaling replacing PIM-ASM removes the complexity of PIM-AS complexity and corresponding fragility in some implementations. More below on this.

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.

Zzh> The above two paragraphs of yours endorses the first sentence in the paragraph that you quoted 😊 BTW – even if MSDP is not used, PIM-ASM still has its complexities.
Zzh> The quoted paragraph then further points out many deployments still relies on “network-based source discovery” (i.e., RPT->SPT switching or MSDP), laying the foundation that this draft introduces BGP-based source discovery mechanism for those who still need network-based source discovery.
Zzh> Notice that we’re not saying SSM is bad. Rather, SSM is what we want to do, but the draft is about BGP-SSM (a step up from PIM-SSM) with BGP-based source discovery.

ASM deprecated for inter domain multicast:

https://tools.ietf.org/pdf/draft-ietf-mboned-deprecate-interdomain-asm-06.pdf<https://urldefense.com/v3/__https:/tools.ietf.org/pdf/draft-ietf-mboned-deprecate-interdomain-asm-06.pdf__;!!NEt6yMaO-gk!QtpaFkmp7b-jN1Hx7jvDFyyziVwrqB-uaXzP3-7VpsK-vqdh7dzTIXYI83lmj4OL$>


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.

Zzh> One important motivation of the draft is to provide means of supporting SSM even when there is no application-based source discovery.

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

Zzh> I thought our motives are perfectly aligned? 😊

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.

zzh> DC was mentioned because it is a perfect starting point scenario, at least for those operators who deploy RFC7938 and don’t want to run PIM in their DC (even though they have multicast need).
Zzh> Of course it can be used for any scenario where: 1. The operator is open to run BGP on every node (could be for multicast purpose only) 2. The operator wants to remove the complexity of PIM-ASM and inefficiency of PIM, or the operator wants to replace mLDP protocol.

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.

Zzh> The highlighted red text in your paragraph is the key (and mentioned in the first paragraph you quoted 😊). The before/after sentences are orthogonal (whatever service is fine) 😊

See forwarded below as well - inline comments.

Zzh> More zzh2> below.

Kind regards,

Gyan


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

Please see zzh> below.

From: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Sent: Monday, January 6, 2020 7:10 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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.
 Gyan> 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.
Zzh2> This draft is only about establishing multicast trees/tunnels using BGP signaling. The resulting trees/tunnels can be used for whatever purposes.
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.
Gyan> In the draft was mentioned mLDP replacement so for that i was thinking SR maybe a use case.
   Zzh2> It can certainly be used in an SR network (if the operator wants to remove PIM/mLDP/RSVP-TE P2MP).
   Zzh2> Thanks!
Zzh> Jeffrey

Kind regards,

Gyan

On Mon, Jan 6, 2020 at 9:15 AM <[e-mail]<mailto:[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]<mailto:[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://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike?entry=gmail&source=g__;Kys!!NEt6yMaO-gk!QtpaFkmp7b-jN1Hx7jvDFyyziVwrqB-uaXzP3-7VpsK-vqdh7dzTIXYI83pxKc0T$> FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: [phone]
Email: [e-mail]<mailto:[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]<mailto:[e-mail]>
www.linkedin.com/in/networking-technologies-consultant<https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!QtpaFkmp7b-jN1Hx7jvDFyyziVwrqB-uaXzP3-7VpsK-vqdh7dzTIXYI89SlT2YC$>