RFC 8049
YANG Data Model for L3VPN Service Delivery
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.
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.
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.
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.
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.
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>
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.
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.
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.
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 |
\ /
+-------------+
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.
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.
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.
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
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.
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+-----|---+ +------------------+ \ / +--------+
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 | | | \ / | | +--------+ | |----------------------------------- +------------------+
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).
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.
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.
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>
<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>
<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)
