Eric,
> -----Original Message-----
> From: Eric Rosen [mailto:[email protected]]
> Sent: Thursday, March 21, 2013 11:11 AM
> To: Jeffrey (Zhaohui) Zhang
> Cc: Eric Rosen; [email protected]
> Subject: Re: comments on draft-zzhang-mboned-mvpn-global-table-mcast-
> 00.txt
>
> 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.
If I understand you correctly, the spec should point out that I-PMSI A-D route
should be avoided, for practical reasons. I will do that.
>
> 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?
Yes. The draft did miss pointing out that all-zero RD is used for C-multicast
routes.
Currently the draft says to use all-zero RD for A-D routes by default, but I'm
thinking that we should revert it - use non-zero RDs for A-D routes by default
but allow zero RDs. Using zero RDs has the caveat that it does not work with
GTM procedures in seamless-mpls-mcast.
>
> 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.
Thanks for pointing this out. I agree that we should simply say that SFS is not
supported.
>
> 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.
It's not that it is "desired" so. It's just that the fact that multicast
traffic has to go through certain BRs, while unicast may go through some other
paths.
>
> 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.
Agreed.
>
> 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" ;-))
I will state explicitly which scenarios can be made to work with the tweaks and
what the pre-requisites are. Currently it only spells out the procedure on the
egress PEs.
>
> 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.
If the ingress BR does distribute the routes with BGP, then just make it a
requirement to attach those ECs like in MVPN case.
>
> - 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
When an ingress BR does not distribute all UMH-eligible routes (see above),
then it SHOULD use BGP to distribute the above mentioned route to itself.
The keyword "SHOULD" instead of "MUST" comes from the fact that, if no such
route exists, but the ingress BR is the endpoint of RSVP-TE tunnels from other
PEs, and the UMH routes use those tunnels, then those PEs can construct the VRF
Route Import EC as described in the draft.
> 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.
What if it's not the preferred route on an egress PE, but the implementation on
that PE can still make use of it? I think that should be allowed.
>
> 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 ;-)
OK. I think your preference is make it standard track, and optionally document
the special scenario in an informational spec.
>
> 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).
Yes it does modify the default, though using a non-default RT is also allowed.
>
> 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 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.
Indeed. As mentioned above, we should change the default behavior (in this
draft) that non-zero RDs should be used in the A-D routes.
>
> 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.
6.1.2 talks about three things:
1) Add VRF Route Import EC to unicast routes
2) Inter-area P2MP Segmented Next-Hop Extended Community
3) Determine Ingress PE and then upstream node
I assume you're referring to 1). I missed stating it explicitly, though I did
imply it in section 3.1 and 3.2. I will add it.
Thanks.
Jeffrey
