Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8466

A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery

Pages: 158
Proposed Standard
Errata
Part 3 of 8 – Pages 30 to 48
First   Prev   Next

Top   ToC   RFC8466 - Page 30   prevText

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.
Top   ToC   RFC8466 - Page 31
   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.
Top   ToC   RFC8466 - Page 32
   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).
Top   ToC   RFC8466 - Page 33
   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.
Top   ToC   RFC8466 - Page 34
   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.
Top   ToC   RFC8466 - Page 35
   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.
Top   ToC   RFC8466 - Page 36
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.
Top   ToC   RFC8466 - Page 37
   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.
Top   ToC   RFC8466 - Page 38
   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.
Top   ToC   RFC8466 - Page 39
   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
Top   ToC   RFC8466 - Page 40
   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
Top   ToC   RFC8466 - Page 41
   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>
Top   ToC   RFC8466 - Page 42
          <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>
Top   ToC   RFC8466 - Page 43
                     <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.
Top   ToC   RFC8466 - Page 44
     +---------------------------------------------------------------+
     |       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>
Top   ToC   RFC8466 - Page 45
           <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>
Top   ToC   RFC8466 - Page 46
                     <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>
Top   ToC   RFC8466 - Page 47
   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>
Top   ToC   RFC8466 - Page 48
                <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)

Next Section