Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8049

YANG Data Model for L3VPN Service Delivery

Pages: 157
Obsoleted by:  8299
Part 3 of 6 – Pages 40 to 66
First   Prev   Next

ToP   noToC   RFC8049 - Page 40   prevText

6.6. Deciding Where to Connect the Site

The management system will have to determine where to connect each site-network-access of a particular site to the provider network (e.g., PE, aggregation switch). The current model proposes parameters and constraints that can influence the meshing of the site-network-access. The management system SHOULD honor any customer constraints. If a constraint is too strict and cannot be fulfilled, the management system MUST NOT provision the site and SHOULD provide relevant information to the user. How the information is provided is out of scope for this document. Whether or not to relax the constraint would then be left up to the user. Parameters are just hints for the management system for service placement. In addition to parameters and constraints, the management system's decision MAY be based on any other internal constraints that are left up to the SP: least load, distance, etc.
ToP   noToC   RFC8049 - Page 41

6.6.1. Constraint: Device

In the case of provider management or co-management, one or more devices have been ordered by the customer. The customer may force a particular site-network-access to be connected on a particular device that he ordered. New York Site +------------------+ Site | +--------------+ |----------------------------------- | | Manhattan | | | | CE1********* (site-network-access#1) ****** | +--------------+ | | +--------------+ | | | Brooklyn CE2********* (site-network-access#2) ****** | +--------------+ | | |----------------------------------- +------------------+ In the figure above, site-network-access#1 is associated with CE1 in the service request. The SP must ensure the provisioning of this connection.

6.6.2. Constraint/Parameter: Site Location

The location information provided in this model MAY be used by a management system to determine the target PE to mesh the site (SP side). A particular location must be associated with each site network access when configuring it. The SP MUST honor the termination of the access on the location associated with the site network access (customer side). The "country-code" in the site location SHOULD be expressed as an ISO ALPHA-2 code. The site-network-access location is determined by the "location-flavor". In the case of a provider-managed or co-managed site, the user is expected to configure a "device-reference" (device case) that will bind the site-network-access to a particular device that the customer ordered. As each device is already associated with a particular location, in such a case the location information is retrieved from the device location. In the case of a customer- managed site, the user is expected to configure a "location-reference" (location case); this provides a reference to an existing configured location and will help with placement.
ToP   noToC   RFC8049 - Page 42
                                         POP#1 (New York)
                                      +---------+
                                      |   PE1   |
                 Site #1 ---...       |   PE2   |
                (Atlantic City)       |   PE3   |
                                      +---------+

                                         POP#2 (Washington)
                                      +---------+
                                      |   PE4   |
                                      |   PE5   |
                                      |   PE6   |
                                      +---------+

                                         POP#3 (Philadelphia)
                                      +---------+
                                      |   PE7   |
                 Site #2 CE#1---...   |   PE8   |
                (Reston)              |   PE9   |
                                      +---------+

   In the example above, Site #1 is a customer-managed site with a
   location L1, while Site #2 is a provider-managed site for which a CE
   (CE#1) was ordered.  Site #2 is configured with L2 as its location.
   When configuring a site-network-access for Site #1, the user will
   need to reference location L1 so that the management system will know
   that the access will need to terminate on this location.  Then, for
   distance reasons, this management system may mesh Site #1 on a PE in
   the Philadelphia POP.  It may also take into account resources
   available on PEs to determine the exact target PE (e.g., least
   loaded).  For Site #2, the user is expected to configure the
   site-network-access with a device-reference to CE#1 so that the
   management system will know that the access must terminate on the
   location of CE#1 and must be connected to CE#1.  For placement of the
   SP side of the access connection, in the case of the nearest PE used,
   it may mesh Site #2 on the Washington POP.

6.6.3. Constraint/Parameter: Access Type

The management system needs to elect the access media to connect the site to the customer (for example, xDSL, leased line, Ethernet backhaul). The customer may provide some parameters/constraints that will provide hints to the management system.
ToP   noToC   RFC8049 - Page 43
   The bearer container information SHOULD be the first piece of
   information considered when making this decision:

   o  The "requested-type" parameter provides information about the
      media type that the customer would like to use.  If the "strict"
      leaf is equal to "true", this MUST be considered a strict
      constraint so that the management system cannot connect the site
      with another media type.  If the "strict" leaf is equal to "false"
      (default) and if the requested media type cannot be fulfilled, the
      management system can select another media type.  The supported
      media types SHOULD be communicated by the SP to the customer via a
      mechanism that is out of scope for this document.

   o  The "always-on" leaf defines a strict constraint: if set to true,
      the management system MUST elect a media type that is "always-on"
      (e.g., this means no dial access type).

   o  The "bearer-reference" parameter is used in cases where the
      customer has already ordered a network connection to the SP apart
      from the IP VPN site and wants to reuse this connection.  The
      string used is an internal reference from the SP and describes the
      already-available connection.  This is also a strict requirement
      that cannot be relaxed.  How the reference is given to the
      customer is out of scope for this document, but as a pure example,
      when the customer ordered the bearer (through a process that is
      out of scope for this model), the SP may have provided the bearer
      reference that can be used for provisioning services on top.

   Any other internal parameters from the SP can also be used.  The
   management system MAY use other parameters, such as the requested
   "svc-input-bandwidth" and "svc-output-bandwidth", to help decide
   which access type to use.

6.6.4. Constraint: Access Diversity

Each site-network-access may have one or more constraints that would drive the placement of the access. By default, the model assumes that there are no constraints, but allocation of a unique bearer per site-network-access is expected. In order to help with the different placement scenarios, a site-network-access may be tagged using one or multiple group identifiers. The group identifier is a string, so it can accommodate both explicit naming of a group of sites (e.g., "multihomed-set1" or "subVPN") and the use of a numbered identifier (e.g., 12345678). The meaning of each group-id is local to each customer administrator, and the management system MUST ensure that different customers can use the same group-ids. One or more group-ids can also be defined at the
ToP   noToC   RFC8049 - Page 44
   site level; as a consequence, all site-network-accesses under the
   site MUST inherit the group-ids of the site they belong to.  When, in
   addition to the site group-ids some group-ids are defined at the
   site-network-access level, the management system MUST consider the
   union of all groups (site level and site network access level) for
   this particular site-network-access.

   For an already-configured site-network-access, each constraint MUST
   be expressed against a targeted set of site-network-accesses.  This
   site-network-access MUST never be taken into account in the targeted
   set -- for example, "My site-network-access S must not be connected
   on the same POP as the site-network-accesses that are part of
   Group 10."  The set of site-network-accesses against which the
   constraint is evaluated can be expressed as a list of groups,
   "all-other-accesses", or "all-other-groups".  The all-other-accesses
   option means that the current site-network-access constraint MUST be
   evaluated against all the other site-network-accesses belonging to
   the current site.  The all-other-groups option means that the
   constraint MUST be evaluated against all groups that the current
   site-network-access does not belong to.

   The current model proposes multiple constraint-types:

   o  pe-diverse: The current site-network-access MUST NOT be connected
      to the same PE as the targeted site-network-accesses.

   o  pop-diverse: The current site-network-access MUST NOT be connected
      to the same POP as the targeted site-network-accesses.

   o  linecard-diverse: The current site-network-access MUST NOT be
      connected to the same linecard as the targeted
      site-network-accesses.

   o  bearer-diverse: The current site-network-access MUST NOT use
      common bearer components compared to bearers used by the targeted
      site-network-accesses.  "bearer-diverse" provides some level of
      diversity at the access level.  As an example, two bearer-diverse
      site-network-accesses must not use the same DSLAM, BAS, or Layer 2
      switch.

   o  same-pe: The current site-network-access MUST be connected to the
      same PE as the targeted site-network-accesses.

   o  same-bearer: The current site-network-access MUST be connected
      using the same bearer as the targeted site-network-accesses.

   These constraint-types can be extended through augmentation.
ToP   noToC   RFC8049 - Page 45
   Each constraint is expressed as "The site-network-access S must be
   <constraint-type> (e.g., pe-diverse, pop-diverse) from these <target>
   site-network-accesses."

   The group-id used to target some site-network-accesses may be the
   same as the one used by the current site-network-access.  This eases
   the configuration of scenarios where a group of site-network-access
   points has a constraint between the access points in the group.  As
   an example, if we want a set of sites (Site#1 to Site#5) to be
   connected on different PEs, we can tag them with the same group-id
   and express a pe-diverse constraint for this group-id.

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
ToP   noToC   RFC8049 - Page 46
   <site>
    <site-id>SITE2</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   ...
   <site>
    <site-id>SITE5</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
ToP   noToC   RFC8049 - Page 47
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

   The group-id used to target some site-network-accesses may also be
   different than the one used by the current site-network-access.  This
   can be used to express that a group of sites has some constraints
   against another group of sites, but there is no constraint within the
   group.  For example, we consider a set of six sites and two groups;
   we want to ensure that a site in the first group must be pop-diverse
   from a site in the second group:

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
ToP   noToC   RFC8049 - Page 48
   </site>
   <site>
    <site-id>SITE2</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   ...
   <site>
    <site-id>SITE5</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
ToP   noToC   RFC8049 - Page 49
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>SITE6</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

6.6.5. Infeasible Access Placement

Some infeasible access placement scenarios could be created via the proposed configuration framework. Such infeasible access placement scenarios could result from constraints that are too restrictive, leading to infeasible access placement in the network or conflicting
ToP   noToC   RFC8049 - Page 50
   constraints that would also lead to infeasible access placement.  An
   example of conflicting rules would be to request that
   site-network-access#1 be pe-diverse from site-network-access#2 and to
   request at the same time that site-network-access#2 be on the same PE
   as site-network-access#1.  When the management system cannot
   determine the placement of a site-network-access, it SHOULD return an
   error message indicating that placement was not possible.

6.6.6. Examples of Access Placement

6.6.6.1. Multihoming
The customer wants to create a multihomed site. The site will be composed of two site-network-accesses; for resiliency purposes, the customer wants the two site-network-accesses to be meshed on different POPs. POP#1 +-------+ +---------+ | | | PE1 | | |---site-network-access#1----| PE2 | | | | PE3 | | | +---------+ | Site#1| | | POP#2 | | +---------+ | | | PE4 | | |---site-network-access#2----| PE5 | | | | PE6 | | | +---------+ +-------+ This scenario can be expressed as follows: <site> <site-id>SITE1</site-id> <site-network-accesses> <site-network-access> <site-network-access-id>1</site-network-access-id> <access-diversity> <groups> <group> <group-id>10</group-id> </group> </groups> <constraints> <constraint> <constraint-type>pop-diverse</constraint-type>
ToP   noToC   RFC8049 - Page 51
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>2</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
ToP   noToC   RFC8049 - Page 52
   But it can also be expressed as follows:

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <all-other-accesses/>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>2</site-network-access-id>
      <access-diversity>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <all-other-accesses/>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
ToP   noToC   RFC8049 - Page 53
6.6.6.2. Site Offload
The customer has six branch offices in a particular region, and he wants to prevent having all branch offices connected on the same PE. He wants to express that three branch offices cannot be connected on the same linecard. Also, the other branch offices must be connected on a different POP. Those other branch offices cannot also be connected on the same linecard. POP#1 +---------+ | PE1 | Office#1 ---... | PE2 | Office#2 ---... | PE3 | Office#3 ---... | PE4 | +---------+ POP#2 +---------+ Office#4 ---... | PE5 | Office#5 ---... | PE6 | Office#6 ---... | PE7 | +---------+ This scenario can be expressed as follows: o We need to create two groups of sites: Group#10, which is composed of Office#1, Office#2, and Office#3; and Group#20, which is composed of Office#4, Office#5, and Office#6. o Sites within Group#10 must be pop-diverse from sites within Group#20, and vice versa. o Sites within Group#10 must be linecard-diverse from other sites in Group#10 (same for Group#20).
ToP   noToC   RFC8049 - Page 54
   <site>
    <site-id>Office1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>Office2</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
ToP   noToC   RFC8049 - Page 55
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>Office3</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>10</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
ToP   noToC   RFC8049 - Page 56
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>Office4</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
ToP   noToC   RFC8049 - Page 57
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
   <site>
    <site-id>Office5</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
ToP   noToC   RFC8049 - Page 58
   <site>
    <site-id>Office6</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>20</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pop-diverse</constraint-type>
         <target>
          <group>
           <group-id>10</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>linecard-diverse</constraint-type>
         <target>
          <group>
           <group-id>20</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNA</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
ToP   noToC   RFC8049 - Page 59
6.6.6.3. Parallel Links
To increase its site bandwidth at lower cost, a customer wants to order two parallel site-network-accesses that will be connected to the same PE. *******site-network-access#1********** Site 1 *******site-network-access#2********** PE1 This scenario can be expressed as follows: <site> <site-id>SITE1</site-id> <site-network-accesses> <site-network-access> <site-network-access-id>1</site-network-access-id> <access-diversity> <groups> <group> <group-id>PE-linkgrp-1</group-id> </group> </groups> <constraints> <constraint> <constraint-type>same-pe</constraint-type> <target> <group> <group-id>PE-linkgrp-1</group-id> </group> </target> </constraint> </constraints> </access-diversity> <vpn-attachment> <vpn-id>VPNB</vpn-id> <site-role>spoke-role</site-role> </vpn-attachment> </site-network-access> <site-network-access> <site-network-access-id>2</site-network-access-id> <access-diversity> <groups> <group> <group-id>PE-linkgrp-1</group-id> </group> </groups>
ToP   noToC   RFC8049 - Page 60
       <constraints>
        <constraint>
         <constraint-type>same-pe</constraint-type>
         <target>
          <group>
           <group-id>PE-linkgrp-1</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNB</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

6.6.6.4. SubVPN with Multihoming
A customer has a site that is dual-homed. The dual-homing must be done on two different PEs. The customer also wants to implement two subVPNs on those multihomed accesses. +-----------------+ Site +------+ | |---------------------------------/ +-----+ | |****(site-network-access#1)*****| VPN B / \ | New York Office |****(site-network-access#2)************| VPN C | | | +-----\ / | | +-----+ | | | | +------+ | | / +-----+ | |****(site-network-access#3)*****| VPN B / \ | |****(site-network-access#4)************| VPN C | | | +-----\ / | |----------------------------------- +-----+ +-----------------+ This scenario can be expressed as follows: o The site will have four site network accesses (two subVPNs coupled via dual-homing). o Site-network-access#1 and site-network-access#3 will correspond to the multihoming of subVPN B. A PE-diverse constraint is required between them.
ToP   noToC   RFC8049 - Page 61
   o  Site-network-access#2 and site-network-access#4 will correspond to
      the multihoming of subVPN C.  A PE-diverse constraint is required
      between them.

   o  To ensure proper usage of the same bearer for the subVPN,
      site-network-access#1 and site-network-access#2 must share the
      same bearer as site-network-access#3 and site-network-access#4.

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>1</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>dualhomed-1</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-2</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>same-bearer</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-1</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNB</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>2</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
ToP   noToC   RFC8049 - Page 62
         <group-id>dualhomed-1</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-2</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>same-bearer</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-1</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNC</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>3</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>dualhomed-2</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-1</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>same-bearer</constraint-type>
         <target>
          <group>
ToP   noToC   RFC8049 - Page 63
           <group-id>dualhomed-2</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNB</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
     <site-network-access>
      <site-network-access-id>4</site-network-access-id>
      <access-diversity>
       <groups>
        <group>
         <group-id>dualhomed-2</group-id>
        </group>
       </groups>
       <constraints>
        <constraint>
         <constraint-type>pe-diverse</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-1</group-id>
          </group>
         </target>
        </constraint>
        <constraint>
         <constraint-type>same-bearer</constraint-type>
         <target>
          <group>
           <group-id>dualhomed-2</group-id>
          </group>
         </target>
        </constraint>
       </constraints>
      </access-diversity>
      <vpn-attachment>
       <vpn-id>VPNC</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>
ToP   noToC   RFC8049 - Page 64

6.6.7. Route Distinguisher and VRF Allocation

The route distinguisher (RD) is a critical parameter of PE-based L3VPNs as described in [RFC4364] that provides the ability to distinguish common addressing plans in different VPNs. As for route targets (RTs), a management system is expected to allocate a VRF on the target PE and an RD for this VRF. If a VRF already exists on the target PE and the VRF fulfills the connectivity constraints for the site, there is no need to recreate another VRF, and the site MAY be meshed within this existing VRF. How the management system checks that an existing VRF fulfills the connectivity constraints for a site is out of scope for this document. If no such VRF exists on the target PE, the management system has to initiate the creation of a new VRF on the target PE and has to allocate a new RD for this new VRF. The management system MAY apply a per-VPN or per-VRF allocation policy for the RD, depending on the SP's policy. In a per-VPN allocation policy, all VRFs (dispatched on multiple PEs) within a VPN will share the same RD value. In a per-VRF model, all VRFs should always have a unique RD value. Some other allocation policies are also possible, and this document does not restrict the allocation policies to be used. The allocation of RDs MAY be done in the same way as RTs. The examples provided in Section 6.2.1.1 could be reused in this scenario. Note that an SP MAY configure a target PE for an automated allocation of RDs. In this case, there will be no need for any backend system to allocate an RD value.

6.7. Site Network Access Availability

A site may be multihomed, meaning that it has multiple site-network-access points. Placement constraints defined in previous sections will help ensure physical diversity. When the site-network-accesses are placed on the network, a customer may want to use a particular routing policy on those accesses.
ToP   noToC   RFC8049 - Page 65
   The "site-network-access/availability" container defines parameters
   for site redundancy.  The "access-priority" leaf defines a preference
   for a particular access.  This preference is used to model
   load-balancing or primary/backup scenarios.  The higher the
   access-priority value, the higher the preference will be.

   The figure below describes how the access-priority attribute can be
   used.

   Hub#1 LAN (Primary/backup)          Hub#2 LAN (Load-sharing)
     |                                                     |
     |    access-priority 1          access-priority 1     |
     |--- CE1 ------- PE1            PE3 --------- CE3 --- |
     |                                                     |
     |                                                     |
     |--- CE2 ------- PE2            PE4 --------- CE4 --- |
     |    access-priority 2          access-priority 1     |

                             PE5
                              |
                              |
                              |
                             CE5
                              |
                         Spoke#1 site (Single-homed)

   In the figure above, Hub#2 requires load-sharing, so all the
   site-network-accesses must use the same access-priority value.  On
   the other hand, as Hub#1 requires a primary site-network-access and a
   backup site-network-access, a higher access-priority setting will be
   configured on the primary site-network-access.

   Scenarios that are more complex can be modeled.  Let's consider a Hub
   site with five accesses to the network (A1,A2,A3,A4,A5).  The
   customer wants to load-share its traffic on A1,A2 in the nominal
   situation.  If A1 and A2 fail, the customer wants to load-share its
   traffic on A3 and A4; finally, if A1 to A4 are down, he wants to
   use A5.  We can model this easily by configuring the following
   access-priority values: A1=100, A2=100, A3=50, A4=50, A5=10.

   The access-priority scenario has some limitations.  An
   access-priority scenario like the previous one with five accesses but
   with the constraint of having traffic load-shared between A3 and A4
   in the case where A1 OR A2 is down is not achievable.  But the
   authors believe that using the access-priority attribute will cover
   most of the deployment use cases and that the model can still be
   extended via augmentation to support additional use cases.
ToP   noToC   RFC8049 - Page 66

6.8. Traffic Protection

The service model supports the ability to protect the traffic for a site. Such protection provides a better level of availability in multihoming scenarios by, for example, using local-repair techniques in case of failures. The associated level of service guarantee would be based on an agreement between the customer and the SP and is out of scope for this document. Site#1 Site#2 CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3 | | | | | | CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4 / / CE5 ----+ Site#3 In the figure above, we consider an IP VPN service with three sites, including two dual-homed sites (Site#1 and Site#2). For dual-homed sites, we consider PE1-CE1 and PE3-CE3 as primary and PE2-CE2,PE4-CE4 as backup for the example (even if protection also applies to load-sharing scenarios). In order to protect Site#2 against a failure, a user may set the "traffic-protection/enabled" leaf to true for Site#2. How the traffic protection will be implemented is out of scope for this document. However, in such a case, we could consider traffic coming from a remote site (Site#1 or Site#3), where the primary path would use PE3 as the egress PE. PE3 may have preprogrammed a backup forwarding entry pointing to the backup path (through PE4-CE4) for all prefixes going through the PE3-CE3 link. How the backup path is computed is out of scope for this document. When the PE3-CE3 link fails, traffic is still received by PE3, but PE3 automatically switches traffic to the backup entry; the path will therefore be PE1-P1-(...)-P3-PE3-PE4-CE4 until the remote PEs reconverge and use PE4 as the egress PE.


(page 66 continued on part 4)

Next Section