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

[Gyan Mishra <[e-mail]>]

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]