RFC 8466
A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
5.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 | \ / +-------------+ Figure 11: Example: Customer Office and Two VPN Services The provider uses the site container to store information regarding detailed implementation arrangements made with either the customer or peer operators at each interconnect location. We restrict the L2SM to exterior interfaces (i.e., UNIs and NNIs) only, so all internal interfaces and the underlying topology are outside the scope of the L2SM. Typically, the following characteristics of a site interface handoff need to be documented as part of the service design: Unique identifier (site-id): An arbitrary string to uniquely identify the site within the overall network infrastructure. The format of "site-id" is determined by the local administrator of the VPN service. Device (device): The customer can request one or more customer premises equipment entities from the SP for a particular site. Management (management): Defines the model of management for the site -- for example, type, management-transport, address. This parameter determines the boundary between the SP and the customer, i.e., who has ownership of the CE device. Location (location): The site location information. Allows easy retrieval of data about the nearest available resources. Site diversity (site-diversity): Presents some parameters to support site diversity.
Site network accesses (site-network-accesses): Defines the list of
ports to the site and their properties -- in particular, bearer,
connection, and service parameters.
A site-network-access represents an Ethernet logical connection to a
site. A site may have multiple site-network-accesses.
+------------------+ Site
| |-------------------------------------
| |****** (site-network-access#1) ******
| New York Office |
| |****** (site-network-access#2) ******
| |-------------------------------------
+------------------+
Figure 12: Two Site-Network-Accesses for a Site
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 parameters between the PE configuration and
the CE configuration.
The site may support single-homed access or multihoming. In the case
of multihoming, the site can support multiple site-network-accesses.
Under each site-network-access, "vpn-attachment" is defined;
vpn-attachment will describe the association between a given
site-network-access and a given site, as well as the VPN to which
that site will connect.
5.3.1. Devices and Locations
The information in the "location" sub-container under a site
container and in the "devices" container allows easy retrieval of
data about the nearest available facilities and can be used for
access topology planning. It may also be used by other network
orchestration components to choose the targeted upstream PE and
downstream CE. Location is expressed in terms of postal information.
More detailed information or other location information can be added
by augmentation.
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, where the office is composed of multiple buildings. Those buildings may be located in different parts of the city and may be linked by intra-city fibers (a customer metropolitan area network). This model does not represent connectivity between multiple locations of a site, because that connectivity is controlled by the customer. 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) ****** | +--------------+ |------------------------------------- +------------------+ Figure 13: Two Site-Network-Accesses, Two Sites A customer may also request the use of 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 requested for 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 Figure 13, 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 they want to implement: single CE, dual CE, etc.5.3.2. Site Network Accesses
The L2SM includes a set of essential physical interface properties and Ethernet-layer characteristics in the "site-network-accesses" container. Some of these are critical implementation arrangements that require consent from both the customer and the provider. As mentioned earlier, a site may be multihomed. Each logical 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 2).
o connection: defines Layer 2 protocol parameters of the attachment.
o availability: defines the site's availability policy. The
availability parameters are defined in Section 5.8.
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.
This site-network-access type may have an impact on the parameters
offered to the customer, e.g., an SP might not offer MAC loop
protection for multipoint accesses. It is up to the provider to
decide what parameters are supported for point-to-point and/or
multipoint accesses. Multipoint accesses are out of scope for this
document; some containers defined in the model may require extensions
in order to work properly for multipoint accesses.
5.3.2.1. Bearer
The "bearer" container defines the requirements for the site
attachment (below Layer 2) to the provider network.
The bearer parameters will help to determine the access media to
be used.
5.3.2.2. Connection
The "connection" container defines the Layer 2 protocol parameters of
the attachment (e.g., vlan-id or circuit-id) and provides
connectivity between customer Ethernet switches. Depending on the
management mode, it refers to PE-CE-LAN segment addressing or to
CE-to-customer-LAN segment 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-LAN segment connection.
For a provider-managed site, it refers to the CE-to-customer-LAN
segment connection.
The "encapsulation-type" parameter allows the user to select between
Ethernet encapsulation (port-based) or Ethernet VLAN encapsulation
(VLAN-based). All of the allowed Ethernet interface types of service
frames can be listed under "ether-inf-type", e.g., untagged
interface, tagged interface, LAG interface.
Corresponding to "ether-inf-type", the connection container also presents three sets of link attributes: untagged interface, tagged interface, and optional LAG interface attributes. These parameters are essential for the connection to be properly established between the CE devices and the PE devices. The connection container also defines a Layer 2 Control Protocol (L2CP) attribute that allows control-plane protocol interaction between the CE devices and the PE device.5.3.2.2.1. Untagged Interface
For each untagged interface (untagged-interface), there are basic configuration parameters like interface index and speed, interface MTU, auto-negotiation and flow-control settings, etc. In addition, and based on mutual agreement, the customer and provider may decide to enable advanced features, such as LLDP, IEEE 802.3ah [IEEE-802-3ah], or MAC loop detection/prevention at a UNI. If loop avoidance is required, the attribute "uni-loop-prevention" must be set to "true".5.3.2.2.2. Tagged Interface
If the tagged service is enabled on a logical unit on the connection at the interface, "encapsulation-type" should be specified as the Ethernet VLAN encapsulation (if VLAN-based) or VXLAN encapsulation, and "eth-inf-type" should be set to indicate a tagged interface. In addition, "tagged-interface-type" should be specified in the "tagged-interface" container to determine how tagging needs to be done. The current model defines five ways to perform VLAN tagging: o priority-tagged: SPs encapsulate and tag packets between the CE and the PE with the frame priority level. o dot1q-vlan-tagged: SPs encapsulate packets between the CE and the PE with one or a set of customer VLAN (CVLAN) IDs. o qinq: SPs encapsulate packets that enter their networks with multiple CVLAN IDs and a single VLAN tag with a single SP VLAN (SVLAN). o qinany: SPs encapsulate packets that enter their networks with unknown CVLANs and a single VLAN tag with a single SVLAN. o vxlan: SPs encapsulate packets that enter their networks with a VXLAN Network Identifier (VNI) and a peer list.
The overall S-tag for the Ethernet circuit and (if applicable) C-tag-to-SVC mapping (where "SVC" stands for "Switched Virtual Circuit") have been placed in the "service" container. For the qinq and qinany options, the S-tag under "qinq" and "qinany" should match the S-tag in the service container in most cases; however, VLAN translation is required for the S-tag in certain deployments at the external-facing interface or upstream PEs to "normalize" the outer VLAN tag to the service S-tag into the network and translate back to the site's S-tag in the opposite direction. One example of this is with a Layer 2 aggregation switch along the path: the S-tag for the SVC has been previously assigned to another service and thus cannot be used by this AC.5.3.2.2.3. LAG Interface
Sometimes, the customer may require multiple physical links bundled together to form a single, logical, point-to-point LAG connection to the SP. Typically, the Link Aggregation Control Protocol (LACP) is used to dynamically manage adding or deleting member links of the aggregate group. In general, a LAG allows for increased service bandwidth beyond the speed of a single physical link while providing graceful degradation as failure occurs, thus increasing availability. In the L2SM, there is a set of attributes under "lag-interface" related to link aggregation functionality. The customer and provider first need to decide on whether LACP PDUs will be exchanged between the edge devices by specifying the "LACP-state" as "on" or "off". If LACP is to be enabled, then both parties need to further specify (1) whether LACP will be running in active or passive mode and (2) the time interval and priority level of the LACP PDU. The customer and provider can also determine the minimum aggregate bandwidth for a LAG to be considered as a valid path by specifying the optional "mini-link-num" attribute. To enable fast detection of faulty links, micro-BFD [RFC7130] ("BFD" stands for "Bidirectional Forwarding Detection") runs independent UDP sessions to monitor the status of each member link. The customer and provider should agree on the BFD hello interval and hold time. Each member link will be listed under the LAG interface with basic physical link properties. Certain attributes, such as flow control, encapsulation type, allowed ingress Ethertype, and LLDP settings, are at the LAG level.
5.3.2.2.4. CVLAN-ID-to-SVC Mapping
When more than one service is multiplexed onto the same interface, ingress service frames are conditionally transmitted through one of the L2VPN services based upon a pre-arranged customer-VLAN-to-SVC mapping. Multiple CVLANs can be bundled across the same SVC. The bundling type will determine how a group of CVLANs is bundled into one VPN service (i.e., VLAN-bundling). When applicable, "cvlan-id-to-svc-map" contains the list of CVLANs that are mapped to the same service. In most cases, this will be the VLAN access-list for the inner 802.1Q tag [IEEE-802-1Q] (the C-tag). A VPN service can be set to preserve the CE-VLAN ID and CE-VLAN CoS from the source site to the destination site. This is required when the customer wants to use the VLAN header information between its two sites. CE-VLAN ID preservation and CE-VLAN CoS preservation are applied on each site-network-access within sites. "Preservation" means that the value of the CE-VLAN ID and/or CE-VLAN CoS at the source site must be equal to the value at a destination site belonging to the same L2VPN service. If all-to-one bundling is enabled (i.e., the bundling type is set to "all-to-one bundling"), then preservation applies to all ingress service frames. If all-to-one bundling is disabled, then preservation applies to tagged ingress service frames having the CE-VLAN ID.5.3.2.2.5. L2CP Control Support
The customer and the SP should arrange in advance whether or not to allow control-plane protocol interaction between the CE devices and the PE device. To provide seamless operation with multicast data transport, the transparent operation of Ethernet control protocols (e.g., the Spanning Tree Protocol (STP) [IEEE-802-1D]) can be employed by customers. To support efficient dynamic transport, Ethernet multicast control frames (e.g., GARP/GMRP [IEEE-802-1D]) can be used between the CE and the PE. However, solutions MUST NOT assume that all CEs are always running such protocols (typically in the case where a CE is a router and is not aware of Layer 2 details). The destination MAC addresses of these L2CP PDUs fall within two reserved blocks specified by the IEEE 802.1 Working Group. Packets with destination MAC addresses in these multicast ranges have special forwarding rules.
o Bridge block of protocols: 01-80-C2-00-00-00 through
01-80-C2-00-00-0F
o MRP block of protocols: 01-80-C2-00-00-20 through
01-80-C2-00-00-2F
Layer 2 protocol tunneling allows SPs to pass subscriber Layer 2
control PDUs across the network without being interpreted and
processed by intermediate network devices. These L2CP PDUs are
transparently encapsulated across the MPLS-enabled core network in
QinQ fashion.
The "L2CP-control" container contains the list of commonly used L2CP
protocols and parameters. The SP can specify discard-mode,
peer-mode, or tunnel-mode actions for each individual protocol.
5.3.2.2.6. Ethernet Service OAM
The advent of Ethernet as a wide-area network technology brings the
additional requirements of end-to-end service monitoring and fault
management in the SP network, particularly in the area of service
availability and Mean Time To Repair (MTTR). Ethernet Service OAM in
the L2SM refers to the combined protocol suites of IEEE 802.1ag
[IEEE-802-1ag] and ITU-T Y.1731 [ITU-T-Y-1731].
Generally speaking, Ethernet Service OAM enables SPs to perform
service continuity checks, fault isolation, and packet delay/jitter
measurement at per-customer and per-site-network-access granularity.
The information collected from Ethernet Service OAM data sets is
complementary to other higher-layer IP/MPLS OSS tools to ensure that
the required SLAs can be met.
The 802.1ag Connectivity Fault Management (CFM) functional model is
structured with hierarchical Maintenance Domains (MDs), each assigned
with a unique maintenance level. Higher-level MDs can be nested over
lower-level MDs. However, the MDs cannot intersect. The scope of
each MD can be solely within a customer network or solely within the
SP network. An MD can interact between CEs and PEs (customer-to-
provider) or between PEs (provider-to-provider), or it can tunnel
over another SP network.
Depending on the use-case scenario, one or more Maintenance Entity
Group End Points (MEPs) can be placed on the external-facing
interface, sending CFM PDUs towards the core network ("Up MEP") or
downstream link ("Down MEP").
The "cfm-802.1-ag" sub-container under "site-network-access" presents
the CFM Maintenance Association (MA), i.e., Down MEP for the UNI MA.
For each MA, the user can define the Maintenance Association Identifier (MAID), MEP level, MEP direction, Remote MEP ID, CoS level of the CFM PDUs, Continuity Check Message (CCM) interval and hold time, alarm-priority defect (i.e., the lowest-priority defect that is allowed to generate a fault alarm), CCM priority type, etc. ITU-T Y.1731 Performance Monitoring (PM) provides essential network telemetry information that includes the measurement of Ethernet service frame delay, frame delay variation, frame loss, and frame throughput. The delay/jitter measurement can be either one-way or two-way. Typically, a Y.1731 PM probe sends a small amount of synthetic frames along with service frames to measure the SLA parameters. The "y-1731" sub-container under "site-network-access" contains a set of parameters to define the PM probe information, including MAID, local and Remote MEP ID, PM PDU type, message period and measurement interval, CoS level of the PM PDUs, loss measurement by synthetic or service frame options, one-way or two-way delay measurement, PM frame size, and session type.5.4. Site Roles
A VPN has a particular service topology, as described in Section 5.2.2. As a consequence, each site belonging to a VPN is assigned 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.5.5. Site Belonging to Multiple VPNs
5.5.1. Site VPN Flavors
A site may be part of one or more VPNs. The "site-vpn-flavor" defines the way that the VPN multiplexing is done. There are four possible types of external-facing connections associated with an EVPN service and a site. Therefore, 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-nni: The site represents an NNI where two
administrative domains belonging to the same or different
providers interconnect.
o site-vpn-flavor-e2e: The site represents an end-to-end
multi-segment connection.
5.5.1.1. Single VPN Attachment: site-vpn-flavor-single
Figure 14 depicts a single VPN attachment. The site connects to only
one VPN.
+--------+
+------------------+ Site / \
| |-----------------------------| |
| |***(site-network-access#1)***| VPN1 |
| New York Office | | |
| |***(site-network-access#2)***| |
| |-----------------------------| |
+------------------+ \ /
+--------+
Figure 14: Single VPN Attachment
5.5.1.2. Multi-VPN Attachment: site-vpn-flavor-multi
Figure 15 shows a site connected to multiple VPNs.
+---------+
+---/----+ \
+------------------+ Site / | \ |
| |--------------------------------- | |VPN B|
| |***(site-network-access#1)******* | | |
| New York Office | | | | |
| |***(site-network-access#2)******* \ | /
| |-----------------------------| VPN A+-----|---+
+------------------+ \ /
+--------+
Figure 15: Multi-VPN Attachment
In Figure 15, the New York office is multihomed. Both logical
accesses are using the same VPN attachment rules, and both are
connected to VPN A and to VPN B.
Reaching VPN A or VPN B from the New York office will be done via MAC
destination-based forwarding. Having the same destination reachable
from the two VPNs may cause routing problems. The customer
administration's role in this case would be to ensure the appropriate mapping of its MAC addresses in each VPN. See Sections 5.5.2 and 5.10.2 for more details. See also Section 5.10.3 for details regarding support for BUM.5.5.1.3. NNI: site-vpn-flavor-nni
A Network-to-Network Interface (NNI) scenario may be modeled using the sites container. 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., Access Control Lists (ACLs), routing policies). SP A SP B ------------------- ------------------- / \ / \ | | | | | ++++++++ Inter-AS link ++++++++ | | + +_______________+ + | | + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+ | | + + + + | | + ASBR + + ASBR + | | + + + + | | + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+ | | + +_______________+ + | | ++++++++ ++++++++ | | | | | | | | | | | | | | ++++++++ Inter-AS link ++++++++ | | + +_______________+ + | | + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+ | | + + + + | | + ASBR + + ASBR + | | + + + + | | + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+ | | + +_______________+ + | | ++++++++ ++++++++ | | | | | | | | | \ / \ / ------------------- ------------------- Figure 16: Option A NNI Scenario
Figure 16 illustrates 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 type will be used to inform SP B that this is an NNI and not a regular customer site.5.5.1.4. E2E: site-vpn-flavor-e2e
An end-to-end (E2E) multi-segment VPN connection to be constructed out of several connectivity segments may be modeled. It is helpful for the SP to indicate that the requested VPN connection is not a regular site but rather is an end-to-end VPN connection, as specific default device configuration parameters may be applied in the case of site-vpn-flavor-e2e (e.g., QoS configuration). In order to establish a connection between Site 1 in SP A and Site 2 in SP B spanning multiple domains, SP A may request the creation of end-to-end connectivity to SP B. The site-vpn-flavor-e2e type will be used to indicate that this is an end-to-end connectivity setup and not a regular customer site.5.5.2. Attaching a Site to a VPN
Due to the multiple site-vpn flavors, the attachment of a site to an L2VPN 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. These options allow the user to choose the flavor that provides the best fit.5.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. 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"?> <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc"> <vpn-services> <vpn-service> <vpn-id>VPNA</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPNB</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</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>
<site-network-accesses>
<site-network-access>
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<network-access-id>LA2</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l2vpn-svc>
The example above describes a multi-VPN case where a site (SITE 1)
has two logical accesses (LA1 and LA2), attached to both VPNA and
VPNB.
5.5.2.2. VPN Policy
The "vpn-policy" list helps express a multi-VPN scenario where a
logical access belongs to multiple 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 at the site should be part of a particular VPN.
A site can be composed of multiple LAN segments, and each LAN segment
can be connected to a different 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.
+---------------------------------------------------------------+ | Site 1 ------ PE7 | +-------------------------+ [VPN2] | | | +-------------------------+ | | Site 2 ------ PE3 PE4 ------ Site 3 | +-----------------------------------+ | | | +-------------------------------------------------------------+ | | Site 4 ------ PE5 | PE6 ------ Site 5 | | | | | | [VPN3] | | +-------------------------------------------------------------+ | | | +----------------------------+ Figure 17: VPN Policy Example In Figure 17, Site 5 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 multi-VPN scenario as follows: <?xml version="1.0"?> <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc"> <vpn-services> <vpn-service> <vpn-id>VPN2</vpn-id> <ce-vlan-preservation>true</ce-vlan-preservation> <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation> </vpn-service> <vpn-service> <vpn-id>VPN3</vpn-id> <ce-vlan-preservation>true</ce-vlan-preservation> <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation> </vpn-service> </vpn-services> <sites> <site> <locations> <location> <location-id>L1</location-id> </location> </locations> <management> <type>customer-managed</type> </management> <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>
<network-access-id>LA1</network-access-id>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<site-network-accesses>
<site-network-access>
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<network-access-id>LA2</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l2vpn-svc>
Now, if a more granular VPN attachment is necessary, filtering can be
used. For example, if LAN1 from Site 5 must be attached to VPN2 as a
Hub and LAN2 must be attached to VPN3, the following configuration
can be used:
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN2</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPN3</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
<sites>
<site>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<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>
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l2vpn-svc>
(page 48 continued on part 4)
