Hi Gyan, Please see zzh3> below. I trimmed some text.
From: Gyan Mishra <[email protected]> Sent: Wednesday, January 8, 2020 2:50 AM To: Jeffrey (Zhaohui) Zhang <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03 Hi Jeffery Pleas see in line Gyan> 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. Zzh3> This draft does work for both eBGP and iBGP: How the BGP peer sessions are provisioned, whether EBGP or IBGP, whether statically, automatically (e.g., based on IGP neighbor discovery), or programmably via an external controller, is outside the scope of this document. In case of IBGP, it could be that every router peering with Route Reflectors, or hop by hop IBGP sessions could be used to exchange C-MCAST NLRIs for joins. In the latter case, unless desired otherwise for reasons outside of the scope of this document, the hop by hop IBGP sessions SHOULD only be used to exchange C-MCAST NLRIs. Zzh3> RFC 7938 uses eBGP which does not require IGP, so the following text is perfect (after removing P2MP tunnel wording): This section provides some motivation for BGP signaling for native and labeld multicast. One target deployment would be a Data Center that requires multicast but uses BGP as its only routing protocol [RFC7938<https://tools.ietf.org/html/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. Zzh3> Then the following talks about other scenarios beyond DC: 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. Zzh3> I will change “compared to PIM” to “compared to PIM/mLDP”. Gyan> 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. Zzh3> It’s the PIM joins from LHRs or mLDP label mappings from leaves replaced with BGP messages, not that “the join is sent via BGP signalled tree”. Gyan> 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. Zzh3> MVPN/EVPN is for overlay – multiple C-flows can be transported over a single I/S-PMSI which are instantiated by underlay tunnels. This draft is about establish trees/tunnels, which can instantiate MVPN/EVPN I/S-PMSI (among other things). Gyan> Is their any way to minimize per GDA state with BGP trees. Zzh3> What does GDA mean? Group Destination Address? Zzh3> Anyway, so far the only efficient replication solution w/o incurring per-tree/tunnel state is BIER. BGP-signaled multicast does still have per-tree/tunnel state just like with PIM/mLDP. The only difference is how the state is signaled. Gyan> 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. Zzh3> This draft uses a different address family and new route types similar to MVPN type-3/4 routes instead of type-6/7 routes: The joins are carried in BGP Updates with MCAST-TREE SAFI and S-PMSI/ Leaf A-D routes defined in this document. The updates are targeted at the upstream neighbor by use of Route Targets. [Note - earlier version of this draft uses C-multicast route to send joins. We're now switching to S-PMSI/Leaf routes for three reasons. a) when the routes go through RRs, we have to distinguish different routes based on upstream router and downstream router. This leads to Leaf routes. b) for labeled bidirectional trees, we need to signal "upstream fec". S-PMSI suits this very well. c) we may want to allow the option of setting up trees from the roots instead of from the leaves. S-PMSI suits that very well.] Gyan> Doing so could you leverage the PMSI-I inclusive tree MVPN feature so you don't have per GDA state Zzh3> As explained earlier, I-PMSI is irrelevant. 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. Zzh3> To do SSM you need to know sources ahead of time. Zzh3> In a true ASM scenario, there are multiple sources sending to the same group and receivers don’t necessarily know which sources will be sending. Even though for some applications the receivers can get that source information from some servers/URIs (which is what I refer to as “application based source discovery”), there are still many situations where the receivers just want to do (*,g) IGMP join and leave the source discover to the network. Zzh3> As for deprecating inter-domain ASM, please note the following: This document does not make any statement on the use of ASM within a single domain or organisation, and therefore does not preclude its use. Indeed, there are application contexts for which ASM is currently still widely considered well-suited within a single domain. Zzh3> More importantly, to use SSM you need to know sources first – either the receivers somehow learns/knows the sources or the network will figure it out. This draft provides a way for the LHRs to figure out where the sources are and then apply SSM procedures. 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." Zzh3> To clarify, the above text is not implying to move away from SSM. Rather, it is to explain why we introduce network-based source discovery via BGP in this draft so that SSM can be used w/o requiring application-based source discovery. Zzh3> Thanks! Zzh3> Jeffrey
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
