Jeffrey> A BR may originate an intra-AS I-PMSI A-D route for the global
Jeffrey> table but it is not required, just like in rfc6513/6514/6625.
Jeffrey> As mentioned above, use of intra-AS I-PMSI A-D routes is optional.
I think the references are not quite clear on whether an Intra-AS I-PMSI A-D
route is needed in the case where BGP C-multicast is used but inclusive
tunnels are not used. RFC 6514 specifies particular cases in which a PE
does not need to originate an Intra-AS I-PMSI A-D route. These cases have
to do with the presence or absence of receivers and/or sources in sites
attached to the PE, and with whether ingress replication is being used. But
there doesn't seem to be a rule saying "you don't have to originate an
Intra-AS I-PMSI A-D route if you don't want to use an inclusive P-tunnel".
In GTM, I think the use of inclusive tunnels is less likely, and there are
potentially a lot more global tables than there are VRFs of any given VPN.
So it's more important to avoid originating A-D routes that aren't really
needed.
Jeffrey> each BR may use a unique RD value for its global table
Doesn't that create a problem with regard to the following text from section
11.1.3 ("Constructing the Rest of the C-Multicast Route") of RFC 6514:
If the local and the upstream PEs are in the same AS, then the RD of
the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route
that contains the address carried in the Multicast Source field.
Is it the intention that the C-multicast route NLRI always have an RD of
zero, even if the global tables have non-zero RDs?
Jeffrey> Single Forwarder Selection can still work for GTM if BGP Add-Path
Jeffrey> is used, which allows to propagate multiple UMH-eligible routes for
Jeffrey> the same prefix
It's not enough to propagate multiple paths to a given prefix, you'd have to
make sure you propagate at least one path per ingress PE for that prefix.
This gets a little tricky on BGP sessions where the next hop is changed and
hence no longer identifies the ingress PE.
AS-X | AS-Y | AS-Z
| |
S--PE1---ASBR1--|--ASBR2--|---ASBR5
| \______/ | |
| / \ | |
|--PE2---ASBR3--|--ASBR4--|---ASBR6
| |
In AS-X, PE1 reports to both ASBR1 and ASBR3 that it has a route to S.
Similarly, PE2 reports to both ASBR1 and ASBR3 that it has a route to S.
Using add-path, ASBR1 reports both routes to ASBR2, and ASBR3 reports both
routes to ASBR4. Now AS-Y has 4 paths to S. The AS-Z ASBRs will see eight
paths. This doesn't seem very desirable. One can configure a BGP speaker
using add-path to report only the n best paths, but then there is no
guarantee that the reported set of paths will contain at least one path via
PE1 and at least one path via PE2.
I think if we really wanted to pursue this, we'd have devise some new
add-path functionality such as the following. Given a set of paths with the
same NLRI, look at the set union of the VRF Route Import ECs of those paths.
For each value of VRF Route Import EC in that set, report the best path that
carries that VRF Route Import EC value.
Another alternative would be to export the GTM UMH-eligible routes as
SAFI-129 routes, using unique RDs for each global table, and using RTs to
cause the routes to be imported into the global tables.
But perhaps it would be better just to say that SFS is not supported for
GTM.
With regard to the use case scenario of section 3.2:
> Multicast traffic has to go through the BRs but the unicast not
> necessarily. GW1 is simply advertising itself as the "protocol nexthop"
> for unicast.
In other words, what is desired is a multicast topology that is
non-congruent to the unicast topology. That needs to be stated explicitly.
Jeffrey> With enough tweaking in the UMH selection procedures we can make it
Jeffrey> work w/o originating SAFI-2 routes, so it was included. Note that
Jeffrey> even if the UMH routes are not distributed by BGP at all, the
Jeffrey> procedure could still work. We can get input from WG on if such
Jeffrey> scenario is worth supporting. If not, it can be taken out of scope.
I can well imagine that a service provider might want to get this
functionality without modifying its procedures for distributing unicast
routes, without enabling and configuring SAFI-2, and even without adding the
VRF Route Import EC to the UMH-eligible routes.
If the tweaked UMH selection procedures only work in a very specific
environment, I don't think it is appropriate to standardize them. However,
as long as the tweaks are fully specified and the applicability restrictions
clearly stated, it could be appropriate to describe the tweaks in an
Informational document, especially if some service provider is demanding
them. But these environment-specific tweaks have to be clearly
distinguished from the procedures that are required for a more general
implementation of MVPN-based GTM.
Eric> MVPN procedures do not require an ingress PE to originate a route to
Eric> itself with a VRF Route Import extended community attached. (One
Eric> could make that a requirement, but I don't see it in the draft, and
Eric> that would certainly be a modification of the MVPN procedures.)
Jeffrey> It's not required; but if such a route does exist, then it can be
Jeffrey> used to make that deployment scenario work.
If certain procedures will only work when certain route origination policies
are in place, the relationship should be clearly stated. (I guess the route
origination policies could be called "pre-requisities" rather than
"requirements" ;-))
With regard to the following tweak:
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.
Thinking about this more, I'm liking it better, but I think it has the
following pre-requisites that should be stated explicitly:
- If a UMH-eligible route from an ingress BR that is distributed without the
VRF Route Import EC, it MUST be distributed to the egress BRs in such a
way that the next hop is never changed.
- An ingress BR that distributes UMH-eligible routes without the VRF Route
Import EC MUST use BGP to distribute a route to itself that does have the
VRF Route Import EC. The NLRI MUST contain the same prefix that is used
as the next hop in the abovementioned UMH-eligible routes. This route
MUST be distributed to all the egress PEs that receive the abovementioned
UMH-eligible routes, and at those egress PEs, it MUST be the preferred
route to the ingress PE.
On the issue of whether GTM requires changes to the MVPN specs (and hence a
Standards Track document), I don't want to make too big a deal of the
process issue. But the issue is only whether any of the procedures are
different than what is described in the MVPN specs, not how different they
are or how obvious one thinks the differences are ;-)
Jeffrey> current MVPN spec allows using configured RTs. One can think that
Jeffrey> there is an (auto-configured) RT 0:0 for the global table.
This modifies the default specified in RFC 6514 section 9.1.1, which
requires that, by default, the RTs be the same as the ones carried by the
"unicast VPN-IP routes" (should be "UMH-eligible routes", actually).
Jeffrey> Current MVPN only says use the RD for the VPN. One can think that
Jeffrey> for the global table, there is an all-zero RD (or any other unique
Jeffrey> RD)
Sure, the GTM spec can say something like: "it MUST (or SHOULD or MAY) be
possible to configure an RD that is used only for MCAST-VPN A-D routes
originated from the global table, and the default value MUST be zero". It's
probably also worth pointing out that this is not a legal value for use as a
VRF RD, and that, unlike the use of RD zero in seamless-mcast, the use of RD
zero in this draft does not modify the semantics of any BGP route in which
it appears.
Also, I think that something along the lines of section 6.1.2 of the
seamless-mcast draft (or perhaps a normative reference to it) should also be
included.
