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

[Gyan Mishra <[e-mail]>]

Hi Jeffrey & Mankamana

Just following up on my comments and if you had any questions.

Kind Regards

Gyan

On Thu, Jan 9, 2020 at 7:22 PM Gyan Mishra <[e-mail]> wrote:

>
> In-line comments
>
> On Wed, Jan 8, 2020 at 1:48 PM Jeffrey (Zhaohui) Zhang <[e-mail]>
> wrote:
>
>> Hi Gyan,
>>
>>
>>
>> Please see zzh3> below. I trimmed some text.
>>
>>
>>
>> *From:* Gyan Mishra <[e-mail]>
>> *Sent:* Wednesday, January 8, 2020 2:50 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
>>
>>
>>
>> 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.
>>
>>
>>
>    Gyan> I am on the same page with you on the draft as it has a lot of
> merit.  I like the concept of leveraging BGP for multicast and using the
> proven MVPN procedures to instantiate PMSI trees now with hard stare end to
> end.
>
> Few comments below:
>
> The main objectives of this draft which should be incorporated in the
> Introduction is to provide an option for both service providers and
> enterprises that do not want to maintain soft state of multicast trees ;
> native PIM ASM or SSM based trees ; or MPLS based instantiated S-PMSI trees
> ; to use BGP multicast hard state to send joins/prune using proven service
> provider MVPN procedures.  Provide a means of network based source
> discovery for both ASM and SSM.
>
> Would Default MDT UI/MI PMSI instantiated tree type 1 and 2 be considered
> hard state since the default MDT tree is always UP.  They could be an
> example to give to describe what is meant by hard state.
>
> What is confusing is the mention in the introduction of the target
> deployment being for data centers BGP-only RFC 7938 deployments.  Since BGP
> multicast procedure can use both eBGP or IBGP with or w/o RR ; I would put
> the target deployments or use case in a separate section.  I think the
> reason why 7938 is mentioned is that in cases where BGP is solely used and
> protocol elimination is the goal, similar to P router “BGP free core” ;
> this allows for the elimination of PIM as well.  Does add confusion as part
> of intro since it makes the reader think that this is a eBGP only option
> for this feature  which it is not.
>
> Some operators don’t have an issue with the IP or labeled soft state with
> tree based models
>
> Since the objective of this draft is to provide an alternative solution
> for operators  and not that this would provide a means to that end to
> eliminate tree based protocols such as pim or mldp but as an “option” if so
> desired.   I would stare as such.
>
> I don’t think tree based protocols are going away any time soon but I
> think it’s good to clarify that the direction from a standards perspective
> is not to eliminate but provide the optional flexibility for operators.
>
> I think it’s a good idea to define what is meant by hard state and soft
> state.
>
> There maybe reason that operators may desire to keep the soft state if
> they don’t have much native or labeled state.  Or for telemetry or tracking
> purposes desire to maintain tree state to see how many trees are active
> within the network.  For scalability in cases of where soft state
> management is an issue now they have an option.
>
> ASM was built with LHR network based source discovery with MSDP and to
> that end it did add complexity but did allow a lot of flexibility that the
> MRIB contained all available groups so any receiver could join and group
> and any source could start streaming if they so desired.  Controls were
> built into ASM for that reason to limit what groups could be serviced  by
> an RP via ACL and what sources could stream with PIM accept register.
> Controls were also put in place with MSDP SA propagation with SA
> filtering.  So the added flexibility of network based discovery was nice
> with ASM however with a major trade off of complexity as well as now added
> controls as to what valid sources can steam and what receivers can join
> what what steam.
>
> SSM was designed w/o network based discovery to eliminate the complexity
> of all the knobs to provide those controls that were built into ASM for the
> gain of simplicity : thus application based network discovery.  With SSM
> now all the controls are with the application /  server layer and removed
> from the network.  With application based source discovery at the
> application layer a channel list can now be provided which was done
> previously by legacy multicast apps such as SDR which detected the active
> groups on the network.
>
> I think it maybe worthwhile mentioning reasons why SSM was built without
> network based discovery since now this draft will be adding the capability
> to SSM for network based source discovery.
>
> Regarding the multicast NLRI I was thinking how that would work and reason
> why the group is not needed is that the group is known with ASM model and
> if you have ASM and SSM overlay the  group is known by the app layer and so
> the network just needs the source to be learned for the LHR S,G join. Maybe
> worth mentioning in the draft.
>
> In the introduction I would remove that soft state and tree building
> protocols as a reason why data centers avoid enabling multicast on the
> network.  There maybe some isolated corner cases however predominantly PIM
> soft state ASM or SSM has never been an issue.  To that end most data
> centers server deployments rely on multicast for clustering and data
> replication.  Also server based applications that can utilize multicast
> save on high bandwidth server to server east to west intra data center
> flows.  I do think BGP multicast would be an improvement and would add
> stability for data centers requiring multicast.
>
> In the draft it mentions that earlier versions of this draft user
> C-Multicast for signaling which was change to S-PMSI leaf Type 4 routes so
> we can set up the tree from FEC root instead of leaves.  This is similar to
> P2MP TE P-Tunnel where the root advertises BGP route type 3 with “leaf info
> required” bit set ; when the receiver PE gets the route it responds with
> type 4 leaf-ad.  Is that correct?
>
> For labeled use case can this be used for all P-tunnel types MP2MP P2MP
> mLDP, P2MP TE.  Would PIM Rosen GRE still be valid P tunnel supported.
> Maybe good to mention all the P tunnels supported for labeled BGP multicast.
>
> As far as the MVPN procedures instantiation of S-PMSI trees is that being
> completed reused from RFC 6513 6514  - all the same route types supporting
> ASM and SSM types 3-7.  Only type 1 and 2 for default MDT instantiation of
> I-PMSI trees is not supported.
>
> Correct?
>
> Kind regards,
>
> Gyan
>
> 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
>>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]