RE: comments on draft-zzhang-mboned-mvpn-global-table-mcast-00.txt

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

Eric,

Thanks for your close review and detailed comments. Please see below.

> -----Original Message-----
> From: Eric Rosen [mailto:[e-mail]]
> Sent: Monday, March 04, 2013 2:58 PM
> To: L3VPN
> Subject: comments on draft-zzhang-mboned-mvpn-global-table-mcast-00.txt
> 
> This draft proposes to use BGP-MVPN procedures to support "Global Table
> Multicast" (GTM).  I fully support this, but I have some questions and
> comments on the draft.  Although the draft name contains "mboned" and not
> "l3vpn", the L3VPN WG seems like the best place to have a detailed
> discussion of a draft that makes use of MVPN procedures.

Good to have your support!

I originally thought this would go to Mboned, but after thinking about 
this further, I think L3VPN is the more appropriate WG for this document.

> 
> - The procedures given in this draft for GTM differ from the procedures for
>   GTM that are provided in draft-ietf-mpls-seamless-mcast-06.txt. There
>   should be some text explicitly pointing this out, and the seamless-mcast
>   draft should be listed in the Informative References section. Further,
>   the mvpn-global-table-mcast should make it clear whether it is being
>   offered as a replacement for the GTM part of the seamless-mcast draft, or
>   whether it is being offered as another possible option.

I will clarify in the next revision that it is different from the other draft, and it is being offered as another possible option.

> 
> - Assuming that the procedures in the mvpn-global-table-mcast draft are
>   being offered as another possible option, the question arises as to
>   whether the two options can co-exist in the same backbone network. This
>   should be addressed in the draft.  I think the answer is that the two
>   procedures can co-exist, as long as it is made clear (somehow) which
>   option is to be used for which ASM groups, and which option is to be used
>   for which (S,G) SSM flows.
> 
>   The two options make different uses of the Leaf A-D routes, but it is
>   always possible to tell from the NLRI of a Leaf A-D route which set of
>   procedures governs the use of that particular Leaf A-D route.  This should
>   be mentioned.

The two options can co-exist. We will spell this out in the next version of the draft.

> 
> - In the MVPN procedures, VRFs are configured with import and export RTs.
>   The I-PMSI A-D routes, S-PMSI A-D routes, and Source Active A-D routes
>   carry at least some of the export RTs of the VRFs from which they are
>   originated, following rules laid out in RFC 6514.
> 
>   The draft doesn't talk about this at all, and it's not clear whether or
>   not it is expected that the global tables will have import and export
>   RTs.
> 
>   Is it required that the I-PMSI, S-PMSI, and Source Active A-D routes
>   originated from the global table will carry RTs, and that these RTs will
>   constrain the distribution of the routes?  If not required, is it
>   prohibited, or is it optional?  If there are no RTs, how does a "BR" (the
>   term used by the draft to mean, roughly, "PE") know whether a particular
>   A-D route needs to be imported into its global table?  Or does every
>   global table have to import every I-PMSI, S-PMSI, and Source Active A-D
>   route that has no RTs?
> 
>   I think this has to be addressed explicitly, as I don't think the answers
>   are determined by just saying "use the MVPN procedures".

Thanks for pointing it out. Yes I will clarify that import/export RTs are used for those I/S-PMSI and SA A-D routes.

> 
> - The draft does seem to assume that a BR will originate an Intra-AS I-PMSI
>   A-D route for the global table, if that BR plays the role of "ingress PE".

A BR may originate an intra-AS I-PMSI A-D route for the global table but it is not required, just like in rfc6513/6514/6625.

>   This raises the question of whether it is allowable to include a PMSI
>   Tunnel attribute in these routes.  If an Intra-AS I-PMSI A-D route
>   specifies an inclusive P-tunnel, every BR in the network that can play the
>   role of "egress PE" for GTM needs to join that inclusive P-tunnel, whether
>   or not it is interested in receiving any multicast data from the
>   originator of the route.  I'm not sure if this is a good idea in the
>   context of GTM.
> 
>   There may be different points of view about whether the use of inclusive
>   tunnels make sense for GTM, but the draft should certainly call attention
>   to this issue.
> 
>   One could also ask whether Intra-AS I-PMSI A-D routes are really needed
>   for GTM at all.

As mentioned above, use of intra-AS I-PMSI A-D routes is optional.

> 
> - Unless it is the intention to disallow the use of wildcard S-PMSI A-D
>   routes, RFC 6625 should be added to the list of normative references, and
>   it would be a good idea to at least mention that wildcard S-PMSI A-D
>   routes may be used for GTM.

Good point. I'll point out that wildcard S-PMSI is applicable and add 6625 to the reference list.

> 
> - The claim is made that "With Global Table Multicast implemented by
>   BGP-MVPN procedures, all the features/characteristics of BGP-MVPN apply,
>   including ... support for PIM-DM ... BSR and AUTO-RP as RP-to-group
>   mapping protocols".
> 
>   I don't believe that MVPN supports PIM-DM; RFC 6513 declares support for
>   PIM-DM to be outside its scope.  I don't think the MVPN RFCs mention
>   Auto-RP at all.

I will replace the text with the following:

      With Global Table Multicast implemented by BGP-MVPN procedures, all
      the features/characteristics of BGP-MVPN apply, including scaling,
      aggregation, flexible choice of provider tunnels, support for 
      ASM/SSM/Bidir as PE-CE multicast protocol, support for unsolicited
      flooded data, including support for BSR as RP-to-group mapping 
      protocols, etc.

> 
> - The MVPN specs distinguish between the "Upstream Multicast Hop" (UMH) and
>   the "Upstream PE".  The draft doesn't stick to the terminology of the MVPN
>   specs, but instead uses the term "RPF route", which is never actually
>   defined.  In some cases, the term "RPF route" seems to mean what RFCs 6513
>   and 6625 call a "UMH-eligible route".  But the draft often doesn't seem to
>   distinguish between the UMH and the Upstream PE.  In particular, some of
>   the new procedures specified in section 3.2 seem to work only if the UMH
>   and the Upstream PE are the same (see below), even though this is not
>   generally the case.
> 
>   I think it would be better to stick to the terminology of the MVPN specs,
>   and to avoid terms like "RPF route" that are not precisely defined.

Sure. I'll fix it in the next revision.

> 
> - The draft does not actually say anywhere that a BR SHOULD attach a VRF
>   Route Import extended community and a Source AS extended community to the
>   UMH-eligible routes that it originates from the global table.  While one
>   could say that this falls under the category of "just use the MVPN
>   procedures", it would be better to mention this explicitly.

I'll mention it explicitly.
	
> 
> - With regard to the statement:
> 
>         "By default, RD 0:0 is used when advertising A-D routes for Global
>         Table Multicast, though an implementation MAY support the
>         configuration and use of a different RD value."
> 
>    * "RD 0:0" is not a notation defined in any RFC.  I assume it means "RD
>      whose value is 64 bits of zero", but it would be better to say that.

Thanks for pointing that out. Will fix it.

> 
>    * When you say "MAY support the configuration and use of a different RD
>      value", please specify whether you mean "each BR may use a unique RD
>      value for its global table", or "all BRs must use the same RD value for
>      their global tables, but it can be configured to be other than zero."
>      It would also be worth discussing whether there is any possible advantage
>      to using an RD other than zero.

I'll clarify that it means "each BR may use a unique RD value for its global table".

> 
> - It should be pointed out that the MVPN procedures for Single Forwarder
>   Selection will not work for GTM, as those procedures presuppose that every
>   VRF has a unique RD, and that this RD is part of the NLRI of the
>   "UMH-eligible" routes.  In GTM, the UMH-eligible routes are will be of
>   AFI/SAFI 1/1, 2/1, 1/2,or 2/2, and these routes do not have RTs. This
>   means that GTM can only be supported on platforms that can implement the
>   procedures of RFC 6513 section 9.1.1 (label-based RPF check).

To be more precise, Single Forwarder Selection can still work for GTM if BGP Add-Path is used, which allows to propagate multiple UMH-eligible routes for the same prefix - that should allow Single Forwarder Selection to work.

I will clarify that.

> 
> - With regard to the following paragraph from section 3.1:
> 
>         In the simple reference scenario above, it is assumed that the BRs
>         learn RPF routes from non-BRs via eBGP or IGP.  The assumption is to
>         illustrate the analogy to a true VPN environment.  In another
>         deployment scenario, the BRs could have learned the RPF routes over
>         those iBGP sessions to non-BRs.  If the BRs act as RRs and reflect
>         the RPF routes to other BRs with polices to attach VRF Route Import
>         Extended Community and Source AS Extended Community, BGP-MVPN
>         procedures can still be used as described earlier.
> 
>   I don't really get the point here.  The protocol by which the non-BR
>   advertises routes to the BR doesn't seem relevant at all; whatever the
>   protocol is, the BR should attach the extended communities when it
>   redistributes the routes via BGP.

You're correct that BRs should attach the ECs. The reason the doc was structured as quoted above is that, there was a comment that in a true VPN environment you'd not have iBGP between PE-CE unless it is the situation as documented in RFC 636. Since this doc is basically saying "use BGP-MVPN protocol/procedure", it is good to point out in that case either BRs act as RRs and attach the extended communities via policy, or follow the 6368 procedures.

> 
>   In any case, I would avoid the phrase "act as an RR"; this phrase is not
>   well-defined.

draft-ietf-mpls-seamless-mcast-06 has "acting as Route Reflectors" :-) Anyway, I'll change it to "BRs are Route Reflectors".

> 
> - I'm not sure I understand the use case scenario of section 3.2:
> 
>         There is a full-mesh of IBGP sessions among provider routers
>         GW1/BR1/BR2/GW2.  EBGP sessions run between CPE1/GW1 and between
>         CPE2/GW2.  Border routers BR1/BR2 run BGP-MVPN procedures for Global
>         Table Multicast.  GW1 learns of BGP route to the src from CPE1 and
>         advertises it to BRx/GW2.
> 
>    In this scenario, is GW1 putting itself in as the next hop of the route
>    to "src"?  If not, what is the next hop?

Yes it put itself as the next hop.

> 
>         Because GW1 does not run MVPN, BR2's route to the src (learned from
>         GW1 instead of BR1) does not have the VRF Route Import Extended
>         Community.  Therefore, it would not be able to correctly attach a
>         Route Target Extended Community corresponding to BR1 in its
>         C-Multicast Routes.
> 
>     In this scenario, is there an assumption that the data path from BR2 to
>     GW1 passes through BR1?  This is not stated, and is not indicated in the
>     diagram, but otherwise I don't see why BR2's C-multicast routes should
>     be targeted to BR1.

For multicast, all traffic has to go through the BRs.

> 
>     But if the data path from BR2 to GW1 passes through BR1, why is GW1
>     telling BR2 that GW1 itself is the next hop?

Multicast traffic has to go through the BRs but the unicast not necessarily. GW1 is simply advertising itself as the "protocol nexthop" for unicast.

> 
>     It would help if the diagram distinguished the physical connections from
>     the BGP sessions.

Sure. Will come up with a better picture.

> 
>     If the unicast data path between GW1 and BR2 does not pass through BR1,
>     but one wants the multicast data path between GW1 and BR2 to pass
>     through BR1, the most obvious solution is to have BR1 originate SAFI-2
>     routes whose NLRIs match the addresses of the multicast sources behind
>     GW1.  Although this isn't mentioned, it seems like a viable option that
>     (a) avoids the need to modify the UMH selection procedures and (b)
>     doesn't depend on or affect the unicast routing.

The scenario is indeed a bit special. With enough tweaking in the UMH selection procedures we can make it work w/o originating SAFI-2 routes, so it was included. Note that even if the UMH routes are not distributed by BGP at all, the procedure could still work.

We can get input from WG on if such scenario is worth supporting. If not, it can be taken out of scope.

> 
> - Section 3.2 proposes a modified procedure for determining the Upstream PE
>   (which would be the "ingress BR" in the terminology of this draft), given
>   a route to the multicast source:
> 
>         o If the route is a BGP route with a VRF Route Import Extended
>           Community, that VRF Route Import Extended Community is used.
> 
>         o If the route is a BGP route without a VRF Route Import Extended
>           Community, get the route to the Next Hop and recurse.
> 
>    I don't understand this second step.  Only routes to multicast sources
>    have the extended community.  So even if the next hop is itself the
>    ingress BR (i.e., if all the BRs are in the same AS), I don't see how
>    this will work, because MVPN procedures do not require an ingress PE to
>    originate a route to itself with a VRF Route Import extended community
>    attached.  (One could make that a requirement, but I don't see it in the
>    draft, and that would certainly be a modification of the MVPN
>    procedures.)

It's not required; but if such a route does exist, then it can be used to make that deployment scenario work.

> 
>    In any case, the next hop is not necessarily the ingress BR; the next hop
>    may be an ASBR that is along the path to the ingress BR.  Since that ASBR
>    may also be along the path to other ingress BRs, the route to the next
>    hop cannot be carrying a VRF Route Import extended community that
>    identifies any particular ingress BR.

The idea is that if the ingress BR is on the path to the advertised next hop, then we can try to identify that ingress BR.

> 
>         o If the route is an IGP route with a RSVP-TE LSP as next hop, and
>           the LSP endpoint is a BR that advertises an Intra-AS I-PMSI A-D
>           route (BR1 in the above example), a VRF Route Import Extended
>           Community is constructed as BR_addr:0 to be associated with the
>           RPF route, where the BR_addr is the Originating Router's IP
>           Address of the Intra-AS I-PMSI A-D route.
> 
>     This will not give the correct result unless the BRs are all in the same
>     IGP domain and are connected through a full mesh of RSVP-TE LSPs.

Right. It does come with restrictions and we can take it out of the scope if the WG consensus is that it's not worth specifying.

> 
>     And the final step of the new procedure:
> 
>         If the above procedure does not produce a usable VRF Route Import
>         Extended Community, then the RPF route is considered a local route
>         (vs. a remote route that is associated with a remote BR).
> 
>     If the next hop is not a BR, presumably it's a system that plays the
>     role of an MVPN CE, and it has to be sent a PIM Join rather than a BGP
>     C-multicast Join.  However, a BR generally knows which of its interfaces
>     are customer-facing rather than core-facing, and should not sent PIM
>     Joins out its core-facing interfaces.  But there are conditions under
>     which the above procedures will cause that to happen.
> 
>     Perhaps the procedures of section 3.2 are intended to have restricted
>     applicability, e.g., only applicable when the "core" contains a single
>     AS or consists of a full mesh of RSVP-TE tunnels.  In that case, the
>     draft should clearly state the applicability restrictions.

Yes I can clearly state that and even take it out of the scope.

> 
> - If there is discussion of modifying the procedure for selecting the UMH,
>   there should be some discussion of whether the procedures in this draft
>   can be used together with the P-tunnel segmentation procedures of
>   draft-ietf-mpls-seamless-mcast.
> 
> - I can't agree with the statement in the abstract that "no protocol
>   modification/extension is required".  While the draft does not define new
>   messages or TLVs, it does specify and/or presuppose procedures that are
>   specific to the case of global table multicast.  For instance:
> 
>   * the procedures for selecting the RD to be placed in the I-PMSI, S-PMSI,
>     and Source Active A-D routes are different than the MVPN procedures;

I don't see the difference? Current MVPN only says use the RD for the VPN. One can think that for the global table, there is an all-zero RD (or any other unique RD).

> 
>   * the procedures for deciding which RTs to attach to routes other than
>     C-multicast routes and Leaf A-D routes are not discussed in this draft,
>     but they should be, and I don't see how they can be exactly the same as
>     the MVPN procedures;

I will add text on that (using an all-zero RT, say RT 0:0); but I don't see how they're different - current MVPN spec allows using configured RTs. One can think that there is an (auto-configured) RT 0:0 for the global table.

> 
>   * the procedure for determining the upstream PE is not the same as the
>     MVPN procedure.

I will clarify that Single Forwarder Selection has its restrictions (not supported unless add-path is used), but I think it is still within the current MVPN spec?

> 
>   These are protocol modifications/extensions, and need to be addressed in a
>   standards track document.

Modulo the special scenario, I don't think the two are that different, but I'm fine with turning it to standards track.

Thanks.
Jeffrey