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

From: Eric Rosen <[email-masked]>
Date: Mon, 04 Mar 2013 14:58:04 -0500

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.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 13 Mar 2013 22:51:02 +0000

Eric,

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

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Monday, March 04, 2013 2:58 PM
> To: L3VPN
> Subject: comments on draft-zzhang-mboned-mvpn-global-table-mcast-00.txt
> 

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.

>   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.

>   procedures governs the use of that particular Leaf A-D route.  This should

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

>   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.

>   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.

>   One could also ask whether Intra-AS I-PMSI A-D routes are really needed

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

>   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.

>   PIM-DM to be outside its scope.  I don't think the MVPN RFCs mention

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.

>   and to avoid terms like "RPF route" that are not precisely defined.

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

>   procedures", it would be better to mention this explicitly.

I'll mention it explicitly.
	
>      whose value is 64 bits of zero", but it would be better to say that.

Thanks for pointing that out. Will fix it.

>      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".

>   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.

>   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

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

>    to "src"?  If not, what is the next hop?

Yes it put itself as the next hop.

>     diagram, but otherwise I don't see why BR2's C-multicast routes should

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

>     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

Sure. Will come up with a better picture.

>     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.

>    draft, and that would certainly be a modification of the MVPN

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

>    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.

>     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.

>     draft should clearly state the applicability restrictions.

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

>     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).

>     but they should be, and I don't see how they can be exactly the same as

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

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?

>   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

---

From: Eric Rosen <[email-masked]>
Date: Thu, 21 Mar 2013 11:10:45 -0400

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:

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.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 25 Mar 2013 16:16:22 +0000

Eric,

> Sent: Thursday, March 21, 2013 11:11 AM
> To: Jeffrey (Zhaohui) Zhang
> Cc: Eric Rosen; [email-masked]
> Subject: Re: comments on draft-zzhang-mboned-mvpn-global-table-mcast-
> 00.txt
> 
> 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
> 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.

> 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:
> 
> 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.

> 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
>                 |         |
> 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.
> 
> 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.
> 
> 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.

> non-congruent to the unicast topology.  That needs to be stated

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.

> routes, without enabling and configuring SAFI-2, and even without
> adding the VRF Route Import EC to the UMH-eligible routes.
> 
> 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

Agreed.

> 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.

>   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.

>   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.

>   UMH-eligible routes, and at those egress PEs, it MUST be the preferred

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.

> 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.

> 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.

> 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