tech-invite   World Map     

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

RFC 8049

 
 
 

YANG Data Model for L3VPN Service Delivery

Part 2 of 6, p. 18 to 40
Prev Section       Next Section

 


prevText      Top      ToC       Page 18 
6.2.  VPN Service Overview

   A vpn-service list item contains generic information about the VPN
   service.  The "vpn-id" provided in the vpn-service list refers to an
   internal reference for this VPN service, while the customer name
   refers to a more-explicit reference to the customer.  This identifier
   is purely internal to the organization responsible for the VPN
   service.

6.2.1.  VPN Service Topology

   The type of VPN service topology is required for configuration.  Our
   proposed model supports any-to-any, Hub and Spoke (where Hubs can
   exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot
   exchange traffic).  New topologies could be added via augmentation.
   By default, the any-to-any VPN service topology is used.

Top      Up      ToC       Page 19 
6.2.1.1.  Route Target Allocation

   A Layer 3 PE-based VPN is built using route targets (RTs) as
   described in [RFC4364].  The management system is expected to
   automatically allocate a set of RTs upon receiving a VPN service
   creation request.  How the management system allocates RTs is out of
   scope for this document, but multiple ways could be envisaged, as
   described below.

                                    Management system
                     <------------------------------------------------->
                                                 Request RT
                      +-----------------------+  Topo a2a   +----------+
           RESTCONF   |                       |  ----->     |          |
   User ------------- | Service Orchestration |             | Network  |
           l3vpn-svc  |                       |  <-----     |   OSS    |
             Model    +-----------------------+   Response  +----------+
                                                  RT1, RT2

   In the example above, a service orchestration, owning the
   instantiation of this service model, requests RTs to the network OSS.
   Based on the requested VPN service topology, the network OSS replies
   with one or multiple RTs.  The interface between this service
   orchestration and the network OSS is out of scope for this document.

                              +---------------------------+
                   RESTCONF   |                           |
           User ------------- |   Service Orchestration   |
                   l3vpn-svc  |                           |
                     Model    |                           |
                              |  RT pool: 10:1->10:10000  |
                              |  RT pool: 20:50->20:5000  |
                              +---------------------------+

   In the example above, a service orchestration, owning the
   instantiation of this service model, owns one or more pools of RTs
   (specified by the SP) that can be allocated.  Based on the requested
   VPN service topology, it will allocate one or multiple RTs from the
   pool.

   The mechanisms shown above are just examples and should not be
   considered an exhaustive list of solutions.

Top      Up      ToC       Page 20 
6.2.1.2.  Any-to-Any

     +------------------------------------------------------------+
     |  VPN1_Site1 ------ PE1               PE2 ------ VPN1_Site2 |
     |                                                            |
     |  VPN1_Site3 ------ PE3               PE4 ------ VPN1_Site4 |
     +------------------------------------------------------------+

                     Any-to-Any VPN Service Topology

   In the any-to-any VPN service topology, all VPN sites can communicate
   with each other without any restrictions.  The management system that
   receives an any-to-any IP VPN service request through this model is
   expected to assign and then configure the VRF and RTs on the
   appropriate PEs.  In the any-to-any case, a single RT is generally
   required, and every VRF imports and exports this RT.

6.2.1.3.  Hub and Spoke

     +-------------------------------------------------------------+
     |   Hub_Site1 ------ PE1               PE2 ------ Spoke_Site1 |
     |                          +----------------------------------+
     |                          |
     |                          +----------------------------------+
     |   Hub_Site2 ------ PE3               PE4 ------ Spoke_Site2 |
     +-------------------------------------------------------------+

                     Hub-and-Spoke VPN Service Topology

   In the Hub-and-Spoke VPN service topology, all Spoke sites can
   communicate only with Hub sites but not with each other, and Hubs can
   also communicate with each other.  The management system that owns an
   any-to-any IP VPN service request through this model is expected to
   assign and then configure the VRF and RTs on the appropriate PEs.  In
   the Hub-and-Spoke case, two RTs are generally required (one RT for
   Hub routes and one RT for Spoke routes).  A Hub VRF that connects Hub
   sites will export Hub routes with the Hub RT and will import Spoke
   routes through the Spoke RT.  It will also import the Hub RT to allow
   Hub-to-Hub communication.  A Spoke VRF that connects Spoke sites will
   export Spoke routes with the Spoke RT and will import Hub routes
   through the Hub RT.

Top      Up      ToC       Page 21 
   The management system MUST take into account constraints on Hub-and-
   Spoke connections.  For example, if a management system decides to
   mesh a Spoke site and a Hub site on the same PE, it needs to mesh
   connections in different VRFs, as shown in the figure below.

      Hub_Site ------- (VRF_Hub)  PE1
                                 (VRF_Spoke)
                                   /  |
   Spoke_Site1 -------------------+   |
                                      |
   Spoke_Site2 -----------------------+

6.2.1.4.  Hub and Spoke Disjoint

     +-------------------------------------------------------------+
     |   Hub_Site1 ------ PE1               PE2 ------ Spoke_Site1 |
     +--------------------------+  +-------------------------------+
                                |  |
     +--------------------------+  +-------------------------------+
     |   Hub_Site2 ------ PE3               PE4 ------ Spoke_Site2 |
     +-------------------------------------------------------------+

               Hub and Spoke Disjoint VPN Service Topology

   In the Hub and Spoke disjoint VPN service topology, all Spoke sites
   can communicate only with Hub sites but not with each other, and Hubs
   cannot communicate with each other.  The management system that owns
   an any-to-any IP VPN service request through this model is expected
   to assign and then configure the VRF and RTs on the appropriate PEs.
   In the Hub-and-Spoke case, two RTs are required (one RT for Hub
   routes and one RT for Spoke routes).  A Hub VRF that connects Hub
   sites will export Hub routes with the Hub RT and will import Spoke
   routes through the Spoke RT.  A Spoke VRF that connects Spoke sites
   will export Spoke routes with the Spoke RT and will import Hub routes
   through the Hub RT.

   The management system MUST take into account constraints on Hub-and-
   Spoke connections, as in the previous case.

   Hub and Spoke disjoint can also be seen as multiple Hub-and-Spoke
   VPNs (one per Hub) that share a common set of Spoke sites.

Top      Up      ToC       Page 22 
6.2.2.  Cloud Access

   The proposed model provides cloud access configuration via the
   "cloud-accesses" container.  The usage of cloud-access is targeted
   for the public cloud.  An Internet access can also be considered a
   public cloud access service.  The cloud-accesses container provides
   parameters for network address translation and authorization rules.

   A private cloud access may be addressed through NNIs, as described in
   Section 6.15.

   A cloud identifier is used to reference the target service.  This
   identifier is local to each administration.

   The model allows for source address translation before accessing the
   cloud.  IPv4-to-IPv4 address translation (NAT44) is the only
   supported option, but other options can be added through
   augmentation.  If IP source address translation is required to access
   the cloud, the "enabled" leaf MUST be set to true in the "nat44"
   container.  An IP address may be provided in the "customer-address"
   leaf if the customer is providing the IP address to be used for the
   cloud access.  If the SP is providing this address,
   "customer-address" is not necessary, as it can be picked from a pool
   of SPs.

   By default, all sites in the IP VPN MUST be authorized to access the
   cloud.  If restrictions are required, a user MAY configure the
   "permit-site" or "deny-site" leaf-list.  The permit-site leaf-list
   defines the list of sites authorized for cloud access.  The deny-site
   leaf-list defines the list of sites denied for cloud access.  The
   model supports both "deny-any-except" and "permit-any-except"
   authorization.

   How the restrictions will be configured on network elements is out of
   scope for this document.

Top      Up      ToC       Page 23 
                     IP VPN
           ++++++++++++++++++++++++++++++++     ++++++++++++
           +             Site 3           + --- +  Cloud 1 +
           + Site 1                       +     ++++++++++++
           +                              +
           + Site 2                       + --- ++++++++++++
           +                              +     + Internet +
           +            Site 4            +     ++++++++++++
           ++++++++++++++++++++++++++++++++
                        |
                   +++++++++++
                   + Cloud 2 +
                   +++++++++++

   In the example above, we configure the global VPN to access the
   Internet by creating a cloud-access pointing to the cloud identifier
   for the Internet service.  No authorized sites will be configured, as
   all sites are required to access the Internet.  The
   "address-translation/nat44/enabled" leaf will be set to true.

   <vpn-service>
       <vpn-id>123456487</vpn-id>
       <cloud-accesses>
        <cloud-access>
           <cloud-identifier>INTERNET</cloud-identifier>
           <address-translation>
             <nat44>
               <enabled>true</enabled>
             </nat44>
           </address-translation>
        </cloud-access>
       </cloud-accesses>
   </vpn-service>

Top      Up      ToC       Page 24 
   If Site 1 and Site 2 require access to Cloud 1, a new cloud-access
   pointing to the cloud identifier of Cloud 1 will be created.  The
   permit-site leaf-list will be filled with a reference to Site 1 and
   Site 2.

   <vpn-service>
       <vpn-id>123456487</vpn-id>
       <cloud-accesses>
        <cloud-access>
           <cloud-identifier>Cloud1</cloud-identifier>
           <permit-site>site1</permit-site>
           <permit-site>site2</permit-site>
        </cloud-access>
       </cloud-accesses>
   </vpn-service>

   If all sites except Site 1 require access to Cloud 2, a new
   cloud-access pointing to the cloud identifier of Cloud 2 will be
   created.  The deny-site leaf-list will be filled with a reference to
   Site 1.

   <vpn-service>
       <vpn-id>123456487</vpn-id>
       <cloud-accesses>
        <cloud-access>
           <cloud-identifier>Cloud2</cloud-identifier>
           <deny-site>site1</deny-site>
        </cloud-access>
       </cloud-accesses>
   </vpn-service>

6.2.3.  Multicast Service

   Multicast in IP VPNs is described in [RFC6513].

   If multicast support is required for an IP VPN, some global multicast
   parameters are required as input for the service request.

   Users of this model will need to provide the flavors of trees that
   will be used by customers within the IP VPN (customer tree).  The
   proposed model supports bidirectional, shared, and source-based trees
   (and can be augmented).  Multiple flavors of trees can be supported
   simultaneously.

Top      Up      ToC       Page 25 
                                   Operator network
                                   ______________
                                  /               \
                                 |                 |
                          (SSM tree)               |
    Recv (IGMPv3) -- Site2 ------- PE2             |
                                 |             PE1 --- Site1 --- Source1
                                 |                 |        \
                                 |                 |         -- Source2
                                 |                 |
                           (ASM tree)              |
    Recv (IGMPv2) -- Site3 ------- PE3             |
                                 |                 |
                           (SSM tree)              |
    Recv (IGMPv3) -- Site4 ------- PE4             |
                                 | /               |
    Recv (IGMPv2) -- Site5 --------                |
                           (ASM tree)              |
                                 |                 |
                                  \_______________/

   When an ASM flavor is requested, this model requires that the "rp"
   and "rp-discovery" parameters be filled.  Multiple RP-to-group
   mappings can be created using the "rp-group-mappings" container.  For
   each mapping, the SP can manage the RP service by setting the
   "provider-managed/enabled" leaf to true.  In the case of a provider-
   managed RP, the user can request RP redundancy and/or optimal traffic
   delivery.  Those parameters will help the SP select the appropriate
   technology or architecture to fulfill the customer service
   requirement: for instance, in the case of a request for optimal
   traffic delivery, an SP may use Anycast-RP or RP-tree-to-SPT
   switchover architectures.

   In the case of a customer-managed RP, the RP address must be filled
   in the RP-to-group mappings using the "rp-address" leaf.  This leaf
   is not needed for a provider-managed RP.

   Users can define a specific mechanism for RP discovery, such as the
   "auto-rp", "static-rp", or "bsr-rp" modes.  By default, the model
   uses "static-rp" if ASM is requested.  A single rp-discovery
   mechanism is allowed for the VPN.  The "rp-discovery" container can
   be used for both provider-managed and customer-managed RPs.  In the
   case of a provider-managed RP, if the user wants to use "bsr-rp" as a
   discovery protocol, an SP should consider the provider-managed
   "rp-group-mappings" for the "bsr-rp" configuration.  The SP will then
   configure its selected RPs to be "bsr-rp-candidates".  In the case of
   a customer-managed RP and a "bsr-rp" discovery mechanism, the
   "rp-address" provided will be the bsr-rp candidate.

Top      Up      ToC       Page 26 
6.2.4.  Extranet VPNs

   There are some cases where a particular VPN needs access to resources
   (servers, hosts, etc.) that are external.  Those resources may be
   located in another VPN.

                 +-----------+           +-----------+
                /             \         /             \
     Site A -- |    VPN A      |  ---  |    VPN B      | --- Site B
                \             /         \             / (Shared
                 +-----------+           +-----------+   resources)

   In the figure above, VPN B has some resources on Site B that need to
   be available to some customers/partners.  VPN A must be able to
   access those VPN B resources.

   Such a VPN connection scenario can be achieved via a VPN policy as
   defined in Section 6.5.2.2.  But there are some simple cases where a
   particular VPN (VPN A) needs access to all resources in another VPN
   (VPN B).  The model provides an easy way to set up this connection
   using the "extranet-vpns" container.

   The extranet-vpns container defines a list of VPNs a particular VPN
   wants to access.  The extranet-vpns container must be used on
   customer VPNs accessing extranet resources in another VPN.  In the
   figure above, in order to provide VPN A with access to VPN B, the
   extranet-vpns container needs to be configured under VPN A with an
   entry corresponding to VPN B.  There is no service configuration
   requirement on VPN B.

   Readers should note that even if there is no configuration
   requirement on VPN B, if VPN A lists VPN B as an extranet, all sites
   in VPN B will gain access to all sites in VPN A.

   The "site-role" leaf defines the role of the local VPN sites in the
   target extranet VPN service topology.  Site roles are defined in
   Section 6.4.  Based on this, the requirements described in
   Section 6.4 regarding the site-role leaf are also applicable here.

Top      Up      ToC       Page 27 
   In the example below, VPN A accesses VPN B resources through an
   extranet connection.  A Spoke role is required for VPN A sites, as
   sites from VPN A must not be able to communicate with each other
   through the extranet VPN connection.

   <vpn-service>
       <vpn-id>VPNB</vpn-id>
       <vpn-service-topology>hub-spoke</vpn-service-topology>
   </vpn-service>
   <vpn-service>
       <vpn-id>VPNA</vpn-id>
       <vpn-service-topology>any-to-any</vpn-service-topology>
       <extranet-vpns>
           <extranet-vpn>
               <vpn-id>VPNB</vpn-id>
               <site-role>spoke-role</site-role>
           </extranet-vpn>
       </extranet-vpns>
   </vpn-service>

   This model does not define how the extranet configuration will be
   achieved.

   Any VPN interconnection scenario that is more complex (e.g., only
   certain parts of sites on VPN A accessing only certain parts of sites
   on VPN B) needs to be achieved using a VPN attachment as defined in
   Section 6.5.2, and especially a VPN policy as defined in
   Section 6.5.2.2.

6.3.  Site Overview

   A site represents a connection of a customer office to one or more
   VPN services.

                                                    +-------------+
                                                   /               \
     +------------------+                   +-----|      VPN1       |
     |                  |                   |      \               /
     |  New York Office |------ (site) -----+       +-------------+
     |                  |                   |       +-------------+
     +------------------+                   |      /               \
                                            +-----|      VPN2       |
                                                   \               /
                                                    +-------------+

Top      Up      ToC       Page 28 
   A site has several characteristics:

   o  Unique identifier (site-id): uniquely identifies the site within
      the overall network infrastructure.  The identifier is a string
      that allows any encoding for the local administration of the VPN
      service.

   o  Locations (locations): site location information that allows easy
      retrieval of information from the nearest available resources.  A
      site may be composed of multiple locations.

   o  Devices (devices): allows the customer to request one or more
      customer premises equipment entities from the SP for a particular
      site.

   o  Management (management): defines the type of management for the
      site -- for example, co-managed, customer-managed, or provider-
      managed.  See Section 6.10.

   o  Site network accesses (site-network-accesses): defines the list of
      network accesses associated with the sites, and their properties
      -- especially bearer, connection, and service parameters.

   A site-network-access represents an IP logical connection of a site.
   A site may have multiple site-network-accesses.

     +------------------+             Site
     |                  |-----------------------------------
     |                  |****** (site-network-access#1) ******
     |  New York Office |
     |                  |****** (site-network-access#2) ******
     |                  |-----------------------------------
     +------------------+

   Multiple site-network-accesses are used, for instance, in the case of
   multihoming.  Some other meshing cases may also include multiple
   site-network-accesses.

   The site configuration is viewed as a global entity; we assume that
   it is mostly the management system's role to split the parameters
   between the different elements within the network.  For example, in
   the case of the site-network-access configuration, the management
   system needs to split the overall parameters between the PE
   configuration and the CE configuration.

Top      Up      ToC       Page 29 
6.3.1.  Devices and Locations

   A site may be composed of multiple locations.  All the locations will
   need to be configured as part of the "locations" container and list.
   A typical example of a multi-location site is a headquarters office
   in a city composed of multiple buildings.  Those buildings may be
   located in different parts of the city and may be linked by
   intra-city fibers (customer metropolitan area network).  In such a
   case, when connecting to a VPN service, the customer may ask for
   multihoming based on its distributed locations.

       New York Site

     +------------------+             Site
     | +--------------+ |-----------------------------------
     | | Manhattan    | |****** (site-network-access#1) ******
     | +--------------+ |
     | +--------------+ |
     | | Brooklyn     | |****** (site-network-access#2) ******
     | +--------------+ |
     |                  |-----------------------------------
     +------------------+

   A customer may also request some premises equipment entities (CEs)
   from the SP via the "devices" container.  Requesting a CE implies a
   provider-managed or co-managed model.  A particular device must be
   ordered to a particular already-configured location.  This would help
   the SP send the device to the appropriate postal address.  In a
   multi-location site, a customer may, for example, request a CE for
   each location on the site where multihoming must be implemented.  In
   the figure above, one device may be requested for the Manhattan
   location and one other for the Brooklyn location.

   By using devices and locations, the user can influence the
   multihoming scenario he wants to implement: single CE, dual CE, etc.

Top      Up      ToC       Page 30 
6.3.2.  Site Network Accesses

   As mentioned earlier, a site may be multihomed.  Each IP network
   access for a site is defined in the "site-network-accesses"
   container.  The site-network-access parameter defines how the site is
   connected on the network and is split into three main classes of
   parameters:

   o  bearer: defines requirements of the attachment (below Layer 3).

   o  connection: defines Layer 3 protocol parameters of the attachment.

   o  availability: defines the site's availability policy.  The
      availability parameters are defined in Section 6.7.

   The site-network-access has a specific type
   (site-network-access-type).  This document defines two types:

   o  point-to-point: describes a point-to-point connection between the
      SP and the customer.

   o  multipoint: describes a multipoint connection between the SP and
      the customer.

   The type of site-network-access may have an impact on the parameters
   offered to the customer, e.g., an SP may not offer encryption for
   multipoint accesses.  It is up to the provider to decide what
   parameter is supported for point-to-point and/or multipoint accesses;
   this topic is out of scope for this document.  Some containers
   proposed in the model may require extensions in order to work
   properly for multipoint accesses.

6.3.2.1.  Bearer

   The bearer container defines the requirements for the site attachment
   to the provider network that are below Layer 3.

   The bearer parameters will help determine the access media to be
   used.  This is further described in Section 6.6.3.

Top      Up      ToC       Page 31 
6.3.2.2.  Connection

   The "ip-connection" container defines the protocol parameters of the
   attachment (IPv4 and IPv6).  Depending on the management mode, it
   refers to PE-CE addressing or CE-to-customer-LAN addressing.  In any
   case, it describes the responsibility boundary between the provider
   and the customer.  For a customer-managed site, it refers to the
   PE-CE connection.  For a provider-managed site, it refers to the
   CE-to-LAN connection.

6.3.2.2.1.  IP Addressing

   An IP subnet can be configured for either IPv4 or IPv6 Layer 3
   protocols.  For a dual-stack connection, two subnets will be
   provided, one for each address family.

   The "address-allocation-type" determines how the address allocation
   needs to be done.  The current model proposes five ways to perform IP
   address allocation:

   o  provider-dhcp: The provider will provide DHCP service for customer
      equipment; this is applicable to either the "IPv4" container or
      the "IPv6" container.

   o  provider-dhcp-relay: The provider will provide DHCP relay service
      for customer equipment; this is applicable to both IPv4 and IPv6
      addressing.  The customer needs to populate the DHCP server list
      to be used.

   o  static-address: Addresses will be assigned manually; this is
      applicable to both IPv4 and IPv6 addressing.

   o  slaac: This parameter enables stateless address autoconfiguration
      [RFC4862].  This is applicable to IPv6 only.

   o  provider-dhcp-slaac: The provider will provide DHCP service for
      customer equipment, as well as stateless address
      autoconfiguration.  This is applicable to IPv6 only.

   In the dynamic addressing mechanism, the SP is expected to provide at
   least the IP address, mask, and default gateway information.

6.3.2.2.2.  OAM

   A customer may require a specific IP connectivity fault detection
   mechanism on the IP connection.  The model supports BFD as a fault
   detection mechanism.  This can be extended with other mechanisms via
   augmentation.  The provider can propose some profiles to the

Top      Up      ToC       Page 32 
   customer, depending on the service level the customer wants to
   achieve.  Profile names must be communicated to the customer.  This
   communication is out of scope for this document.  Some fixed values
   for the holdtime period may also be imposed by the customer if the
   provider allows the customer this function.

   The "oam" container can easily be augmented by other mechanisms; in
   particular, work done by the LIME Working Group
   (https://datatracker.ietf.org/wg/lime/charter/) may be reused in
   applicable scenarios.

6.3.2.3.  Inheritance of Parameters Defined at Site Level and Site
          Network Access Level

   Some parameters can be configured at both the site level and the
   site-network-access level, e.g., routing, services, security.
   Inheritance applies when parameters are defined at the site level.
   If a parameter is configured at both the site level and the access
   level, the access-level parameter MUST override the site-level
   parameter.  Those parameters will be described later in this
   document.

   In terms of provisioning impact, it will be up to the implementation
   to decide on the appropriate behavior when modifying existing
   configurations.  But the SP will need to communicate to the user
   about the impact of using inheritance.  For example, if we consider
   that a site has already provisioned three site-network-accesses, what
   will happen if a customer changes a service parameter at the site
   level?  An implementation of this model may update the service
   parameters of all already-provisioned site-network-accesses (with
   potential impact on live traffic), or it may take into account this
   new parameter only for the new sites.

6.4.  Site Role

   A VPN has a particular service topology, as described in
   Section 6.2.1.  As a consequence, each site belonging to a VPN is
   assigned with a particular role in this topology.  The site-role leaf
   defines the role of the site in a particular VPN topology.

   In the any-to-any VPN service topology, all sites MUST have the same
   role, which will be "any-to-any-role".

   In the Hub-and-Spoke VPN service topology or the Hub and Spoke
   disjoint VPN service topology, sites MUST have a Hub role or a
   Spoke role.

Top      Up      ToC       Page 33 
6.5.  Site Belonging to Multiple VPNs

6.5.1.  Site VPN Flavor

   A site may be part of one or multiple VPNs.  The "site-vpn-flavor"
   defines the way the VPN multiplexing is done.  The current version of
   the model supports four flavors:

   o  site-vpn-flavor-single: The site belongs to only one VPN.

   o  site-vpn-flavor-multi: The site belongs to multiple VPNs, and all
      the logical accesses of the sites belong to the same set of VPNs.

   o  site-vpn-flavor-sub: The site belongs to multiple VPNs with
      multiple logical accesses.  Each logical access may map to
      different VPNs (one or many).

   o  site-vpn-flavor-nni: The site represents an option A NNI.

6.5.1.1.  Single VPN Attachment: site-vpn-flavor-single

   The figure below describes a single VPN attachment.  The site
   connects to only one VPN.

                                                      +--------+
   +------------------+             Site             /          \
   |                  |-----------------------------|            |
   |                  |***(site-network-access#1)***|    VPN1    |
   |  New York Office |                             |            |
   |                  |***(site-network-access#2)***|            |
   |                  |-----------------------------|            |
   +------------------+                              \          /
                                                      +--------+

6.5.1.2.  MultiVPN Attachment: site-vpn-flavor-multi

   The figure below describes a site connected to multiple VPNs.

                                                           +---------+
                                                      +---/----+      \
   +------------------+             Site             /   |      \      |
   |                  |--------------------------------- |       |VPN B|
   |                  |***(site-network-access#1)******* |       |     |
   |  New York Office |                             |    |       |     |
   |                  |***(site-network-access#2)*******  \      |    /
   |                  |-----------------------------| VPN A+-----|---+
   +------------------+                              \          /
                                                      +--------+

Top      Up      ToC       Page 34 
   In the example above, the New York office is multihomed.  Both
   logical accesses are using the same VPN attachment rules, and both
   are connected to VPN A and VPN B.

   Reaching VPN A or VPN B from the New York office will be done via
   destination-based routing.  Having the same destination reachable
   from the two VPNs may cause routing troubles.  The customer
   administration's role in this case would be to ensure the appropriate
   mapping of its prefixes in each VPN.

6.5.1.3.  SubVPN Attachment: site-vpn-flavor-sub

   The figure below describes a subVPN attachment.  The site connects to
   multiple VPNs, but each logical access is attached to a particular
   set of VPNs.  A typical use case for a subVPN is a customer site used
   by multiple affiliates with private resources for each affiliate that
   cannot be shared (communication between the affiliates is prevented).
   It is similar to having separate sites, but in this case the customer
   wants to share some physical components while maintaining strong
   communication isolation between the affiliates.  In this example,
   site-network-access#1 is attached to VPN B, while
   site-network-access#2 is attached to VPN A.

   +------------------+         Site                      +--------+
   |                  |----------------------------------/          \
   |                  |****(site-network-access#1)******|    VPN B   |
   |  New York Office |                                  \          /
   |                  |                                   +--------+
   |                  |                                   +--------+
   |                  |                                  /          \
   |                  |****(site-network-access#2)******|    VPN A   |
   |                  |                                  \          /
   |                  |                                   +--------+
   |                  |-----------------------------------
   +------------------+

Top      Up      ToC       Page 35 
   A multiVPN can be implemented in addition to a subVPN; as a
   consequence, each site-network-access can access multiple VPNs.  In
   the example below, site-network-access#1 is mapped to VPN B and
   VPN C, while site-network-access#2 is mapped to VPN A and VPN D.

   +-----------------+         Site                    +------+
   |                 |--------------------------------/       +-----+
   |                 |****(site-network-access#1)****| VPN B /       \
   | New York Office |                                \     |  VPN C  |
   |                 |                                 +-----\       /
   |                 |                                        +-----+
   |                 |
   |                 |                                 +-------+
   |                 |                                /        +-----+
   |                 |****(site-network-access#2)****| VPN A  /       \
   |                 |                                \      | VPN D   |
   |                 |                                 +------\       /
   |                 |---------------------------------        +-----+
   +-----------------+

   Multihoming is also possible with subVPNs; in this case,
   site-network-accesses are grouped, and a particular group will have
   access to the same set of VPNs.  In the example below,
   site-network-access#1 and site-network-access#2 are part of the same
   group (multihomed together) and are mapped to VPN B and VPN C; in
   addition, site-network-access#3 and site-network-access#4 are part of
   the same group (multihomed together) and are mapped to VPN A and
   VPN D.

   +-----------------+         Site                     +------+
   |                 |---------------------------------/       +-----+
   |                 |****(site-network-access#1)*****| VPN B /       \
   | New York Office |****(site-network-access#2)***** \     |  VPN C  |
   |                 |                                  +-----\       /
   |                 |                                         +-----+
   |                 |
   |                 |                                  +------+
   |                 |                                 /       +-----+
   |                 |****(site-network-access#3)*****| VPN A /       \
   |                 |****(site-network-access#4)***** \     | VPN D   |
   |                 |                                  +-----\       /
   |                 |----------------------------------       +-----+
   +-----------------+

   In terms of service configuration, a subVPN can be achieved by
   requesting that the site-network-access use the same bearer (see
   Sections 6.6.4 and 6.6.6.4 for more details).

Top      Up      ToC       Page 36 
6.5.1.4.  NNI: site-vpn-flavor-nni

   A Network-to-Network Interface (NNI) scenario may be modeled using
   the sites container (see Section 6.15.1).  Using the sites container
   to model an NNI is only one possible option for NNIs (see
   Section 6.15).  This option is called "option A" by reference to the
   option A NNI defined in [RFC4364].  It is helpful for the SP to
   indicate that the requested VPN connection is not a regular site but
   rather is an NNI, as specific default device configuration parameters
   may be applied in the case of NNIs (e.g., ACLs, routing policies).

          SP A                                             SP B
     -------------------                         -------------------
    /                   \                       /                   \
   |                     |                     |                     |
   |                 ++++++++ Inter-AS link ++++++++                 |
   |                 +      +_______________+      +                 |
   |                 +  (VRF1)---(VPN1)----(VRF1)  +                 |
   |                 + ASBR +               + ASBR +                 |
   |                 +  (VRF2)---(VPN2)----(VRF2)  +                 |
   |                 +      +_______________+      +                 |
   |                 ++++++++               ++++++++                 |
   |                     |                     |                     |
   |                     |                     |                     |
   |                     |                     |                     |
   |                 ++++++++ Inter-AS link ++++++++                 |
   |                 +      +_______________+      +                 |
   |                 +  (VRF1)---(VPN1)----(VRF1)  +                 |
   |                 + ASBR +               + ASBR +                 |
   |                 +  (VRF2)---(VPN2)----(VRF2)  +                 |
   |                 +      +_______________+      +                 |
   |                 ++++++++               ++++++++                 |
   |                     |                     |                     |
   |                     |                     |                     |
    \                   /                       \                   /
     -------------------                         -------------------

   The figure above describes an option A NNI scenario that can be
   modeled using the sites container.  In order to connect its customer
   VPNs (VPN1 and VPN2) in SP B, SP A may request the creation of some
   site-network-accesses to SP B.  The site-vpn-flavor-nni will be used
   to inform SP B that this is an NNI and not a regular customer site.
   The site-vpn-flavor-nni may be multihomed and multiVPN as well.

Top      Up      ToC       Page 37 
6.5.2.  Attaching a Site to a VPN

   Due to the multiple site-vpn flavors, the attachment of a site to an
   IP VPN is done at the site-network-access (logical access) level
   through the "vpn-attachment" container.  The vpn-attachment container
   is mandatory.  The model provides two ways to attach a site to a VPN:

   o  By referencing the target VPN directly.

   o  By referencing a VPN policy for attachments that are more complex.

   A choice is implemented to allow the user to choose the flavor that
   provides the best fit.

6.5.2.1.  Referencing a VPN

   Referencing a vpn-id provides an easy way to attach a particular
   logical access to a VPN.  This is the best way in the case of a
   single VPN attachment or subVPN with a single VPN attachment per
   logical access.  When referencing a vpn-id, the site-role setting
   must be added to express the role of the site in the target VPN
   service topology.

   <site>
    <site-id>SITE1</site-id>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>LA1</site-network-access-id>
      <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>LA2</site-network-access-id>
      <vpn-attachment>
       <vpn-id>VPNB</vpn-id>
       <site-role>spoke-role</site-role>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

   The example above describes a subVPN case where a site (SITE1) has
   two logical accesses (LA1 and LA2), with LA1 attached to VPNA and LA2
   attached to VPNB.

Top      Up      ToC       Page 38 
6.5.2.2.  VPN Policy

   The "vpn-policy" list helps express a multiVPN scenario where a
   logical access belongs to multiple VPNs.  Multiple VPN policies can
   be created to handle the subVPN case where each logical access is
   part of a different set of VPNs.

   As a site can belong to multiple VPNs, the vpn-policy list may be
   composed of multiple entries.  A filter can be applied to specify
   that only some LANs of the site should be part of a particular VPN.
   Each time a site (or LAN) is attached to a VPN, the user must
   precisely describe its role (site-role) within the target VPN service
   topology.

   +--------------------------------------------------------------+
   |       Site1 ------ PE7                                       |
   +-------------------------+                 [VPN2]             |
                             |                                    |
   +-------------------------+                                    |
   |       Site2 ------ PE3               PE4 ------ Site3        |
   +----------------------------------+                           |
                                      |                           |
   +------------------------------------------------------------+ |
   |       Site4 ------ PE5           |   PE6 ------ Site5      | |
   |                                                            | |
   |                      [VPN3]                                | |
   +------------------------------------------------------------+ |
                                      |                           |
                                      +---------------------------+

   In the example above, Site5 is part of two VPNs: VPN3 and VPN2.  It
   will play a Hub role in VPN2 and an any-to-any role in VPN3.  We can
   express such a multiVPN scenario as follows:

   <site>
    <site-id>Site5</site-id>
    <vpn-policies>
     <vpn-policy>
      <vpn-policy-id>POLICY1</vpn-policy-id>
      <entries>
       <id>ENTRY1</id>
       <vpn>
        <vpn-id>VPN2</vpn-id>
        <site-role>hub-role</site-role>
       </vpn>
      </entries>

Top      Up      ToC       Page 39 
      <entries>
       <id>ENTRY2</id>
       <vpn>
        <vpn-id>VPN3</vpn-id>
        <site-role>any-to-any-role</site-role>
       </vpn>
      </entries>
     </vpn-policy>
    </vpn-policies>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>LA1</site-network-access-id>
      <vpn-attachment>
       <vpn-policy-id>POLICY1</vpn-policy-id>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>

   Now, if a more-granular VPN attachment is necessary, filtering can be
   used.  For example, if LAN1 from Site5 must be attached to VPN2 as a
   Hub and LAN2 must be attached to VPN3, the following configuration
   can be used:

   <site>
    <site-id>Site5</site-id>
    <vpn-policies>
     <vpn-policy>
      <vpn-policy-id>POLICY1</vpn-policy-id>
      <entries>
       <id>ENTRY1</id>
       <filter>
        <lan-tag>LAN1</lan-tag>
       </filter>
       <vpn>
        <vpn-id>VPN2</vpn-id>
        <site-role>hub-role</site-role>
       </vpn>
      </entries>
      <entries>
       <id>ENTRY2</id>
       <filter>
        <lan-tag>LAN2</lan-tag>
       </filter>

Top      Up      ToC       Page 40 
       <vpn>
        <vpn-id>VPN3</vpn-id>
        <site-role>any-to-any-role</site-role>
       </vpn>
      </entries>
     </vpn-policy>
    </vpn-policies>
    <site-network-accesses>
     <site-network-access>
      <site-network-access-id>LA1</site-network-access-id>
      <vpn-attachment>
       <vpn-policy-id>POLICY1</vpn-policy-id>
      </vpn-attachment>
     </site-network-access>
    </site-network-accesses>
   </site>



(page 40 continued on part 3)

Next Section