tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7900

 
 
 

Extranet Multicast in BGP/IP MPLS VPNs

Part 3 of 3, p. 46 to 65
Prev RFC Part

 


prevText      Top      ToC       Page 46 
7.  When BGP Is the PE-PE C-Multicast Control Plane

   This document assumes that if BGP is used as the PE-PE C-multicast
   control plane, the "single PMSI per C-flow" model is used.
   Procedures for providing the "multiple PMSIs per C-flow" model with
   BGP C-multicast are outside the scope of this document.

   When BGP is used as the C-multicast control plane, the "single PMSI
   per C-flow" model may be used either with or without extranet
   separation.  (Recall that "extranet separation" means that no
   P-tunnel can carry traffic from both extranet sources and
   non-extranet sources.)  In either case, the data traffic may be
   carried on Inclusive Tunnels only, Selective Tunnels only (known as
   the "S-PMSI only" model), or a combination of Inclusive Tunnels and
   Selective Tunnels.  This is determined by provisioning.  The
   procedures specified below support all three choices.

   Note that there are no special extranet procedures for Inter-AS
   I-PMSI A-D routes or for Leaf A-D routes.

7.1.  Originating C-Multicast Routes

   This section applies whether extranet separation is used or not.

   When it is necessary to originate a C-multicast Source Tree Join for
   (C-S,C-G), a PE must follow the procedures of Section 11.1.3
   ("Constructing the Rest of the C-Multicast Route") of [RFC6514] to
   find the selected UMH route for C-S.  When it is necessary to
   originate a C-multicast Shared Tree Join for (C-*,C-G), where C-G is
   an ASM group, a PE must follow the procedures of that section to find
   the selected UMH route for C-G's C-RP.

   Section 11.1.3 of [RFC6514] specifies how information from the
   selected UMH route is used to find an Intra-AS I-PMSI A-D route or an
   Inter-AS I-PMSI A-D route.  Information from that I-PMSI A-D route is
   then used to construct part of the C-multicast route.

   For extranets, the rules given in Section 7.4.5 of this document are
   used to find the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D
   route that "corresponds" to the selected UMH route; the rules in
   Section 7.4.5 replace the rules given in Section 11.1.3 of [RFC6514]
   for finding the Inter-AS or Intra-AS I-PMSI A-D route.

   Information from this I-PMSI A-D route is then used, as specified in
   Section 11.1.3 of [RFC6514], to construct the C-multicast route.

Top      Up      ToC       Page 47 
7.2.  Originating A-D Routes without Extranet Separation

7.2.1.  Intra-AS I-PMSI A-D Routes

   Consider a VRF (call it "VRF-S") that contains extranet C-sources and
   exports UMH-eligible routes matching those C-sources.  The VRF may
   also originate and export an Intra-AS I-PMSI A-D route.

   As specified in [RFC6514], if exactly one Intra-AS I-PMSI A-D route
   is originated by and exported from VRF-S, the RTs carried by that
   route MUST be chosen such that every VRF that imports a UMH-eligible
   route from VRF-S also imports this Intra-AS I-PMSI A-D route.

   If inclusive P-tunnels are being used to carry extranet C-flows,
   there are additional requirements on the way the RTs carried by the
   Intra-AS I-PMSI A-D routes must be chosen, as specified in the
   following paragraph.

   If VRF-S is using inclusive P-tunnels but is not using extranet
   separation, there is one inclusive P-tunnel rooted at VRF-S, and this
   tunnel carries both extranet and non-extranet C-flows.  This
   Inclusive Tunnel is identified in the PTA of the Intra-AS I-PMSI A-D
   route originated from VRF-S.  The set of RTs carried by this Intra-AS
   I-PMSI A-D route MUST be chosen so as to ensure that every VRF that
   imports a UMH-eligible route from this VRF-S also imports this
   Intra-AS I-PMSI A-D route.  Further, the set of RTs carried by this
   Intra-AS I-PMSI A-D route MUST be chosen such that it has at least
   one RT in common with every UMH-eligible route that is exported from
   the VRF.

7.2.2.  S-PMSI A-D Routes

   Let R-SP be an S-PMSI A-D route that is exported from VRF-S.  Suppose
   that R-SP is used to bind some or all of the extranet C-flows from a
   given extranet C-source to a given selective P-tunnel.  Let R-UMH be
   a UMH-eligible route that is exported from VRF-S and matches the
   given extranet C-source.  In that case, R-SP and R-UMH MUST have at
   least one RT in common.  Further, the RTs carried by these two routes
   MUST be such that every VRF that imports R-UMH also imports R-SP.
   These rules apply whether or not R-SP uses wildcards [RFC6625].

Top      Up      ToC       Page 48 
   An implementation MUST allow the set of RTs carried by the S-PMSI A-D
   routes to be specified by configuration.  In the absence of such
   configuration, an S-PMSI A-D route originated by a given VRF, say
   VRF-X, MUST carry a default set of RTs, as specified by the following
   rules:

   1.  By default, an S-PMSI A-D route originated by VRF-X for a given
       (C-S,C-G) or (C-S,C-*) carries the same RT(s) as the UMH-eligible
       route originated by VRF-X that matches C-S.

   2.  By default, an S-PMSI A-D route originated by VRF-X for a given
       (C-*,C-G) carries as its RTs a set union of all RT(s) of the
       UMH-eligible route(s) matching the multicast C-sources contained
       in VRF-X that could originate traffic for that C-G.  Moreover, if
       the VRF contains (as defined in Section 1.1) the C-RP of C-G,
       then this set union also includes the RT(s) of the UMH-eligible
       route matching C-RP and the RT(s) of the unicast VPN-IP route
       matching C-RP.

   3.  By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X
       is to be used for both extranet and non-extranet traffic, it
       carries the same RTs that would be carried (as specified in
       Section 7.2.1) by an I-PMSI A-D route originated by VRF-X if that
       I-PMSI A-D route were advertising an inclusive P-tunnel for
       carrying both extranet and non-extranet traffic.  In general, a
       given VRF would not originate both (a) an S-PMSI A-D route
       advertising a (C-*,C-*) selective P-tunnel for both extranet and
       non-extranet traffic and (b) an I-PMSI A-D route advertising an
       inclusive P-tunnel for both extranet and non-extranet traffic, as
       the inclusive P-tunnel would not get used in that case.

7.2.3.  Source Active A-D Routes

7.2.3.1.  When Inter-Site Shared Trees Are Used

   This section applies when inter-site shared trees are used, as
   specified in Section 13 of [RFC6514].

   If VRF-S exports a Source Active A-D route that contains C-S in the
   Multicast Source field of its NLRI and VRF-S also exports a
   UMH-eligible route matching C-S, the Source Active A-D route MUST
   carry at least one RT in common with the UMH-eligible route.  The RT
   MUST be chosen such that the following condition holds: if a VRF, say
   VRF-R, contains an extranet C-receiver allowed by policy to receive
   extranet traffic from C-S, then VRF-R imports both the UMH-eligible
   route and the Source Active A-D route.

Top      Up      ToC       Page 49 
   By default, a Source Active A-D route for a given (C-S,C-G), exported
   by a given VRF, carries the same set of RTs as the UMH-eligible route
   matching C-S that is exported from that VRF.

7.2.3.2.  When Inter-Site Shared Trees Are Not Used

   This section applies when inter-site shared trees are not used, as
   specified in Section 14 of [RFC6514].

   Suppose that a VRF, say VRF-X, contains the C-RP for a given extranet
   C-group, say C-G.  If C-S is an active source for C-G, then,
   following the procedures of Section 14.1 of [RFC6514], VRF-X may
   export a Source Active A-D route that contains C-S in the Multicast
   Source field of its NLRI.  With the following text, this document
   replaces the rule specified in Section 14.1 of [RFC6514] for
   constructing the RT(s) carried by such a route: VRF-X MUST be
   configured such that the Source Active A-D route for (C-S,C-G)
   carries the same set of RTs as the UMH-eligible route matching C-S
   that is exported from the VRF(s) containing C-S.  This way, if a VRF,
   say VRF-R, contains an extranet C-receiver allowed by policy to
   receive extranet traffic from C-S, then VRF-R imports both the
   UMH-eligible route and the Source Active A-D route.

7.3.  Originating A-D Routes with Extranet Separation

   If a VRF contains both extranet C-sources and non-extranet C-sources,
   it MUST be configured with both a default RD and an extranet RD (see
   Section 1.3).  The use of these RDs is explained in the following
   subsections.

7.3.1.  Intra-AS I-PMSI A-D Routes

   This section applies when VRF-S is using extranet separation AND when
   VRF-S is using an inclusive P-tunnel to carry some or all of the
   extranet C-flows that it needs to transmit to other VRFs.

   If VRF-S contains both extranet C-sources and non-extranet C-sources,
   and inclusive P-tunnels are used to carry both extranet C-flows and
   non-extranet C-flows, then there MUST be two Inclusive Tunnels from
   VRF-S, one of which is to be used only to carry extranet C-flows (the
   "extranet inclusive P-tunnel") and one of which is to be used only to
   carry non-extranet C-flows (the "non-extranet inclusive P-tunnel").

Top      Up      ToC       Page 50 
   In this case, the VRF MUST originate two Intra-AS I-PMSI A-D routes.
   Their respective NLRIs MUST of course have different RDs.  One of the
   Intra-AS I-PMSI A-D routes identifies the extranet inclusive P-tunnel
   in its PTA.  This route MUST have the VRF's extranet RD in its NLRI.
   The other route identifies the non-extranet inclusive P-tunnel in its
   PTA.  This route MUST have the VRF's default RD in its PTA.

   If VRF-S uses an inclusive P-tunnel for carrying extranet traffic but
   does not use an inclusive P-tunnel for carrying non-extranet traffic,
   then of course only a single Intra-AS I-PMSI A-D route need be
   originated.  The PTA of this route identifies the "extranet inclusive
   P-tunnel".  The NLRI of that route MUST contain the VRF's
   extranet RD.

   An Intra-AS I-PMSI A-D route whose PTA identifies an extranet
   inclusive P-tunnel MUST carry the Extranet Separation Extended
   Community defined in Section 4.5.

   The RTs carried by an Intra-AS I-PMSI A-D route whose PTA identifies
   the "extranet inclusive P-tunnel" MUST be chosen such that the
   following condition holds: if a VRF (call it "VRF-R") imports a
   UMH-eligible route from VRF-S and that route matches an extranet
   C-source, then VRF-R also imports that Intra-AS I-PMSI A-D route.

   Note that when extranet separation is used, it is possible to use an
   inclusive P-tunnel for non-extranet traffic while using only
   selective P-tunnels for extranet traffic.  It is also possible to use
   an inclusive P-tunnel for extranet traffic while using only selective
   P-tunnels for non-extranet traffic.

7.3.2.  S-PMSI A-D Routes

   Let R-SP be an S-PMSI A-D route that is exported from VRF-S.  Suppose
   that R-SP is used to bind some or all of the extranet C-flows from a
   given extranet C-source to a given selective P-tunnel.  Let R-UMH be
   a UMH-eligible route that is exported from VRF-S and matches the
   given extranet C-source.  In that case, R-SP and R-UMH MUST have at
   least one RT in common.  Further, the RTs carried by these two routes
   MUST be such that every VRF that imports R-UMH also imports R-SP.
   These rules apply whether or not R-SP uses wildcards [RFC6625].

Top      Up      ToC       Page 51 
   The following rules, specific to the use of extranet separation,
   apply:

   o  A selective P-tunnel MUST NOT carry C-flows from both extranet and
      non-extranet C-sources.

   o  If it is desired to use a (C-*,C-*) S-PMSI to carry extranet
      traffic and also use a (C-*,C-*) S-PMSI to carry non-extranet
      traffic, then two (C-*,C-*) S-PMSI A-D routes MUST be originated.
      These two routes MUST have different RDs in their respective NLRI
      fields, and their respective PTAs MUST identify different
      P-tunnels.  If the route advertises a P-tunnel that carries only
      non-extranet traffic, the route's NLRI MUST contain the VRF's
      default RD.  If the route advertises a P-tunnel that carries only
      extranet traffic, the route's NLRI MUST contain the VRF's
      extranet RD.

   o  In the following cases, an S-PMSI A-D route exported from the VRF
      MUST have the VRF's extranet RD in its NLRI:

      *  The S-PMSI A-D route is a (C-S,C-G) or a (C-S,C-*) S-PMSI A-D
         route, and C-S is an extranet C-source.

      *  The S-PMSI A-D route is a (C-*,C-G) S-PMSI A-D route, and C-G
         is an extranet C-group.

      In all other cases, a (C-S,C-G), (C-S,C-*), or (C-*,C-G) S-PMSI
      A-D route MUST have the VRF's default RD in its NLRI.

   o  A (C-*,C-*) S-PMSI A-D route advertising a P-tunnel that is used
      to carry extranet traffic MUST carry the Extranet Separation
      Extended Community defined in Section 4.5.

   An implementation MUST allow the set of RTs carried by the S-PMSI A-D
   routes to be specified by configuration.  In the absence of such
   configuration, an S-PMSI A-D route originated by a given VRF, say
   VRF-X, MUST carry a default set of RTs, as specified by the following
   rules:

   1.  Rule 1 of Section 7.2.2 applies.

   2.  By default, if C-G is an extranet C-group, rule 2 of
       Section 7.2.2 applies.

   3.  By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X
       is to be used for extranet traffic, it carries the same RTs that
       would be carried (as specified in Section 7.3.1) by an I-PMSI A-D
       route originated by VRF-X if that I-PMSI A-D route were

Top      Up      ToC       Page 52 
       advertising an inclusive P-tunnel for carrying extranet traffic.
       In general, a given VRF would not originate both an S-PMSI A-D
       route advertising a (C-*,C-*) selective P-tunnel for extranet
       traffic and an I-PMSI A-D route advertising an inclusive P-tunnel
       for extranet traffic, as the inclusive P-tunnel would not get
       used in that case.

7.3.3.  Source Active A-D Routes

   The procedures of Section 7.2.3 apply.

   However, if a Source Active A-D route is exported from a given VRF
   and the route contains C-S, where C-S is an extranet C-source, then
   the RD of the route's NLRI MUST be the extranet RD of the VRF.
   Otherwise, the RD is the default RD of the VRF.

7.4.  Determining the Expected P-Tunnel for a C-Flow

   This section applies whether extranet separation is used or not.

   In the context of a VRF with receivers for a particular C-flow, a PE
   must determine the P-tunnel over which packets of that C-flow are
   expected to arrive.  This is done by finding an I-PMSI or S-PMSI A-D
   route that "matches" the flow.  The matching A-D route will contain a
   PTA that specifies the P-tunnel being used to carry the traffic of
   that C-flow.  We will refer to this P-tunnel as the "expected
   P-tunnel" for the C-flow.  (Note that, per [MVPN-IR], if the PTA
   specifies a tunnel of type "Ingress Replication" (IR), the identifier
   of the P-tunnel is actually the NLRI of the I-PMSI or S-PMSI A-D
   route.  If the PTA specifies a tunnel type other than IR, the
   identifier of the P-tunnel is found in the Tunnel Identifier field of
   the PTA.)

   A PE that needs to receive a given (C-S,C-G) or (C-*,C-G) C-flow MUST
   join the expected P-tunnel for that C-flow, and the PE MUST remain
   joined to the P-tunnel as long as (1) the PE continues to need to
   receive the given C-flow and (2) the P-tunnel continues to remain the
   expected P-tunnel for that C-flow.  Procedures for joining and
   leaving a tunnel depend, of course, on the tunnel type.

   If a PTA specifies a non-zero MPLS label for a tunnel that is not an
   IR tunnel, then the PE originating the A-D route containing that PTA
   is advertising an aggregate P-tunnel.  The aggregate P-tunnel can be
   thought of as an outer P-tunnel multiplexing some number of inner
   P-tunnels.  The inner P-tunnels are demultiplexed by means of the
   MPLS label in the PTA.  In this document, when we talk of the
   "expected P-tunnel" in the context of an aggregate P-tunnel, we refer

Top      Up      ToC       Page 53 
   to a particular inner P-tunnel, not to the outer P-tunnel.  It is
   this "inner P-tunnel" that is the expected P-tunnel for a given
   C-flow.

   In order to find the expected P-tunnel for a given C-flow, the
   upstream PE of the C-flow is first determined.  Then, the S-PMSI A-D
   routes originated by that PE are examined, and their NLRIs compared
   to the (C-S/C-RP,C-G) of the flow, to see if there is a "match for
   reception".  (If there is no S-PMSI A-D route that matches a given
   C-flow, the expected P-tunnel for that C-flow may have been
   advertised in an I-PMSI A-D route; see Section 7.4.5.)

   The rules for determining, in non-extranet cases, whether a given
   C-flow is a "match for reception" for a given S-PMSI A-D route are
   given in Section 3.2 of [RFC6625].  Note that we use the terms
   "installed" and "originated" as they are defined in Section 3.2 of
   [RFC6625].  (See also Section 1.1 of this document.)

   This specification provides additional rules for determining whether
   a given S-PMSI A-D route is a "match for reception" for a given
   (C-S/C-RP,C-G).  Note that these rules all assume the context of a
   particular VRF into which the A-D route has been imported.

   The rules given in [RFC6625] for determining whether a given S-PMSI
   A-D route is a "match for transmission" remain unchanged.

   Suppose that a PE has originated a C-multicast Shared Tree Join for
   (C-*,C-G) but has not originated a C-multicast Source Tree Join for
   (C-S,C-G).  Suppose also that the PE has received and installed a
   Source Active A-D route for (C-S,C-G).  As described in Section 13.2
   of [RFC6514], the PE must receive the (C-S,C-G) traffic from the
   tunnel the originator of the installed Source Active A-D route uses
   for sending (C-S,C-G).

   The originator of the installed Source Active A-D route is determined
   as follows:

   1.  Look at the "UMH Route Candidate Set" for C-S, as defined in
       Section 5.1.3 of [RFC6513].

   2.  From that set, select a subset of UMH routes to C-S, such that
       each route in the subset has at least one RT in common with the
       Source Active A-D route and at least one of the RTs in common is
       an import RT of the VRF.

   3.  From that subset, find the route whose RD is the same as the RD
       from the NLRI of the Source Active A-D route.

Top      Up      ToC       Page 54 
   4.  The upstream PE is the PE identified in the VRF Route Import
       Extended Community of that route.

   5.  The upstream AS is the AS identified in the Source AS Extended
       Community of that route.

   If step 2 results in an empty set or step 3 fails to find a route,
   then the upstream PE of the Source Active A-D route cannot be
   determined, and it is necessary to act as if the Source Active A-D
   route had not been installed.  (A subsequent change to the UMH Route
   Candidate Set for C-S may require that a new attempt be made to
   determine the upstream PE.)

   Once the upstream PE is determined, the P-tunnel over which the flow
   is expected is determined according to the procedures already
   described in this section.

7.4.1.  (C-S,C-G) S-PMSI A-D Routes

   When extranet functionality is being provided, an S-PMSI A-D route
   whose NLRI contains (C-S,C-G) is NOT considered to be a "match for
   reception" for a given C-flow (C-S,C-G) unless one of the following
   conditions holds (in addition to the conditions specified in
   [RFC6625]):

   o  the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is
      provisioned, or

   o  the selected UMH route for C-S has at least one RT in common with
      the S-PMSI A-D route, and at least one of the common RTs is an
      import RT of the VRF.

7.4.2.  (C-S,C-*) S-PMSI A-D Routes

   When extranet functionality is being provided, an S-PMSI A-D route
   whose NLRI contains (C-S,C-*) is NOT considered to be a "match for
   reception" for a given C-flow (C-S,C-G) unless one of the following
   conditions holds (in addition to the conditions specified in
   [RFC6625]):

   o  the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is
      provisioned, or

   o  the selected UMH route for C-S has at least one RT in common with
      the S-PMSI A-D route, and at least one of the common RTs is an
      import RT of the VRF.

Top      Up      ToC       Page 55 
7.4.3.  (C-*,C-G) S-PMSI A-D Routes

   When extranet functionality is being provided, an S-PMSI A-D route
   whose NLRI contains (C-*,C-G) is NOT considered to be a "match for
   reception" for a given C-flow (C-S,C-G) in a given VRF unless either
   condition 1 or condition 2 below holds (in addition to the conditions
   specified in [RFC6625]):

   1.  The given VRF has currently originated a C-multicast Shared Tree
       Join route for (C-*,C-G), and

       a.  (C-*,C-G) matches an installed (C-*,C-G) S-PMSI A-D route
           (according to [RFC6625]) in the given VRF, and

       b.  either

           i.     the "single C-group per (C-*,C-G) P-tunnel" policy has
                  been provisioned, or

           ii.    the RTs of that S-PMSI A-D route form a non-empty
                  intersection with the RTs carried in the VRF's
                  selected UMH route for C-RP of that C-G, or

           iii.   installed in the VRF is at least one (C-S,C-G) Source
                  Active A-D route that was originated by the same PE as
                  the (C-*,C-G) S-PMSI A-D route.

   2.  The given VRF does not have a currently originated C-multicast
       Shared Tree Join for (C-*,C-G), but

       a.  there are one or more values for C-S for which the VRF has a
           currently originated Source Tree Join C-multicast route for
           (C-S,C-G), and

       b.  the (C-* C-G) S-PMSI A-D route matches (according to
           [RFC6625]) each such (C-S,C-G), and

       c.  either

           i.    the "single C-group per (C-*,C-G) P-tunnel" policy has
                 been provisioned, or

           ii.   the RTs of that S-PMSI A-D route form a non-empty
                 intersection with the RTs carried in the VRF's selected
                 UMH routes for each such C-S

Top      Up      ToC       Page 56 
       If a VRF has an installed (C-*,C-G) S-PMSI A-D route but does not
       have a (C-S,C-G) or (C-*,C-G) multicast state that matches that
       route for reception, the procedures of Section 12.3 ("Receiving
       S-PMSI A-D Routes by PEs") of [RFC6514] are not invoked for that
       route.  If those multicast states are created at some later time
       when the route is still installed, the procedures of Section 12.3
       of [RFC6514] are invoked at that time.

7.4.4.  (C-*,C-*) S-PMSI A-D Routes

   A (C-*,C-*) S-PMSI A-D route (call it "R-AD") is NOT considered to be
   a "match for reception" for a given C-flow (C-S,C-G) or (C-*,C-G)
   unless the following conditions hold (in addition to the conditions
   specified in [RFC6625]):

   o  The selected UMH route (call it "R-UMH") for C-S or for C-G's
      C-RP, respectively, has at least one RT in common with R-AD, and
      at least one of the common RTs is an import RT of the VRF.

   o  Either R-AD and R-UMH both carry the Extranet Separation Extended
      Community or neither carries the Extranet Separation Extended
      Community.

7.4.5.  I-PMSI A-D Routes

   If a particular egress VRF in a particular egress PE contains no
   matching S-PMSI A-D routes for a particular C-flow, then the C-flow
   is expected to arrive (at that egress VRF) on an inclusive P-tunnel.

   Suppose that an egress PE has originated a (C-S,C-G) C-multicast
   Source Tree Join.  Let R-UMH be the selected UMH route (in the given
   egress VRF) for C-S.  As specified in [RFC6514], the selected
   upstream PE for (C-S,C-G) is determined from the VRF Route Import
   Extended Community of R-UMH, and the "selected upstream AS" for the
   flow is determined from the Source AS Extended Community of R-UMH.

   Suppose that an egress PE has originated a (C-*,C-G) C-multicast
   Shared Tree Join but has not originated a (C-S,C-G) C-multicast
   Source Tree Join.  If the egress VRF does not have a (C-S,C-G) Source
   Active A-D route installed, the selected upstream PE is determined
   from the VRF Route Import Extended Community of the installed
   UMH-eligible route matching C-RP, where C-RP is the RP for the group
   C-G.  The selected upstream AS for the flow is determined from the
   Source AS Extended Community of that route.  If the egress VRF does
   have a (C-S,C-G) Source Active A-D route installed, the selected
   upstream PE and upstream AS are determined as specified in
   Section 7.4.  In either case, let R-UMH be the installed UMH-eligible
   route matching C-S.

Top      Up      ToC       Page 57 
   The inclusive P-tunnel that is expected to be carrying a particular
   C-flow is found as follows:

   o  If the selected upstream AS is the local AS or segmented Inter-AS
      P-tunnels are not being used to instantiate I-PMSIs, then look in
      the VRF for an installed Intra-AS I-PMSI A-D route, R-AD, such
      that (a) R-AD is originated by the selected upstream PE, (b) R-AD
      has at least one RT in common with R-UMH, (c) at least one of the
      common RTs is an import RT of the local VRF, and (d) either R-AD
      and R-UMH both carry the Extranet Separation Extended Community or
      neither carries the Extranet Separation Extended Community.

      The PTA of R-AD specifies the P-tunnel over which the traffic of
      the given C-flow is expected.

   o  If the selected upstream AS is not the local AS and segmented
      Inter-AS P-tunnels are being used to instantiate I-PMSIs, then
      look in the VRF for an installed Inter-AS I-PMSI A-D route, R-AD,
      such that (a) the Source AS field of R-AD's NLRI contains the AS
      number of the selected upstream AS, (b) R-AD has at least one RT
      in common with R-UMH, (c) at least one of the common RTs is an
      import RT of the local VRF, and (d) either R-AD and R-UMH both
      carry the Extranet Separation Extended Community or neither
      carries the Extranet Separation Extended Community.

      The PTA of R-AD specifies the P-tunnel over which the traffic of
      the given C-flow is expected.

7.5.  Packets Arriving from the Wrong P-Tunnel

   Any packets that arrive on a P-tunnel other than the expected
   P-tunnel (as defined in Section 7.4) MUST be discarded unless it is
   known that all the packets carried by both P-tunnels are from the
   same ingress VRF.  (See Section 2.3.1 for a more detailed discussion
   of when to discard packets from other than the expected P-tunnel.)
   Note that packets arriving on the wrong P-tunnel are to be discarded
   even if they are arriving from the expected PE.

8.  Multiple Extranet VRFs on the Same PE

   When multiple VRFs that contain extranet receivers for a given
   extranet source are present on the same PE, this PE becomes a single
   leaf of the P-tunnel used for sending (multicast) traffic from that
   source to these extranet receivers.  The PE MUST be able to replicate
   this traffic to the multiple VRFs.  Specific procedures for doing so
   are local to the PE and are outside the scope of this document.

Top      Up      ToC       Page 58 
   Two or more VRFs on the same PE may import the same S-PMSI A-D route.
   If this S-PMSI A-D route contains a PTA that has its "Leaf
   Information Required" flag set, it may be necessary for the PE to
   originate a Leaf A-D route whose NLRI is computed from the NLRI of
   the S-PMSI A-D route.  (Details are provided in [RFC6514].)  Note
   that for a given S-PMSI A-D route, the PE can originate only one
   corresponding Leaf A-D route, even if the S-PMSI A-D route is
   imported into multiple VRFs.  This Leaf A-D route can thus be thought
   of as originating from several VRFs.  It MUST NOT be withdrawn by the
   PE until there are no longer any VRFs originating it.

   [RFC6514] specifies conditions under which a PE originates a
   C-multicast Source Tree Join or a C-multicast Shared Tree Join, based
   on the (*,G) and (S,G) states associated with a given VRF.  It also
   specifies the procedure for computing the NLRI of each such route.
   While a given PE may contain two or more VRFs that have (extranet)
   receivers for the same extranet C-flow, the PE cannot originate more
   than one BGP route with a given NLRI.  If there are multiple VRFs,
   each of which has state that is sufficient to cause a given
   C-multicast route to be originated, the route can be thought of as
   originating from several VRFs.  It MUST NOT be withdrawn by the PE
   until there is no longer any VRF with multicast state sufficient to
   cause the route to be originated.

   For a given extranet, the site(s) that contains the extranet
   source(s) and the site(s) that contains the extranet receiver(s) may
   be connected to the same PE.  In this scenario, the procedures by
   which (multicast) traffic from these sources is delivered to these
   receivers are local to the PE and are outside the scope of this
   document.

   An implementation MUST support multiple extranet VRFs on a PE.

9.  IANA Considerations

   IANA has allocated two new codepoints from the "First Come First
   Served" [RFC5226] range of the "Transitive Opaque Extended Community
   Sub-Types" registry (under the top-level registry "Border Gateway
   Protocol (BGP) Extended Communities" registry).

   o  Extranet Source Extended Community (0x04)

   o  Extranet Separation Extended Community (0x05)

Top      Up      ToC       Page 59 
10.  Security Considerations

   The security considerations of [RFC6513] and [RFC6514] are
   applicable.

   As is the case with any application of technology based upon
   [RFC4364], misconfiguration of the RTs may result in VPN security
   violations (i.e., may result in a packet being delivered to a VPN
   where, according to policy, it is not supposed to go).

   In those cases where the set of extranet sources of a particular VRF
   are manually configured, improper configuration of the VRF can result
   in VPN security violations -- traffic from a host that is not an
   extranet source may be treated as if it were traffic from an extranet
   source.

   Section 4.4 specifies the optional use of a new Extended Community --
   the Extranet Source Extended Community.  Security considerations
   regarding the use and distribution of that Extended Community are
   discussed in that section.

   The procedures of this document do not provide encryption of the data
   flows that are sent across the SP backbone network.  Hence, these
   procedures do not by themselves ensure the privacy or integrity of
   the data against attacks on the backbone network.

   In general, different VPNs are allowed to have overlapping IP address
   spaces; i.e., a host in one VPN may have the same IP address as a
   host in another.  This is safe because the customer routes from a
   given VPN do not pass into other VPNs.  Even if there are overlapping
   address spaces among VPNs, the routes that are known at any given VPN
   site are unambiguous, as long as the address space of that VPN is
   unambiguous.  However, this is not necessarily true when extranet
   service is provided.  If an extranet C-receiver in VPN-R is to be
   able to receive multicast traffic from an extranet C-source in VPN-S,
   then the address of the VPN-S extranet C-source must be imported into
   one or more VPN-R VRFs.  If that address is also the address of a
   VPN-R non-extranet C-source, then a system attempting to receive an
   extranet C-flow from the VPN-R extranet C-source may instead receive
   a non-extranet C-flow from the VPN-S C-source.  Otherwise, a VPN
   security violation may result.

   That is, when provisioning an extranet between two VPNs that have
   overlapping address spaces, one must ensure that the IP addresses of
   the extranet sources and the extranet receivers are not from the
   overlapping part of the address space.  This document specifies that
   if a route is imported into a given VRF, all addresses that match
   that route must be unambiguous in the context of that VRF.  Improper

Top      Up      ToC       Page 60 
   provisioning of the extranet source addresses or improper
   provisioning of the RTs may cause this rule to be violated and may
   result in a VPN security violation.

   It is possible that a given multicast C-source is the source of
   multiple flows, some of which are intended to be extranet C-flows and
   some of which are intended to be non-extranet flows.  However, the
   procedures of this document will allow any C-receiver that is able to
   receive the extranet C-flows from a given C-source to also receive
   the non-extranet C-flows from that source.  As a result, VPN security
   violations may result if any system is a C-source for both extranet
   and non-extranet C-flows.  However, the set of C-flows transmitted by
   a given C-source is not under the control of the SP.  SPs who offer
   the extranet MVPN service must make sure that this potential for VPN
   security violations is clearly understood by the customers who
   administer the C-sources.

   This specification does not require that UMH-eligible routes be "host
   routes"; they may be less specific routes.  So, it is possible for
   the NLRI of a UMH-eligible route to contain an address prefix that
   matches the address of both an extranet C-source and a non-extranet
   C-source.  If such a route is exported from a VPN-S VRF and imported
   by a VPN-R VRF, C-receivers contained in VPN-R will be able to
   receive C-flows from the non-extranet C-sources whose addresses match
   that route.  This may result in VPN security violations.  Service
   providers who offer the extranet MVPN service must make sure that
   this is clearly understood by the customers who administer the
   distribution of routes from CE routers to PE routers.

   If the address ambiguities described in Sections 2.1 and 2.2 are not
   prohibited by deployment of the policies described in Section 2.3.2,
   VRFs must be able to discard traffic that arrives on the wrong
   P-tunnel (as specified in Sections 2.3.1 and 7.5).  Otherwise, VPN
   security violations may occur.

Top      Up      ToC       Page 61 
11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <http://www.rfc-editor.org/info/rfc4360>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364,
              February 2006, <http://www.rfc-editor.org/info/rfc4364>.

   [RFC6513]  Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
              MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513,
              February 2012, <http://www.rfc-editor.org/info/rfc6513>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <http://www.rfc-editor.org/info/rfc6514>.

   [RFC6625]  Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
              Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
              RFC 6625, DOI 10.17487/RFC6625, May 2012,
              <http://www.rfc-editor.org/info/rfc6625>.

   [RFC7153]  Rosen, E. and Y. Rekhter, "IANA Registries for BGP
              Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
              March 2014, <http://www.rfc-editor.org/info/rfc7153>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761,
              March 2016, <http://www.rfc-editor.org/info/rfc7761>.

Top      Up      ToC       Page 62 
11.2.  Informative References

   [MVPN-IR]  Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
              Replication Tunnels in Multicast VPN", Work in Progress,
              draft-ietf-bess-ir-03, April 2016.

   [RFC3446]  Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
              Rendevous Point (RP) mechanism using Protocol Independent
              Multicast (PIM) and Multicast Source Discovery Protocol
              (MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003,
              <http://www.rfc-editor.org/info/rfc3446>.

   [RFC3618]  Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
              Discovery Protocol (MSDP)", RFC 3618,
              DOI 10.17487/RFC3618, October 2003,
              <http://www.rfc-editor.org/info/rfc3618>.

   [RFC4610]  Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
              Independent Multicast (PIM)", RFC 4610,
              DOI 10.17487/RFC4610, August 2006,
              <http://www.rfc-editor.org/info/rfc4610>.

   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
              Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
              DOI 10.17487/RFC4875, May 2007,
              <http://www.rfc-editor.org/info/rfc4875>.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast
              (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015,
              October 2007, <http://www.rfc-editor.org/info/rfc5015>.

   [RFC5059]  Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
              "Bootstrap Router (BSR) Mechanism for Protocol Independent
              Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059,
              January 2008, <http://www.rfc-editor.org/info/rfc5059>.

Top      Up      ToC       Page 63 
   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
              Thomas, "Label Distribution Protocol Extensions for Point-
              to-Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
              <http://www.rfc-editor.org/info/rfc6388>.

Top      Up      ToC       Page 64 
Acknowledgments

   The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini
   Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt
   Windisch for their contributions to this work.

   We also wish to thank Lizhong Jin and Rishabh Parekh for their
   reviews and comments.

   Special thanks to Jeffrey (Zhaohui) Zhang for his careful review and
   for providing the ASCII art appearing in Section 2.

Contributors

   Below is a list of other contributing authors, in alphabetical order:

   Wim Henderickx
   Nokia
   Copernicuslaan 50
   Antwerp  2018
   Belgium

   Email: wim.henderickx@nokia.com


   Praveen Muley
   Nokia

   Email: Praveen.Muley@nokia.com


   Ray Qiu
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA  94089
   United States

   Email: rqiu@juniper.net


   IJsbrand Wijnands
   Cisco Systems, Inc.
   De Kleetlaan 6a
   Diegem  1831
   Belgium

   Email: ice@cisco.com

Top      Up      ToC       Page 65 
Authors' Addresses

   Yakov Rekhter (editor)
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, CA  94089
   United States


   Eric C. Rosen (editor)
   Juniper Networks, Inc.
   10 Technology Park Drive
   Westford, Massachusetts  01886
   United States

   Email: erosen@juniper.net


   Rahul Aggarwal
   Arktan

   Email: raggarwa_1@yahoo.com


   Yiqun Cai
   Alibaba Group
   400 S El Camino Real #400
   San Mateo, CA  94402
   United States

   Email: yiqun.cai@alibaba-inc.com


   Thomas Morin
   Orange
   2 Avenue Pierre-Marzin
   22307 Lannion Cedex
   France

   Email: thomas.morin@orange.com