Re: Comments on draft-raggarwa-l3vpn-bgp-mvpn-extranet-00.txt

[Yakov Rekhter <yakov at juniper.net>]

Eric,

> I have a number of comments on this draft.  I've placed them in-line, look
> for lines beginning with ****.

response in-line...

> 2. Introduction
> 
>    This document describes clarifications to the procedures in [BGP-
> 
> **** Fess up, the document specifies new procedures, not merely
> **** "clarifications" to procedures already specified ;-)  I don't think
> **** there's any reason to try to hide that.
> 
> **** Most of the procedures are analogous (as well they should be) to
> **** procedures described in section 8 of draft-rosen-l3vpn-mvpn-mspmsi-
> **** 04.txt ("extranet with PIM control plane".  There are a few differences
> **** that are worthy of discussion.
> 
>    MVPN] for supporting extranets. The procedures specified in this
>    document assume that BGP is used for transmission of MVPN customers'
>    multicast routing information within the service provider(s)
>    infrastructure [BGP-MVPN].
> 
>    The extranet functionality is a requirement of RFC4834 [RFC4834]
>    (section 5.1.6) and allows a VPN site to receive or send multicast
>    traffic from sites (or to sites) of another VPN.
> 
> 3. Extranet Service Model
> 
>    In the context of MVPN the term "extranet" refers to the ability for
>    multicast sources in one VPN to send multicast traffic to multicast
>    receivers in other VPN(s). Such multicast sources are referred to as
>    "extranet sources". The multicast groups to which the extranet
>    sources generate traffic are referred to as "extranet groups". The
>    receivers that receive multicast traffic from extranet sources are
>    referred to as "extranet receivers".
> 
>    The IP addresses used by extranet sources MUST NOT overlap with the
> **** "extranet sources and RPs", I think.

That is correct. It is reflected in the -01 version.

>    IP addresses used by VPNs that receive multicast traffic from such
>    sources.
> 
> **** I think this is too strong a restriction.  Suppose company X is
> **** providing some content to company Y and some entirely different content
> **** to company Z.  And suppose this is done in source-specific mode (SSM),
> **** where Y gets its content from X's source S1 and Z gets its content from
> **** X's source S2.
> 
> **** Clearly Y cannot have its own "intranet" system with source address S1,
> **** and Z cannot have its own "intranet" system with source address S2.
> **** Let's call this the "weak overlap restriction".  Violation of the weak
> **** overlap restriction would cause the address S1 to be ambiguous in VPN Y
> **** and would cause the address S2 to be ambiguous in VPN Z.
> 
> **** However, the draft poses a stronger restriction, viz., that Y should
> **** not be able to have an intranet source S2 and that Z should not be able
> **** to have an intranet source S1. Let's call this the "strong" overlap
> **** restriction.
> 
> **** I don't think the strong overlap restriction is either necessary or
> **** desirable.  As long as the weak overlap restriction is in effect,
> **** there's no reason why VPN Y should not have an intranet system with
> **** address S2 or who VPN Z should not have an intranet system with address
> **** S1.  No ambiguity would result.
> 
> **** If I were the SP connecting X, Y, and Z, I don't think I would want to
> **** tell company Y "sorry, you can't use address S2 in your internal
> **** network, because X is using S2 to send content to Z".  The folks over
> **** at company Y will probably say "we don't care what X uses to send
> **** content to Z, what does that have to do with us?"  So I'm not sure the
> **** strong overlap restriction is deployable in practice.

The "weak overlap restriction" is not sufficient. To illustrate
why, consider a scenario where both company X and company Y provide
some (multicast) content to company Z, and assume that this is done
in the SSM mode, where Z receives its content from X's source S1,
and from Y's source S2. In this case S1 can not be the same as S2,
and this constrain is not covered by the "weak overlap restriction".

See also -01 version, as it clarifies this issue.

> **** The procedures in section 8 of draft-rosen-l3vpn-mvpn-mspmsi do not
> **** have the strong address restriction, but only the weak one.

First of all, reading section 8 of draft-rosen-l3vpn-mvpn-mspmsi
I was not able to find any references to the "weak" restriction. 

Second, as I illustrated above, the "weak" restriction is not sufficient.
  
>    Moreover, in the case of PIM-SM in ASM mode addresses used
>    by extranet groups MUST NOT overlap with the group addresses used by
>    VPNs that have receivers for the extranet groups.
> 
> **** Again, this seems too strong.  In a given VPN, a given group address
> **** either has extranet sources or it doesn't.  But I don't see why the SP
> **** should tell company Y "you can't use group address G internally; X is
> **** already using G to talk to Z".

If both X and Y provide *two* different contents to Z using ASM,
and if X uses C-G1, and Y uses C-G2, then C-G1 can not be the same
as C-G2, as otherwise Z would not be able to distinguish between
the two.

See also -01 version, as it clarifies this issue.

> 4. Routing Exchange in Support of Extranets
> 
>    VRFs in the VPN that wish to access multicast extranet sources in
>    other VPNs MUST be able to import the "necessary" unicast and BGP
>    MVPN auto-discovery routes advertised by other PEs for VPNs that
>    contain the extranet sources.
> 
>    The "necessary" routes are the routes required by VRFs to receive
>    multicast traffic for extranet sources and groups from other VPNs.
>    This includes unicast VPN-IP routes to extranet sources, as well as
>    BGP MVPN Source Active auto-discovery routes for extranet sources and
>    groups.  It also includes Intra-AS, Inter-AS and S-PMSI auto-
>    discovery routes that carry P-Tunnel attributes for P-Tunnels used by
>    the other VPNs for sending multicast traffic for multicast sources
>    and groups.  Following describes procedures that ensure that the
>    necessary routes can be imported.
> 
>    Case 1: PIM-SM in SSM mode. In this scenario a necessary condition
>    for (C-S,C-G) traffic received on a particular VRF to be forwarded
>    downstream is for the VRF to have a VPN-IP route to C-S. In other
> 
> **** It took me a little while to understand what "received on a particular
> **** VRF" means.  I think "received on a particular VRF" is supposed to mean
> **** "received on an interface not associated with the VRF", i.e., received
> **** from the backbone or from a local interface that is associated with a
> **** different VRF.  I also think "forwarded downstream" means "forwarded
> **** over an interface that is associated with the VRF".  Is that a correct
> **** interpretation? 

Yes, this is correct interpretation.

>    words the route to C-S must be advertised in the extranet. If this
>    condition is not satisfied the traffic is discarded by the VRF when
>    received from a CE.
> 
> **** "Discarded by the VRF"?  Do you mean that the traffic is discarded
> **** before it is seen by the VRF's C-PIM instance, or that it is processed
> **** by the C-PIM instance and then discarded as having come from the wrong
> **** RPF interface"?
>
> **** It seems to me that case 1 does not "describe procedures that ensure
> **** that the necessary routes can be imported", as was promised in the
> **** paragraph before case 1.  It describes a procedure for discarding
> **** packets when the necessary routes have not been imported.

See -01 version.
  
>    Case 2: PIM-SM in ASM mode. To fit the ASM model, if a given C-G is
>    in the extranet, then the C-RP for that C-G and all the C-Ss sending
>    to that C-G should be in the extranet as well (or to be more precise,
>    all the VPN-IP routes to C-RP and these C-Ss have to advertised in
>    the extranet). Note that for a given C-G that is part of the extranet
>    formed by several VPNs, C-Ss for that C-G may be present in any of
>    these VPNs.
> 
> **** This is the strong overlap restriction again.

No, it is not - it just allows sources for a given (extranet) group
C-G that is in the ASM range to be located in multiple MVPNs. 

>    VRFs connected to the sites that have extranet receivers for a given
>    extranet source MUST be able to import a VPN-IP route to that source.
>    This could be accomplished by either (a) setting the appropriate RTs
>    that control import of VPN-IP routes on the VRFs connected to the
>    receivers, or (b) setting the appropriate RTs that control export of
>    VPN-IP routes on the VRF connected to the source.
> 
> **** In the likely case that you only want a VRF connected to extranet
> **** receivers to import a select set of routes from the other VPN, you
> **** likely need a separate 'extranet' RT as import RT for the VRF, and a
> **** means of exporting the RT with specific routes at the sender VRF.
>
>    Note that as long as the Source Active auto-discovery routes and S-
>    PMSI auto-discovery routes use the default setting for their RTs,
>    setting up the appropriate RTs for VPN-IP routes, as described above,
>    would also result in the appropriate import of Source Active auto-
>    discovery routes, and S-PMSI auto-discovery routes.
>
> **** I'm not sure there's a default covering the case in which different
> **** VPN-IP routes carry different RTs.  A reference to the relevant section
> **** of [BGP-MVPN] would be useful.

See -01 version.

>    In addition, VRFs connected to the sites that have extranet receivers
>    for a given extranet source MUST be able to import I-PMSI auto-
>    discovery route originated by the VRF connected to the source. This
>    could be accomplished by either (a) setting the appropriate RTs that
>    control import of I-PMSI auto-discovery routes on the VRFs connected
>    to the receivers, or (b) setting the appropriate RTs that control
>    export of I-PMSI auto-discovery routes on the VRF connected to the
>    source.
>
> **** Note that if the A-D routes do not have at least one RT in common with
> **** the VPN-IP routes, then option 2 of section 6.2 will fail.  However,
> **** nothing in this section seems to require that the A-D routes and the
> **** VPN-IP routes have any RT in common.  I think the section requires that
> **** the A-D routes and the VPN-IP routes each get imported into a
> **** particular set of VRFs, but that doesn't require that they have any RT
> **** in common.

See -01 version.

>    If a given VRF connected to a given extranet source uses P2MP RSVP-TE
>    as an inclusive P-tunnel to carry (multicast) traffic from that
>    source, then this VRF MUST also be able to import intra-AS I-PMSI
>    auto-discovery routes originated by the VRFs connected to the sites
>    that have extranet receivers for that source.
> 
> **** If you use option 1 of section 6.1, then presumably there's an RSVP-TE
> **** P2MP LSP for intranet traffic, and a separate one for extranet
> **** traffic.  How does the headend PE know which of the other PEs need to
> **** be added to which of the two LSPs?

The headend PE knows this based on its import policies and the RTs carried 
by the intra-AS I-PMSI A-D routes originated by the other PEs.

> **** An overall comment on the structure of this section: note that unlike
> **** case 1, case 2 does discuss the import/export of the VPN-IP routes to
> **** the C-S or C-RP.  However, case 2 does not discuss the discard of
> **** packets when VPN-IP routes to the C-S or C-RP are not present in the
> **** VRF.  I'm not sure this way of organizing the text is right, as the
> **** topic (importing/exporting the right set of unicast routes) is not
> **** really any different for SSM than it is for ASM, and the rules for
> **** discarding multicast data packets when the necessary VPN-IP routes are
> **** not present also do not seem to be different for SSM than for ASM.
>
> 
> 5. Multicast Extranet over Selective P-tunnels
> 
>    Procedures in [BGP-MVPN] along with the routing exchange
>    clarifications described in the previous section, are sufficient to
>    support the scenario when the multicast extranet traffic is carried
>    over selective P-tunnels (P-tunnels advertised by S-PMSI auto-
>    discovery routes).
> 
> **** For aggregated S-PMSIs, I think this is only correct if the strong
> **** overlap restriction holds.  If only the weak overlap restriction holds,
> **** then we could have the following situation.  VPN1 might have (S1,G) and
> **** (S2,G) sources.  VPN2 might have (S1,G) sources, but might receive
> **** (S2,G) traffic from VPN1.  So VPN1 might transmit (S1,G) and (S2,G) on
> **** one aggregated S-PMSI, while VPN2 transmits (S1,G) on a different
> **** S-PMSI.  VPN2's receiving VRFs would have to know to discard the (S1,G)
> **** traffic from VPN1.  I think these discard procedures are the same that
> **** you need for option 2 of section 6.2.

See -01 version.
  
> 6. Multicast Extranet over Inclusive P-tunnels
> 
>    There are (at least) three possible ways to support extranet
>    multicast over inclusive P-tunnels.
> 
> **** Probably some text like that in section 8.5 of draft-rosen-l3vpn-mvpn-
> **** mspmsi is needed, to cover the case where extranet traffic flows from
> **** one VRF to another on the same PE.

See -01 version.
  
> 6.1. Option 1
> 
> **** I note that this is a model that is not discussed in section 8 of
> **** draft-rosen-l3vpn-mvpn-mspmsi.  
> 
>    Each VRF that has set of extranet sources being part of that VRF uses
>    not one, but two inclusive P-tunnels for sending multicast traffic.
>    The first one is used for sending multicast traffic from the non
>    extranet sources; the second is used for sending multicast traffic
>    from the extranet sources.   Each of these P-tunnels will be advertised
>    by its own I-PMSI auto-discovery route. Therefore, these two routes
>    MUST NOT use the same RD. The distribution scope of the second route
>    SHOULD include all the VRFs that are within the scope of the first
>    route, plus all the other VRFs that have the extranet receivers for
>    the extranet sources of the VRF that originates the route.
> 
> **** So if VPN X has any sources that have been designated as extranet
> **** sources, any VRF in VPN X needs to join two I-PMSIs.  Even the VRFs in
> **** X that do not need to receive the extranet traffic still need to join
> **** the extranet PMSI.  This doesn't seem right; why should a VRF have to
> **** join a second I-PMSI if it doesn't need to receive any traffic from
> **** outside its own VPN?

Even in the absence of any extranets, it is quite possible for a
VRF to receive (multicast) traffic on I-PMSI for which the VRF has
no downstream receivers. The situation above is no different.

> **** If VPN X needs to source some extranet traffic to VPN Y and some
> **** different extranet traffic to VPN Z, then we either need to ensure that
> **** the strong overlap restriction holds or else the receiver VRFs need to
> **** apply the packet discard procedure described in section 6.2.

The receiver VRFs need to apply the packet discard procedures
described in section 6.2. See -01 version.
  
>    To carry (C-S, C-G) multicast traffic the PE by default should use
>    the P-tunnel that has been advertised in the I-PMSI auto-discovery
>    route that has the same set of RTs as the VPN-IP route to C-S
>    advertised by the PE.
> 
> **** Some guidance covering the non-default case would be helpful ;-)
> 
>    A special case of this option is the scenario where the set of
>    extranet sources within a given VRF is the same as the set of
>    multicast sources within that VRF. In this case there is no need to
>    have two P-tunnels - one P-tunnel would suffice. As a result only one
>    I-PMSI auto-discovery route would need to be originated by that VRF.
> 
> 
> 6.2. Option 2
> 
> **** I believe this corresponds to the "red method" described in section 8.2
> **** of (you guessed it) draft-rosen-l3vpn-mvpn-mspmsi.
> 
>    Each VRF has just one inclusive P-tunnel that is used to send data
>    originated by the sites connected to that VRF. In this case if the
>    set of extranet multicast sources are part of that VRF, then all
>    other VRFs that are part of the extranet must be able to receive data
>    on that P-tunnel (all these VRFs must be able import the I-PMSI auto-
>    discovery route that advertises this P-tunnel).
> 
>    A VRF that is receiving traffic on an inclusive P-tunnel from the
>    extranet sources connected to another VRF may also receive on that P-
>    tunnel the non-extranet traffic from that VRF. Such traffic will be
>    dropped by the receiving VRF anyway if it doesn't have (C-S, C-G)
> 
> **** or (C-*,C-G) state

Correct. See -01 version.

>    forwarding state for this non-extranet traffic. The receiving VRF may
>    have forwarding state for such traffic if the address space for the
>    non-extranet sources connected to the sending VRF overlaps with the
>    address space of the sources in the receiving VRF's VPN. To take care
>    of this case the receiving VRF MUST be able to drop the non-extranet
>    traffic if it arrives on the unexpected P-Tunnel.  The following
>    describes how the unexpected P-Tunnel is determined.
> 
>    When the local PE receives from other PEs (multicast) traffic
>    corresponding to the (multicast) state advertised in the C-multicast
>    route originated by the local PE, the PE MUST discard (and not
>    forward) this traffic if it was received on a P-tunnel that is
>    advertised by an I-PMSI auto-discovery route whose RTs form an empty
>    intersection with the RTs carried in the VPN-IP route for the address
>    carried in the Multicast Source field of MCAST-VPN NLRI. This check
>    is in addition to the checks specified in section 9.1 of [MVPN-ARCH].
> 
> **** I don't think the check as stated is precisely correct.  I think the
> **** condition for NOT discarding traffic should be "the intersection of the
> **** set of RTs carried by the VPN-IP route and the set of RTs carried by
> **** the I-PMSI A-D route contains one of the import RTs of the VRF".  the
> **** intersection being non-null does not imply that both the A-D route and
> **** the VPN-IP route were actually imported into the VRF.

That is correct. See -01 version.

>    Note that for the above procedure to work, there should be a
>    consistent choice with respect to handling import/export of VPN-IP
>    routes and I-PMSI auto-discovery routes. That is, either (a) the
>    import/export of both types of routes should be controlled by setting
>    the appropriate RTs on the VRFs connected to the receivers, or (b)
>    the import/export of both types of routes should be controlled by
>    setting the appropriate RTs on the VRF connected to the source.
> 
> 
> **** I don't really follow this.  In this model, the multicast data traffic
> **** is carried in the I-PMSI of the VPN containing the transmitters, call
> **** it "VPN red".  If some other VPN, "VPN blue", has receivers then the
> **** blue VRFs have to be configured to import both red and blue routes.  I
> **** don't see how you can set this up properly without explicit
> **** configuration at the receiver end.
>
> **** It's highly unlikely that you will want the blue VRFs to import all the
> **** red routes, as this would allow blue hosts to unicast to red hosts.  So
> **** it's more likely you will need a distinct RT to mark the red routes
> **** that are supposed to be imported by the blue VRFs.  So there will
> **** generally be configuration at both ends.

Your claim about "there will generally be configuration at both ends" is
incorrect. This could be "set up properly without explicit configuration
at the receiver end" by (selectively) adding RT-blue to *some* of
the "red" routes. This way all the "blue" routes will carry RT-blue,
all the "red" routes will carry RT-red, and some of the "red" routes
will also carry RT-blue (in addition to RT-red).

> 7. Option 3
> 
>    Each VRF that has set of extranet multicast sources being part of
>    that VRF is a root of as many inclusive P-tunnels as the number of
>    MVPNs in the extranet. A given (C-S, C-G) multicast traffic has to be
>    sent over each of these P-tunnels. From the point of view of the
>    number of P-tunnels, and the amount of replication required this is
>    the least desirable option, and is included here just for the sake of
>    completeness.
> 
> **** This is essentially the "blue method" of section 8.3 of
> **** draft-...-mspmsi.  While this model does have the disadvantage of
> **** causing the ingress PE to transmit multicast data on two or more
> **** P-tunnels, it has the advantage of being the only option that does not
> **** require either (a) the strong overlap restriction, or (b) configuration
> **** at the receiver end.

Your claim that it is "the only option that does not require either
(a) the strong overlap restriction, or (b) configuration at the receiver
end" is incorrect, as other the options specified in the draft
require neither the strong overlap restriction, nor configuration at the
receiver end.

> **** We have found this model to be favored by providers who are managing
> **** content distribution, because they can configure just the transmitter
> **** end (the ingress PE) in order to determine which receivers are allowed
> **** to receive a given transmission.  To allow the content to be sent to a
> **** new VPN, the new VPN's RT just has to be added to the set of RTs
> **** carried by the routes originated by the ingress PE.

Note that this scenario assumes that *all* the sites on the new VPN
can receive the content. It does not cover the case where only
*some* of the sites in the new VPN can receive the content.

> **** This model has the further advantage of being the only model that
> **** delivers to the receiver VRFs only the extranet traffic that the
> **** receiver VRFs really need.  I.e., a receiver VRF in a given VPN
> **** doesn't get extranet  traffic that is for some other VPN , and it
> **** doesn't the intranet traffic of any other VPN.

The claimed advantage is incorrect. This is because since this model
uses I-PMSI, then *by definition* this model may result in a situation
where some of the VRFs will receive the extranet traffic that the
receivers in these VRFs do not need.

Your claim about "being the only model" is also incorrect. This is
because the S-PMSI model also accomplishes does in fact allow to
deliver to the receiver VRFs only the extranet traffic that the
receiver VRFs really need.
  
> **** For these reasons, I think this option is preferable to "option 1".
> 
> 11. References
> 
> 11.2. Informative References
> 
> **** I  think there is  sufficient overlap  with the  pre-existing "Extranet
> **** over PIM" material in  draft-rosen-...-mspmsi to warrant an informative
> **** reference to it.

On that we should agree to disagree. 

But your comments have been acknowledged in the -01 version.

Yakov.