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.
- 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.
- 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.
- 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".
- 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".
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.
- 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.
- 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.
- 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.
- 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.
- 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.
* 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.
- 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).
- 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.
In any case, I would avoid the phrase "act as an RR"; this phrase is not
well-defined.
- 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?
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.
But if the data path from BR2 to GW1 passes through BR1, why is GW1
telling BR2 that GW1 itself is the next hop?
It would help if the diagram distinguished the physical connections from
the BGP sessions.
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.
- 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.)
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.
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.
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.
- 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;
* 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;
* the procedure for determining the upstream PE is not the same as the
MVPN procedure.
These are protocol modifications/extensions, and need to be addressed in a
standards track document.
