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

[Eric Rosen <erosen at cisco.com>]

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

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.

   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 procedures in section 8 of draft-rosen-l3vpn-mvpn-mspmsi do not
**** have the strong address restriction, but only the weak one.

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


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? 

   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.


   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.

   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.

   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.

   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?

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


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.


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?

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

   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

   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.

   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.


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.

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

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

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