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.

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.

                                         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.

   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

   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.

   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>

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

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

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

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

   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>

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

   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>

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

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

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

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

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

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

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>

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

   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>

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

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

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.

   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.

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.