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

[Gyan Mishra <[e-mail]>]

Hi Jeffery

Pleas see in line Gyan>

On Tue, Jan 7, 2020 at 9:49 AM Jeffrey (Zhaohui) Zhang <[e-mail]>
wrote:

> 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.
>
>
>
     Gyan> Maybe you can reword and say without requiring the deployment of
tree building protocols such as PIM for Data Center & mLDP, RSVP-TE P2MP
for Non Data Center networks inclusive such as for Segment Routing.


> 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).
>
>
    Gyan> I actually read RFC 7938 when I was redesigning a data center
architecture for stability using a L3 smaller fault domain design.  This
BGP signaling of trees feature has to be used with eBGP and not iBGP as
that requires IGP which would now be in the RIB for RPF path so would not
work thus the "no IGP" requirement as per RFC 7938.  If you had directly
connected iBGP peers and not loop-loop so that you don't need an IGP, could
the BGP signaled tree feature still work. In theory your spine & leaf could
all be directly connected iBGP peers and all now sit in one AS and not have
an IGP.  This would eliminate the need to have ASNs deployed.  So with this
feature the last hop router signals join similar to mLDP inband via BGP and
the join is sent via BGP signalled tree.  With the BGP trees using the same
MVPN mLDP procedures is their a concept of PMSI-I inclusive trees c-tree
p-tree so a single tree  P2MP or MP2MP can be shared by all groups or is it
1-1 mapping group to tree.  Is their any way to minimize per GDA state with
BGP trees.  For the BGP trees is it possible use the same MVPN BGP A-D and
c-tree p-tree Type 6 & 7 routes BGP multicast c-signalling.   Doing so
could you leverage the PMSI-I inclusive tree MVPN feature so you don't have
per GDA state

>
>
> 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.
>
    Gyan> Source discovery is only necessary with ASM not SSM. With SSM the
receiver is "source" aware so does not require any discovery mechanism.
So with SSM which requires IGMPv3 enabled on the receiver last hop router
subnets and on the source first hop router subnet for the both to be
"source aware" ; for the receiver now to send the (S,G) join for the
channel since it is now source aware. How the receiver gets that source
awareness is from the server URI that the user connects to which has the
S,G information ; server has to be also  source aware and has S,G channel
available that can be joined. With IGMPv3 the packet  accommodate the
Source information in the S,G join sent along the RPF path to the source.
You mention that SSM deployment has been limited but in fact the opposite
and reason why ASM is being officially deprecated by the IETF for inter
domain multicast routing. IPv6 does not even have MSDP support since with
ASM MSDP source discovery and propagation is not necessary since no RPs
exist all disparate ASM multicast domains can now be collapsed into a
single SSM domain. ASM MSDP/Anycast has its complexities which is why IPv6
nixed the idea of integrating MSDP into the architecture. Thus IPv6 only
supports SSM for inter-domain multicast routing. I would keep the comment
about ASM complexity which is true but remove mention of SSM.  I would not
mention any gains with less state as you would still have to maintain IGMP
join state with BGP with 1-1 mappings of GDA to tree so the tree state is
not being eliminated.

> 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.
>
>
   Gyan> "While PIM-SSM removes the complexity of PIM-ASM, it requires that

   multicast sources are known apriori.  There have not been a good way
   of discovering sources, so its deployment has been limited."


>
> 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]>
> 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.
>
>  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]> 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://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]
>
> 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
> <https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!QtpaFkmp7b-jN1Hx7jvDFyyziVwrqB-uaXzP3-7VpsK-vqdh7dzTIXYI89SlT2YC$>
>
>
>


-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]