RFC 8299
YANG Data Model for L3VPN Service Delivery
6.3. Site Overview
A site represents a connection of a customer office to one or more VPN services. Each site is associated with one or more locations. +-------------+ / \ +------------------+ +-----| 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. Alternatively, two or more sites can be associated with the same location, by referencing the same location ID. 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 defines 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, prefix length, and default gateway information. In the case of multiple site-network-access points belonging to the same VPN, address space allocated for one site-network-access should not conflict with one allocated for other site-network-accesses.
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 the case of a SubVPN, the customer can share some physical components at a single location, 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 Section 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. <?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"> <vpn-services> <vpn-service> <vpn-id>VPNA</vpn-id> </vpn-service> <vpn-service> <vpn-id>VPNB</vpn-id> </vpn-service> </vpn-services> <sites> <site> <site-id>SITE1</site-id> <locations> <location> <location-id>L1</location-id> </location> </locations> <management> <type>customer-managed</type> </management> <security> <encryption> <layer>layer3</layer> </encryption> </security> <site-network-accesses> <site-network-access> <site-network-access-id>LA1</site-network-access-id> <ip-connection> <ipv4> <address-allocation-type>provider-dhcp</address-allocation-type> </ipv4> <ipv6> <address-allocation-type>provider-dhcp</address-allocation-type> </ipv6> </ip-connection> <service> <svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<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>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
The example of a corresponding XML snippet 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 with the following XML snippet: <?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"> <vpn-services> <vpn-service> <vpn-id>VPN2</vpn-id> </vpn-service> <vpn-service> <vpn-id>VPN3</vpn-id> </vpn-service> </vpn-services> <sites> <site> <site-id>Site5</site-id> <devices>
<device>
<device-id>D1</device-id>
</device>
</devices>
<management>
<type>provider-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<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>
<device-reference>D1</device-reference>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
Now, if a more-granular VPN attachment is necessary, filtering can be
used. For example, if only LAN1 from Site5 must be attached to VPN2
as a Hub and only LAN2 must be attached to VPN3, the following XML
snippet can be used:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN2</vpn-id>
</vpn-service>
<vpn-service>
<vpn-id>VPN3</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Site5</site-id>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id>
<entries>
<id>ENTRY1</id>
<filters>
<filter>
<type>lan</type>
<lan-tag>LAN1</lan-tag>
</filter>
</filters>
<vpn>
<vpn-id>VPN2</vpn-id>
<site-role>hub-role</site-role>
</vpn>
</entries>
<entries>
<id>ENTRY2</id>
<filters>
<filter>
<type>lan</type>
<lan-tag>LAN2</lan-tag>
</filter>
</filters>
<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>
</sites>
</l3vpn-svc>
(page 47 continued on part 4)
