summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8466.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8466.txt')
-rw-r--r--doc/rfc/rfc8466.txt8851
1 files changed, 8851 insertions, 0 deletions
diff --git a/doc/rfc/rfc8466.txt b/doc/rfc/rfc8466.txt
new file mode 100644
index 0000000..b71ca1e
--- /dev/null
+++ b/doc/rfc/rfc8466.txt
@@ -0,0 +1,8851 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Wen
+Request for Comments: 8466 Comcast
+Category: Standards Track G. Fioccola, Ed.
+ISSN: 2070-1721 Telecom Italia
+ C. Xie
+ China Telecom
+ L. Jalil
+ Verizon
+ October 2018
+
+
+ A YANG Data Model for
+ Layer 2 Virtual Private Network (L2VPN) Service Delivery
+
+Abstract
+
+ This document defines a YANG data model that can be used to configure
+ a Layer 2 provider-provisioned VPN service. It is up to a management
+ system to take this as an input and generate specific configuration
+ models to configure the different network elements to deliver the
+ service. How this configuration of network elements is done is out
+ of scope for this document.
+
+ The YANG data model defined in this document includes support for
+ point-to-point Virtual Private Wire Services (VPWSs) and multipoint
+ Virtual Private LAN Services (VPLSs) that use Pseudowires signaled
+ using the Label Distribution Protocol (LDP) and the Border Gateway
+ Protocol (BGP) as described in RFCs 4761 and 6624.
+
+ The YANG data model defined in this document conforms to the Network
+ Management Datastore Architecture defined in RFC 8342.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8466.
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 1]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+Copyright Notice
+
+ Copyright (c) 2018 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 5
+ 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. The Layer 2 VPN Service Model . . . . . . . . . . . . . . . . 7
+ 3.1. Layer 2 VPN Service Types . . . . . . . . . . . . . . . . 7
+ 3.2. Layer 2 VPN Physical Network Topology . . . . . . . . . . 7
+ 4. Service Data Model Usage . . . . . . . . . . . . . . . . . . 9
+ 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 11
+ 5.1. Features and Augmentation . . . . . . . . . . . . . . . . 20
+ 5.2. VPN Service Overview . . . . . . . . . . . . . . . . . . 20
+ 5.2.1. VPN Service Type . . . . . . . . . . . . . . . . . . 21
+ 5.2.2. VPN Service Topologies . . . . . . . . . . . . . . . 22
+ 5.2.2.1. Route Target Allocation . . . . . . . . . . . . . 22
+ 5.2.2.2. Any-to-Any . . . . . . . . . . . . . . . . . . . 22
+ 5.2.2.3. Hub-and-Spoke . . . . . . . . . . . . . . . . . . 22
+ 5.2.2.4. Hub-and-Spoke Disjoint . . . . . . . . . . . . . 23
+ 5.2.3. Cloud Access . . . . . . . . . . . . . . . . . . . . 24
+ 5.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 27
+ 5.2.5. Frame Delivery Service . . . . . . . . . . . . . . . 28
+ 5.3. Site Overview . . . . . . . . . . . . . . . . . . . . . . 30
+ 5.3.1. Devices and Locations . . . . . . . . . . . . . . . . 31
+ 5.3.2. Site Network Accesses . . . . . . . . . . . . . . . . 32
+ 5.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 33
+ 5.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 33
+ 5.4. Site Roles . . . . . . . . . . . . . . . . . . . . . . . 38
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 2]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 5.5. Site Belonging to Multiple VPNs . . . . . . . . . . . . . 38
+ 5.5.1. Site VPN Flavors . . . . . . . . . . . . . . . . . . 38
+ 5.5.1.1. Single VPN Attachment: site-vpn-flavor-single . . 39
+ 5.5.1.2. Multi-VPN Attachment: site-vpn-flavor-multi . . . 39
+ 5.5.1.3. NNI: site-vpn-flavor-nni . . . . . . . . . . . . 40
+ 5.5.1.4. E2E: site-vpn-flavor-e2e . . . . . . . . . . . . 41
+ 5.5.2. Attaching a Site to a VPN . . . . . . . . . . . . . . 41
+ 5.5.2.1. Referencing a VPN . . . . . . . . . . . . . . . . 41
+ 5.5.2.2. VPN Policy . . . . . . . . . . . . . . . . . . . 43
+ 5.6. Deciding Where to Connect the Site . . . . . . . . . . . 48
+ 5.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 49
+ 5.6.2. Constraint/Parameter: Site Location . . . . . . . . . 50
+ 5.6.3. Constraint/Parameter: Access Type . . . . . . . . . . 51
+ 5.6.4. Constraint: Access Diversity . . . . . . . . . . . . 52
+ 5.7. Route Distinguisher and Network Instance Allocation . . . 53
+ 5.8. Site-Network-Access Availability . . . . . . . . . . . . 54
+ 5.9. SVC MTU . . . . . . . . . . . . . . . . . . . . . . . . . 56
+ 5.10. Service . . . . . . . . . . . . . . . . . . . . . . . . . 56
+ 5.10.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 56
+ 5.10.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 57
+ 5.10.2.1. QoS Classification . . . . . . . . . . . . . . . 57
+ 5.10.2.2. QoS Profile . . . . . . . . . . . . . . . . . . 58
+ 5.10.3. Support for BUM . . . . . . . . . . . . . . . . . . 59
+ 5.11. Site Management . . . . . . . . . . . . . . . . . . . . . 60
+ 5.12. MAC Loop Protection . . . . . . . . . . . . . . . . . . . 61
+ 5.13. MAC Address Limit . . . . . . . . . . . . . . . . . . . . 61
+ 5.14. Enhanced VPN Features . . . . . . . . . . . . . . . . . . 62
+ 5.14.1. Carriers' Carriers . . . . . . . . . . . . . . . . . 62
+ 5.15. External ID References . . . . . . . . . . . . . . . . . 63
+ 5.16. Defining NNIs and Inter-AS Support . . . . . . . . . . . 64
+ 5.16.1. Defining an NNI with the Option A Flavor . . . . . . 66
+ 5.16.2. Defining an NNI with the Option B Flavor . . . . . . 70
+ 5.16.3. Defining an NNI with the Option C Flavor . . . . . . 73
+ 5.17. Applicability of L2SM in Inter-provider and Inter-domain
+ Orchestration . . . . . . . . . . . . . . . . . . . . . . 74
+ 6. Interaction with Other YANG Modules . . . . . . . . . . . . . 76
+ 7. Service Model Usage Example . . . . . . . . . . . . . . . . . 77
+ 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 82
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 152
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 153
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 153
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 153
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 155
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 157
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 3]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+1. Introduction
+
+ This document defines a YANG data model for the Layer 2 VPN (L2VPN)
+ service. This model defines service configuration elements that can
+ be used in communication protocols between customers and network
+ operators. Those elements can also be used as input to automated
+ control and configuration applications and can generate specific
+ configuration models to configure the different network elements to
+ deliver the service. How this configuration of network elements is
+ done is out of scope for this document.
+
+ Further discussion of the way that services are modeled in YANG and
+ the relationship between "customer service models" like the one
+ described in this document and configuration models can be found in
+ [RFC8309] and [RFC8199]. Sections 4 and 6 also provide more
+ information on how this service model could be used and how it fits
+ into the overall modeling architecture.
+
+ The YANG data model defined in this document includes support for
+ point-to-point Virtual Private Wire Services (VPWSs) and multipoint
+ Virtual Private LAN Services (VPLSs) that use Pseudowires signaled
+ using the Label Distribution Protocol (LDP) and the Border Gateway
+ Protocol (BGP) as described in [RFC4761] and [RFC6624]. It also
+ conforms to the Network Management Datastore Architecture (NMDA)
+ [RFC8342].
+
+1.1. Terminology
+
+ The following terms are defined in [RFC6241] and are not redefined
+ here:
+
+ o client
+
+ o configuration data
+
+ o server
+
+ o state data
+
+ The following terms are defined in [RFC7950] and are not redefined
+ here:
+
+ o augment
+
+ o data model
+
+ o data node
+
+
+
+
+Wen, et al. Standards Track [Page 4]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ The terminology for describing YANG data models is found in
+ [RFC7950].
+
+1.1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+1.2. Tree Diagrams
+
+ Tree diagrams used in this document follow the notation defined in
+ [RFC8340].
+
+2. Definitions
+
+ This document uses the following terms:
+
+ Service Provider (SP): The organization (usually a commercial
+ undertaking) responsible for operating the network that offers VPN
+ services to clients and customers.
+
+ Customer Edge (CE) Device: Equipment that is dedicated to a
+ particular customer and is directly connected to one or more PE
+ devices via Attachment Circuits (ACs). A CE is usually located at
+ the customer premises and is usually dedicated to a single VPN,
+ although it may support multiple VPNs if each one has separate
+ ACs. The CE devices can be routers, bridges, switches, or hosts.
+
+ Provider Edge (PE) Device: Equipment managed by the SP that can
+ support multiple VPNs for different customers and is directly
+ connected to one or more CE devices via ACs. A PE is usually
+ located at an SP Point of Presence (POP) and is managed by the SP.
+
+ Virtual Private LAN Service (VPLS): A VPLS is a provider service
+ that emulates the full functionality of a traditional LAN. A VPLS
+ makes it possible to interconnect several LAN segments over a
+ packet switched network (PSN) and makes the remote LAN segments
+ behave as one single LAN.
+
+ Virtual Private Wire Service (VPWS): A VPWS is a point-to-point
+ circuit (i.e., link) connecting two CE devices. The link is
+ established as a logical Layer 2 circuit through a PSN. The CE in
+ the customer network is connected to a PE in the provider network
+ via an AC: the AC is either a physical or logical circuit. A VPWS
+
+
+
+
+Wen, et al. Standards Track [Page 5]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ differs from a VPLS in that the VPLS is point-to-multipoint while
+ the VPWS is point-to-point. In some implementations, a set of
+ VPWSs is used to create a multi-site L2VPN network.
+
+ Pseudowire (PW): A Pseudowire is an emulation of a native service
+ over a PSN. The native service may be ATM, Frame Relay, Ethernet,
+ low-rate Time-Division Multiplexing (TDM), or Synchronous Optical
+ Network / Synchronous Digital Hierarchy (SONET/SDH), while the PSN
+ may be MPLS, IP (either IPv4 or IPv6), or Layer 2 Tunneling
+ Protocol version 3 (L2TPv3).
+
+ MAC-VRF: A Virtual Routing and Forwarding table for Media Access
+ Control (MAC) addresses on a PE. It is sometimes also referred to
+ as a Virtual Switching Instance (VSI).
+
+ UNI: User-to-Network Interface. The physical demarcation point
+ between the customer's area of responsibility and the provider's
+ area of responsibility.
+
+ NNI: Network-to-Network Interface. A reference point representing
+ the boundary between two networks that are operated as separate
+ administrative domains. The two networks may belong to the same
+ provider or to two different providers.
+
+ This document uses the following abbreviations:
+
+ BSS: Business Support System
+
+ BUM: Broadcast, Unknown Unicast, or Multicast
+
+ CoS: Class of Service
+
+ LAG: Link Aggregation Group
+
+ LLDP: Link Layer Discovery Protocol
+
+ OAM: Operations, Administration, and Maintenance
+
+ OSS: Operations Support System
+
+ PDU: Protocol Data Unit
+
+ QoS: Quality of Service
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 6]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+3. The Layer 2 VPN Service Model
+
+ A Layer 2 VPN (L2VPN) service is a collection of sites that are
+ authorized to exchange traffic between each other over a shared
+ infrastructure of a common technology. The L2VPN Service Model
+ (L2SM) described in this document provides a common understanding of
+ how the corresponding L2VPN service is to be deployed over the shared
+ infrastructure.
+
+ This document presents the L2SM using the YANG data modeling language
+ [RFC7950] as a formal language that is both human readable and
+ parsable by software for use with protocols such as the Network
+ Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040].
+
+ This service model is limited to VPWS-based VPNs and VPLS-based VPNs
+ as described in [RFC4761] and [RFC6624] and to Ethernet VPNs (EVPNs)
+ as described in [RFC7432].
+
+3.1. Layer 2 VPN Service Types
+
+ From a technology perspective, a set of basic L2VPN service types
+ include:
+
+ o Point-to-point VPWSs that use LDP-signaled Pseudowires or
+ L2TP-signaled Pseudowires [RFC6074].
+
+ o Multipoint VPLSs that use LDP-signaled Pseudowires or
+ L2TP-signaled Pseudowires [RFC6074].
+
+ o Multipoint VPLSs that use a BGP control plane as described in
+ [RFC4761] and [RFC6624].
+
+ o IP-only LAN Services (IPLSs) that are a functional subset of VPLS
+ services [RFC7436].
+
+ o BGP MPLS-based EVPN services as described in [RFC7432] and
+ [RFC7209].
+
+ o EVPN VPWSs as specified in [RFC8214].
+
+3.2. Layer 2 VPN Physical Network Topology
+
+ Figure 1 below depicts a typical SP's physical network topology.
+ Most SPs have deployed an IP, MPLS, or Segment Routing (SR)
+ multi-service core infrastructure. Ingress Layer 2 service frames
+ will be mapped to either an Ethernet Pseudowire (e.g., Pseudowire
+ Emulation Edge to Edge (PWE3)) or a Virtual Extensible Local Area
+
+
+
+
+Wen, et al. Standards Track [Page 7]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ Network (VXLAN) PE-to-PE tunnel. The details of these tunneling
+ mechanisms are left to the provider's discretion and are not part of
+ the L2SM.
+
+ An L2VPN provides end-to-end Layer 2 connectivity over this
+ multi-service core infrastructure between two or more customer
+ locations or a collection of sites. ACs are placed between CE
+ devices and PE devices that backhaul Layer 2 service frames from the
+ customer over the access network to the provider network or remote
+ site. The demarcation point (i.e., UNI) between the customer and the
+ SP can be placed between either (1) customer nodes and the CE device
+ or (2) the CE device and the PE device. The actual bearer connection
+ between the CE and the PE will be described in the L2SM.
+
+ The SP may also choose a "seamless MPLS" approach to expand the PWE3
+ or VXLAN tunnel between sites.
+
+ The SP may leverage Multiprotocol BGP (MP-BGP) to autodiscover and
+ signal the PWE3 or VXLAN tunnel endpoints.
+
+ Site A | |Site B
+ --- ---- | VXLAN/PW | ---
+ | | | | |<------------------------>| | |
+ | C +---+ CE | | | | C |
+ | | | | | --------- | | |
+ --- ----\ | ( ) | /---
+ \ -|-- ( ) -|-- ---- /
+ \| | ( ) | | | |/
+ | PE +---+ IP/MPLS/SR +---+ PE +---+ CE |
+ /| | ( Network ) | | | |\
+ / ---- ( ) ---- ---- \
+ --- ----/ ( ) \---
+ | | | | ----+---- | |
+ | C +---+ CE | | | C |
+ | | | | --+-- | |
+ --- ---- | PE | ---
+ --+--
+ | Site C
+ --+--
+ | CE |
+ --+--
+ |
+ --+--
+ | C |
+ -----
+
+ Figure 1: Reference Network for the Use of the L2SM
+
+
+
+
+Wen, et al. Standards Track [Page 8]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ From the customer's perspective, however, all the CE devices are
+ connected over a simulated LAN environment as shown in Figure 2.
+ Broadcast and multicast packets are sent to all participants in the
+ same bridge domain.
+
+ CE---+----+-----+---CE
+ | | |
+ | | |
+ | | |
+ CE---+ CE +---CE
+
+ Figure 2: Customer's View of the L2VPN
+
+4. Service Data Model Usage
+
+ The L2SM provides an abstracted interface to request, configure, and
+ manage the components of an L2VPN service. The model is used by a
+ customer who purchases connectivity and other services from an SP to
+ communicate with that SP.
+
+ A typical usage for this model is as an input to an orchestration
+ layer that is responsible for translating it into configuration
+ commands for the network elements that deliver/enable the service.
+ The network elements may be routers, but also servers (like
+ Authentication, Authorization, and Accounting (AAA)) that are
+ necessary within the network.
+
+ The configuration of network elements may be done using the Command
+ Line Interface (CLI) or any other configuration (or "southbound")
+ interface such as NETCONF [RFC6241] in combination with device-
+ specific and protocol-specific YANG data models.
+
+ This way of using the service model is illustrated in Figure 3 and is
+ described in more detail in [RFC8309] and [RFC8199]. The split of
+ the orchestration function between a "service orchestrator" and a
+ "network orchestrator" is clarified in [RFC8309]. The usage of this
+ service model is not limited to this example: it can be used by any
+ component of the management system but not directly by network
+ elements.
+
+ The usage and structure of this model should be compared to the
+ Layer 3 VPN service model defined in [RFC8299].
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 9]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ ----------------------------
+ | Customer Service Requester |
+ ----------------------------
+ |
+ |
+ L2SM |
+ |
+ |
+ -----------------------
+ | Service Orchestration |
+ -----------------------
+ |
+ | Service +-------------+
+ | Delivery +------>| Application |
+ | Model | | BSS/OSS |
+ | V +-------------+
+ -----------------------
+ | Network Orchestration |
+ -----------------------
+ | |
+ +----------------+ |
+ | Config manager | |
+ +----------------+ | Device
+ | | Models
+ | |
+ --------------------------------------------
+ Network
+ +++++++
+ + AAA +
+ +++++++
+
+ ++++++++ Bearer ++++++++ ++++++++ ++++++++
+ + CE A + ----------- + PE A + + PE B + ---- + CE B +
+ ++++++++ Connection ++++++++ ++++++++ ++++++++
+
+ Site A Site B
+
+ Figure 3: Reference Architecture for the Use of the L2SM
+
+ The Metro Ethernet Forum (MEF) [MEF-6] has also developed an
+ architecture for network management and operations, but the work of
+ the MEF embraces all aspects of lifecycle service orchestration,
+ including billing, Service Level Agreements (SLAs), order management,
+ and lifecycle management. The IETF's work on service models is
+ typically smaller and offers a simple, self-contained service YANG
+ module. See [RFC8309] for more details.
+
+
+
+
+
+Wen, et al. Standards Track [Page 10]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5. Design of the Data Model
+
+ The L2SM is structured in a way that allows the provider to list
+ multiple circuits of various service types for the same customer. A
+ circuit represents an end-to-end connection between two or more
+ customer locations.
+
+ The YANG module is divided into two main containers: "vpn-services"
+ and "sites". The "vpn-svc" container under vpn-services defines
+ global parameters for the VPN service for a specific customer.
+
+ A site contains at least one network access (i.e., site network
+ accesses providing access to the sites, as defined in Section 5.3.2),
+ and there may be multiple network accesses in the case of
+ multihoming. Site-to-network-access attachment is done through a
+ bearer with a Layer 2 connection on top. The bearer refers to
+ properties of the attachment that are below Layer 2, while the
+ connection refers to Layer 2 protocol-oriented properties. The
+ bearer may be allocated dynamically by the SP, and the customer may
+ provide some constraints or parameters to drive the placement.
+
+ Authorization of traffic exchanges is done through what we call a VPN
+ policy or VPN topology that defines routing exchange rules between
+ sites.
+
+ End-to-end multi-segment connectivity can be realized by using a
+ combination of per-site connectivity and per-segment connectivity at
+ different segments.
+
+ Figure 4 shows the overall structure of the YANG module:
+
+ module: ietf-l2vpn-svc
+ +--rw l2vpn-svc
+ +--rw vpn-profiles
+ | +--rw valid-provider-identifiers
+ | +--rw cloud-identifier* string{cloud-access}?
+ | +--rw qos-profile-identifier* string
+ | +--rw bfd-profile-identifier* string
+ | +--rw remote-carrier-identifier* string
+ +--rw vpn-services
+ | +--rw vpn-service* [vpn-id]
+ | +--rw vpn-id svc-id
+ | +--rw vpn-svc-type? identityref
+ | +--rw customer-name? string
+ | +--rw svc-topo? identityref
+ | +--rw cloud-accesses {cloud-access}?
+ | | +--rw cloud-access* [cloud-identifier]
+ | | +--rw cloud-identifier
+
+
+
+Wen, et al. Standards Track [Page 11]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ | | | -> /l2vpn-svc/vpn-profiles/
+ | | | valid-provider-identifiers/cloud-identifier
+ | | +--rw (list-flavor)?
+ | | +--:(permit-any)
+ | | | +--rw permit-any? empty
+ | | +--:(deny-any-except)
+ | | | +--rw permit-site*
+ | | | : -> /l2vpn-svc/sites/site/site-id
+ | | +--:(permit-any-except)
+ | | +--rw deny-site*
+ | | -> /l2vpn-svc/sites/site/site-id
+ | +--rw frame-delivery {frame-delivery}?
+ | | +--rw customer-tree-flavors
+ | | | +--rw tree-flavor* identityref
+ | | +--rw bum-frame-delivery
+ | | | +--rw bum-frame-delivery* [frame-type]
+ | | | +--rw frame-type identityref
+ | | | +--rw delivery-mode? identityref
+ | | +--rw multicast-gp-port-mapping identityref
+ | +--rw extranet-vpns {extranet-vpn}?
+ | | +--rw extranet-vpn* [vpn-id]
+ | | +--rw vpn-id svc-id
+ | | +--rw local-sites-role? identityref
+ | +--rw ce-vlan-preservation boolean
+ | +--rw ce-vlan-cos-preservation boolean
+ | +--rw carrierscarrier? boolean {carrierscarrier}?
+ +--rw sites
+ +--rw site* [site-id]
+ +--rw site-id string
+ +--rw site-vpn-flavor? identityref
+ +--rw devices
+ | +--rw device* [device-id]
+ | +--rw device-id string
+ | +--rw location
+ | | -> ../../../locations/location/location-id
+ | +--rw management
+ | +--rw transport? identityref
+ | +--rw address? inet:ip-address
+ +--rw management
+ | +--rw type identityref
+ +--rw locations
+ | +--rw location* [location-id]
+ | +--rw location-id string
+ | +--rw address? string
+ | +--rw postal-code? string
+ | +--rw state? string
+ | +--rw city? string
+ | +--rw country-code? string
+
+
+
+Wen, et al. Standards Track [Page 12]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ +--rw site-diversity {site-diversity}?
+ | +--rw groups
+ | +--rw group* [group-id]
+ | +--rw group-id string
+ +--rw vpn-policies
+ | +--rw vpn-policy* [vpn-policy-id]
+ | +--rw vpn-policy-id string
+ | +--rw entries* [id]
+ | +--rw id string
+ | +--rw filters
+ | | +--rw filter* [type]
+ | | +--rw type identityref
+ | | +--rw lan-tag* uint32 {lan-tag}?
+ | +--rw vpn* [vpn-id]
+ | +--rw vpn-id
+ | | -> /l2vpn-svc/vpn-services/
+ | | vpn-service/vpn-id
+ | +--rw site-role? identityref
+ +--rw service
+ | +--rw qos {qos}?
+ | | +--rw qos-classification-policy
+ | | | +--rw rule* [id]
+ | | | +--rw id string
+ | | | +--rw (match-type)?
+ | | | | +--:(match-flow)
+ | | | | | +--rw match-flow
+ | | | | | +--rw dscp? inet:dscp
+ | | | | | +--rw dot1q? uint16
+ | | | | | +--rw pcp? uint8
+ | | | | | +--rw src-mac? yang:mac-address
+ | | | | | +--rw dst-mac? yang:mac-address
+ | | | | | +--rw color-type? identityref
+ | | | | | +--rw target-sites*
+ | | | | | | svc-id {target-sites}?
+ | | | | | +--rw any? empty
+ | | | | | +--rw vpn-id? svc-id
+ | | | | +--:(match-application)
+ | | | | +--rw match-application? identityref
+ | | | +--rw target-class-id? string
+ | | +--rw qos-profile
+ | | +--rw (qos-profile)?
+ | | +--:(standard)
+ | | | +--rw profile?
+ | | | -> /l2vpn-svc/vpn-profiles/
+ | | | valid-provider-identifiers/
+ | | | qos-profile-identifier
+ | | +--:(custom)
+ | | +--rw classes {qos-custom}?
+
+
+
+Wen, et al. Standards Track [Page 13]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ | | +--rw class* [class-id]
+ | | +--rw class-id string
+ | | +--rw direction? identityref
+ | | +--rw policing? identityref
+ | | +--rw byte-offset? uint16
+ | | +--rw frame-delay
+ | | | +--rw (flavor)?
+ | | | +--:(lowest)
+ | | | | +--rw use-lowest-latency? empty
+ | | | +--:(boundary)
+ | | | +--rw delay-bound? uint16
+ | | +--rw frame-jitter
+ | | | +--rw (flavor)?
+ | | | +--:(lowest)
+ | | | | +--rw use-lowest-jitter? empty
+ | | | +--:(boundary)
+ | | | +--rw delay-bound? uint32
+ | | +--rw frame-loss
+ | | | +--rw rate? decimal64
+ | | +--rw bandwidth
+ | | +--rw guaranteed-bw-percent decimal64
+ | | +--rw end-to-end? empty
+ | +--rw carrierscarrier {carrierscarrier}?
+ | +--rw signaling-type? identityref
+ +--rw broadcast-unknown-unicast-multicast {bum}?
+ | +--rw multicast-site-type? enumeration
+ | +--rw multicast-gp-address-mapping* [id]
+ | | +--rw id uint16
+ | | +--rw vlan-id uint16
+ | | +--rw mac-gp-address yang:mac-address
+ | | +--rw port-lag-number? uint32
+ | +--rw bum-overall-rate? uint32
+ | +--rw bum-rate-per-type* [type]
+ | +--rw type identityref
+ | +--rw rate? uint32
+ +--rw mac-loop-prevention {mac-loop-prevention}?
+ | +--rw protection-type? identityref
+ | +--rw frequency? uint32
+ | +--rw retry-timer? uint32
+ +--rw access-control-list
+ | +--rw mac* [mac-address]
+ | +--rw mac-address yang:mac-address
+ +--ro actual-site-start? yang:date-and-time
+ +--ro actual-site-stop? yang:date-and-time
+ +--rw bundling-type? identityref
+ +--rw default-ce-vlan-id uint32
+ +--rw site-network-accesses
+ +--rw site-network-access* [network-access-id]
+
+
+
+Wen, et al. Standards Track [Page 14]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ +--rw network-access-id string
+ +--rw remote-carrier-name? string
+ +--rw type? identityref
+ +--rw (location-flavor)
+ | +--:(location)
+ | | +--rw location-reference?
+ | | -> ../../../locations/location/
+ | | location-id
+ | +--:(device)
+ | +--rw device-reference?
+ | -> ../../../devices/device/device-id
+ +--rw access-diversity {site-diversity}?
+ | +--rw groups
+ | | +--rw group* [group-id]
+ | | +--rw group-id string
+ | +--rw constraints
+ | +--rw constraint* [constraint-type]
+ | +--rw constraint-type identityref
+ | +--rw target
+ | +--rw (target-flavor)?
+ | +--:(id)
+ | | +--rw group* [group-id]
+ | | +--rw group-id string
+ | +--:(all-accesses)
+ | | +--rw all-other-accesses? empty
+ | +--:(all-groups)
+ | +--rw all-other-groups? empty
+ +--rw bearer
+ | +--rw requested-type {requested-type}?
+ | | +--rw type? string
+ | | +--rw strict? boolean
+ | +--rw always-on? boolean {always-on}?
+ | +--rw bearer-reference? string {bearer-reference}?
+ +--rw connection
+ | +--rw encapsulation-type? identityref
+ | +--rw eth-inf-type? identityref
+ | +--rw tagged-interface
+ | | +--rw type? identityref
+ | | +--rw dot1q-vlan-tagged {dot1q}?
+ | | | +--rw tg-type? identityref
+ | | | +--rw cvlan-id uint16
+ | | +--rw priority-tagged
+ | | | +--rw tag-type? identityref
+ | | +--rw qinq {qinq}?
+ | | | +--rw tag-type? identityref
+ | | | +--rw svlan-id uint16
+ | | | +--rw cvlan-id uint16
+ | | +--rw qinany {qinany}?
+
+
+
+Wen, et al. Standards Track [Page 15]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ | | | +--rw tag-type? identityref
+ | | | +--rw svlan-id uint16
+ | | +--rw vxlan {vxlan}?
+ | | +--rw vni-id uint32
+ | | +--rw peer-mode? identityref
+ | | +--rw peer-list* [peer-ip]
+ | | +--rw peer-ip inet:ip-address
+ | +--rw untagged-interface
+ | | +--rw speed? uint32
+ | | +--rw mode? neg-mode
+ | | +--rw phy-mtu? uint32
+ | | +--rw lldp? boolean
+ | | +--rw oam-802.3ah-link {oam-3ah}?
+ | | | +--rw enabled? boolean
+ | | +--rw uni-loop-prevention? boolean
+ | +--rw lag-interfaces {lag-interface}?
+ | | +--rw lag-interface* [index]
+ | | +--rw index string
+ | | +--rw lacp {lacp}?
+ | | +--rw enabled? boolean
+ | | +--rw mode? neg-mode
+ | | +--rw speed? uint32
+ | | +--rw mini-link-num? uint32
+ | | +--rw system-priority? uint16
+ | | +--rw micro-bfd {micro-bfd}?
+ | | | +--rw enabled? enumeration
+ | | | +--rw interval? uint32
+ | | | +--rw hold-timer? uint32
+ | | +--rw bfd {bfd}?
+ | | | +--rw enabled? boolean
+ | | | +--rw (holdtime)?
+ | | | +--:(profile)
+ | | | | +--rw profile-name?
+ | | | | -> /l2vpn-svc/
+ | | | | vpn-profiles/
+ | | | | valid-provider-identifiers/
+ | | | | bfd-profile-identifier
+ | | | +--:(fixed)
+ | | | +--rw fixed-value? uint32
+ | | +--rw member-links
+ | | | +--rw member-link* [name]
+ | | | +--rw name string
+ | | | +--rw speed? uint32
+ | | | +--rw mode? neg-mode
+ | | | +--rw link-mtu? uint32
+ | | | +--rw oam-802.3ah-link {oam-3ah}?
+ | | | +--rw enabled? boolean
+ | | +--rw flow-control? boolean
+
+
+
+Wen, et al. Standards Track [Page 16]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ | | +--rw lldp? boolean
+ | +--rw cvlan-id-to-svc-map* [svc-id]
+ | | +--rw svc-id
+ | | | -> /l2vpn-svc/vpn-services/vpn-service/
+ | | | vpn-id
+ | | +--rw cvlan-id* [vid]
+ | | +--rw vid uint16
+ | +--rw l2cp-control {l2cp-control}?
+ | | +--rw stp-rstp-mstp? control-mode
+ | | +--rw pause? control-mode
+ | | +--rw lacp-lamp? control-mode
+ | | +--rw link-oam? control-mode
+ | | +--rw esmc? control-mode
+ | | +--rw l2cp-802.1x? control-mode
+ | | +--rw e-lmi? control-mode
+ | | +--rw lldp? boolean
+ | | +--rw ptp-peer-delay? control-mode
+ | | +--rw garp-mrp? control-mode
+ | +--rw oam {oam}
+ | +--rw md-name string
+ | +--rw md-level uint16
+ | +--rw cfm-802.1-ag* [maid]
+ | | +--rw maid string
+ | | +--rw mep-id? uint32
+ | | +--rw mep-level? uint32
+ | | +--rw mep-up-down? enumeration
+ | | +--rw remote-mep-id? uint32
+ | | +--rw cos-for-cfm-pdus? uint32
+ | | +--rw ccm-interval? uint32
+ | | +--rw ccm-holdtime? uint32
+ | | +--rw alarm-priority-defect? identityref
+ | | +--rw ccm-p-bits-pri? ccm-priority-type
+ | +--rw y-1731* [maid]
+ | +--rw maid string
+ | +--rw mep-id? uint32
+ | +--rw type? identityref
+ | +--rw remote-mep-id? uint32
+ | +--rw message-period? uint32
+ | +--rw measurement-interval? uint32
+ | +--rw cos? uint32
+ | +--rw loss-measurement? boolean
+ | +--rw synthetic-loss-measurement? boolean
+ | +--rw delay-measurement
+ | | +--rw enable-dm? boolean
+ | | +--rw two-way? boolean
+ | +--rw frame-size? uint32
+ | +--rw session-type? enumeration
+ +--rw availability
+
+
+
+Wen, et al. Standards Track [Page 17]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ | +--rw access-priority? uint32
+ | +--rw (redundancy-mode)?
+ | +--:(single-active)
+ | | +--rw single-active? empty
+ | +--:(all-active)
+ | +--rw all-active? empty
+ +--rw vpn-attachment
+ | +--rw (attachment-flavor)
+ | +--:(vpn-id)
+ | | +--rw vpn-id?
+ | | | -> /l2vpn-svc/vpn-services/
+ | | | vpn-service/vpn-id
+ | | +--rw site-role? identityref
+ | +--:(vpn-policy-id)
+ | +--rw vpn-policy-id?
+ | -> ../../../../vpn-policies/
+ | vpn-policy/vpn-policy-id
+ +--rw service
+ | +--rw svc-bandwidth {input-bw}?
+ | | +--rw bandwidth* [direction type]
+ | | +--rw direction identityref
+ | | +--rw type identityref
+ | | +--rw cos-id? uint8
+ | | +--rw vpn-id? svc-id
+ | | +--rw cir uint64
+ | | +--rw cbs uint64
+ | | +--rw eir? uint64
+ | | +--rw ebs? uint64
+ | | +--rw pir? uint64
+ | | +--rw pbs? uint64
+ | +--rw svc-mtu uint16
+ | +--rw qos {qos}?
+ | | +--rw qos-classification-policy
+ | | | +--rw rule* [id]
+ | | | +--rw id string
+ | | | +--rw (match-type)?
+ | | | | +--:(match-flow)
+ | | | | | +--rw match-flow
+ | | | | | +--rw dscp? inet:dscp
+ | | | | | +--rw dot1q? uint16
+ | | | | | +--rw pcp? uint8
+ | | | | | +--rw src-mac? yang:mac-address
+ | | | | | +--rw dst-mac? yang:mac-address
+ | | | | | +--rw color-type? identityref
+ | | | | | +--rw target-sites*
+ | | | | | | svc-id {target-sites}?
+ | | | | | +--rw any? empty
+ | | | | | +--rw vpn-id? svc-id
+
+
+
+Wen, et al. Standards Track [Page 18]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ | | | | +--:(match-application)
+ | | | | +--rw match-application? identityref
+ | | | +--rw target-class-id? string
+ | | +--rw qos-profile
+ | | +--rw (qos-profile)?
+ | | +--:(standard)
+ | | | +--rw profile?
+ | | | -> /l2vpn-svc/vpn-profiles/
+ | | | valid-provider-identifiers/
+ | | | qos-profile-identifier
+ | | +--:(custom)
+ | | +--rw classes {qos-custom}?
+ | | +--rw class* [class-id]
+ | | +--rw class-id string
+ | | +--rw direction? identityref
+ | | +--rw policing? identityref
+ | | +--rw byte-offset? uint16
+ | | +--rw frame-delay
+ | | | +--rw (flavor)?
+ | | | +--:(lowest)
+ | | | | +--rw use-lowest-latency?
+ | | | | empty
+ | | | +--:(boundary)
+ | | | +--rw delay-bound? uint16
+ | | +--rw frame-jitter
+ | | | +--rw (flavor)?
+ | | | +--:(lowest)
+ | | | | +--rw use-lowest-jitter?
+ | | | | empty
+ | | | +--:(boundary)
+ | | | +--rw delay-bound? uint32
+ | | +--rw frame-loss
+ | | | +--rw rate? decimal64
+ | | +--rw bandwidth
+ | | +--rw guaranteed-bw-percent
+ | | | decimal64
+ | | +--rw end-to-end? empty
+ | +--rw carrierscarrier {carrierscarrier}?
+ | +--rw signaling-type? identityref
+ +--rw broadcast-unknown-unicast-multicast {bum}?
+ | +--rw multicast-site-type? enumeration
+ | +--rw multicast-gp-address-mapping* [id]
+ | | +--rw id uint16
+ | | +--rw vlan-id uint16
+ | | +--rw mac-gp-address yang:mac-address
+ | | +--rw port-lag-number? uint32
+ | +--rw bum-overall-rate? uint32
+ | +--rw bum-rate-per-type* [type]
+
+
+
+Wen, et al. Standards Track [Page 19]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ | +--rw type identityref
+ | +--rw rate? uint32
+ +--rw mac-loop-prevention {mac-loop-prevention}?
+ | +--rw protection-type? identityref
+ | +--rw frequency? uint32
+ | +--rw retry-timer? uint32
+ +--rw access-control-list
+ | +--rw mac* [mac-address]
+ | +--rw mac-address yang:mac-address
+ +--rw mac-addr-limit
+ +--rw limit-number? uint16
+ +--rw time-interval? uint32
+ +--rw action? identityref
+
+ Figure 4: Overall Structure of the YANG Module
+
+5.1. Features and Augmentation
+
+ The model defined in this document implements many features that
+ allow implementations to be modular. As an example, the Layer 2
+ protocol parameters (Section 5.3.2.2) proposed to the customer may
+ also be enabled through features. This model also defines some
+ features for options that are more advanced, such as support for
+ extranet VPNs (Section 5.2.4), site diversity (Section 5.3), and QoS
+ (Section 5.10.2).
+
+ In addition, as for any YANG data model, this service model can be
+ augmented to implement new behaviors or specific features. For
+ example, this model defines VXLAN [RFC7348] for Ethernet packet
+ encapsulation; if VXLAN encapsulation does not fulfill all
+ requirements for describing the service, new options can be added
+ through augmentation.
+
+5.2. VPN Service Overview
+
+ The vpn-service list item contains generic information about the VPN
+ service. The vpn-id in the vpn-service list refers to an internal
+ reference for this VPN service. This identifier is purely internal
+ to the organization responsible for the VPN service.
+
+ The vpn-service list is composed of the following characteristics:
+
+ Customer information (customer-name): Used to identify the customer.
+
+ VPN service type (vpn-svc-type): Used to indicate the VPN service
+ type. The identifier is an identity allowing any encoding for the
+ local administration of the VPN service. Note that another
+ identity can be an extension of the base identity.
+
+
+
+Wen, et al. Standards Track [Page 20]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ Cloud access (cloud-access): All sites in the L2VPN SHOULD be
+ permitted to access the cloud by default. The "cloud-access"
+ container provides parameters for authorization rules. A cloud
+ identifier is used to reference the target service. This
+ identifier is local to each administration.
+
+ Service topology (svc-topo): Used to identify the type of VPN
+ service topology that is required.
+
+ Frame delivery service (frame-delivery): Defines the frame delivery
+ support required for the L2VPN, e.g., multicast delivery, unicast
+ delivery, or broadcast delivery.
+
+ Extranet VPN (extranet-vpns): Indicates that a particular VPN needs
+ access to resources located in another VPN.
+
+5.2.1. VPN Service Type
+
+ The "vpn-svc-type" parameter defines the service type for provider-
+ provisioned L2VPNs. The current version of the model supports six
+ flavors:
+
+ o Point-to-point VPWSs connecting two customer sites.
+
+ o Point-to-point or point-to-multipoint VPWSs connecting a set of
+ customer sites [RFC8214].
+
+ o Multipoint VPLSs connecting a set of customer sites.
+
+ o Multipoint VPLSs connecting one or more root sites and a set of
+ leaf sites but preventing inter-leaf-site communication.
+
+ o EVPN services [RFC7432] connecting a set of customer sites.
+
+ o EVPN VPWSs between two customer sites or a set of customer sites
+ as specified in [RFC8214].
+
+ Other L2VPN service types could be included by augmentation. Note
+ that an Ethernet Private Line (EPL) service or an Ethernet Virtual
+ Private Line (EVPL) service is an Ethernet Line (E-Line) service
+ [MEF-6]or a point-to-point Ethernet Virtual Circuit (EVC) service,
+ while an Ethernet Private LAN (EP-LAN) service or an Ethernet Virtual
+ Private LAN (EVP-LAN) service is an Ethernet LAN (E-LAN) service
+ [MEF-6] or a multipoint-to-multipoint EVC service.
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 21]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5.2.2. VPN Service Topologies
+
+ The types of VPN service topologies discussed below can be used for
+ configuration if needed. The module described in this document
+ currently 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 by augmentation. By
+ default, the any-to-any VPN service topology is used.
+
+5.2.2.1. Route Target Allocation
+
+ A Layer 2 PE-based VPN (such as a VPLS-based VPN or an EVPN that uses
+ BGP as its signaling protocol) can be built using Route Targets (RTs)
+ as described in [RFC4364] and [RFC7432]. 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 in Section 6.2.1.1 of [RFC8299].
+
+5.2.2.2. Any-to-Any
+
+ +--------------------------------------------------------------+
+ | VPN1_Site 1 ------ PE1 PE2 ------ VPN1_Site 2 |
+ | |
+ | VPN1_Site 3 ------ PE3 PE4 ------ VPN1_Site 4 |
+ +--------------------------------------------------------------+
+
+ Figure 5: 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 L2VPN service request through this model is
+ expected to assign and then configure the MAC-VRF and RTs on the
+ appropriate PEs. In the any-to-any case, a single RT is generally
+ required, and every MAC-VRF imports and exports this RT.
+
+5.2.2.3. Hub-and-Spoke
+
+ +---------------------------------------------------------------+
+ | Hub_Site 1 ------ PE1 PE2 ------ Spoke_Site 1 |
+ | +------------------------------------+
+ | |
+ | +------------------------------------+
+ | Hub_Site 2 ------ PE3 PE4 ------ Spoke_Site 2 |
+ +---------------------------------------------------------------+
+
+ Figure 6: Hub-and-Spoke VPN Service Topology
+
+
+
+
+Wen, et al. Standards Track [Page 22]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ In the Hub-and-Spoke VPN service topology,
+
+ o all Spoke sites can communicate only with Hub sites (i.e., Spoke
+ sites cannot communicate with each other).
+
+ o Hubs can communicate with each other.
+
+ The management system that receives a Hub-and-Spoke L2VPN service
+ request through this model is expected to assign and then configure
+ the MAC-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 MAC-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 MAC-VRF that connects Spoke sites
+ will export Spoke routes with the Spoke RT and will import Hub routes
+ through the Hub RT.
+
+5.2.2.4. Hub-and-Spoke Disjoint
+
+ +---------------------------------------------------------------+
+ | Hub_Site 1 ------ PE1 PE2 ------ Spoke_Site 1 |
+ +--------------------------+ +---------------------------------+
+ | |
+ +--------------------------+ +---------------------------------+
+ | Hub_Site 2 ------ PE3 PE4 ------ Spoke_Site 2 |
+ +---------------------------------------------------------------+
+
+ Figure 7: Hub-and-Spoke-Disjoint VPN Service Topology
+
+ In the Hub-and-Spoke-Disjoint VPN service topology,
+
+ o all Spoke sites can communicate only with Hub sites (i.e., Spoke
+ sites cannot communicate with each other).
+
+ o Hubs cannot communicate with each other.
+
+ The management system that receives a Hub-and-Spoke-Disjoint L2VPN
+ 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-Disjoint case, at least two RTs are required for Hubs
+ and Spokes, respectively (at least one RT for Hub routes and at least
+ 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.
+
+
+
+
+Wen, et al. Standards Track [Page 23]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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.
+
+5.2.3. Cloud Access
+
+ This model provides cloud access configuration through the
+ cloud-access container. The usage of cloud-access is targeted for
+ public cloud access and Internet access. The cloud-access container
+ provides parameters for authorization rules. Note that this model
+ considers that public cloud and public Internet access share some
+ commonality; therefore, it does not distinguish Internet access from
+ cloud access. If needed, a different label for Internet access could
+ be added by augmentation.
+
+ Private cloud access may be addressed through the site container as
+ described in Section 5.3, with usage consistent with sites of
+ type "NNI".
+
+ A cloud identifier is used to reference the target service. This
+ identifier is local to each administration.
+
+ By default, all sites in the L2VPN SHOULD be permitted to access the
+ cloud or the Internet. If restrictions are required, a user MAY
+ configure some limitations for some sites or nodes by using policies,
+ i.e., 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 24]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ L2VPN
+ ++++++++++++++++++++++++++++++++ ++++++++++++
+ + Site 3 + --- + Cloud 1 +
+ + Site 1 + ++++++++++++
+ + +
+ + Site 2 + --- ++++++++++++
+ + + + Internet +
+ + Site 4 + ++++++++++++
+ ++++++++++++++++++++++++++++++++
+ |
+ +++++++++++
+ + Cloud 2 +
+ +++++++++++
+
+ Figure 8: Example of Cloud Access Configuration
+
+ As shown in Figure 8, we configure the global VPN to access the
+ Internet by creating a cloud-access container pointing to the cloud
+ identifier for the Internet service. (This is illustrated in the XML
+ [W3C.REC-xml-20081126] below.) No authorized sites will be
+ configured, as all sites are required to be able to access the
+ Internet.
+
+ <?xml version="1.0"?>
+ <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
+ <vpn-services>
+ <vpn-service>
+ <vpn-id>123456487</vpn-id>
+ <cloud-accesses>
+ <cloud-access>
+ <cloud-identifier>INTERNET</cloud-identifier>
+ </cloud-access>
+ </cloud-accesses>
+ <ce-vlan-preservation>true</ce-vlan-preservation>
+ <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
+ </vpn-service>
+ </vpn-services>
+ </l2vpn-svc>
+
+ If Site 1 and Site 2 require access to Cloud 1, a new cloud-access
+ container 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.
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 25]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ <?xml version="1.0"?>
+ <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
+ <vpn-services>
+ <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>
+ <ce-vlan-preservation>true</ce-vlan-preservation>
+ <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
+ </vpn-service>
+ </vpn-services>
+ </l2vpn-svc>
+
+ If all sites except Site 1 require access to Cloud 2, a new
+ cloud-access container 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.
+
+ <?xml version="1.0"?>
+ <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
+ <vpn-services>
+ <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>
+ <ce-vlan-preservation>true</ce-vlan-preservation>
+ <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
+ </vpn-service>
+ </vpn-services>
+ </l2vpn-svc>
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 26]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5.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)
+
+ Figure 9: Example of Shared VPN Resources
+
+ As illustrated in Figure 9, VPN B has some resources on Site B that
+ need to be made available to some customers/partners. Specifically,
+ 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 5.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 is used on customer
+ VPNs accessing extranet resources in another VPN. In Figure 9, 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 5.4.
+
+ 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.
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 27]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ <?xml version="1.0"?>
+ <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
+ <vpn-services>
+ <vpn-service>
+ <vpn-id>VPNB</vpn-id>
+ <svc-topo>hub-spoke</svc-topo>
+ <ce-vlan-preservation>true</ce-vlan-preservation>
+ <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
+ </vpn-service>
+ <vpn-service>
+ <vpn-id>VPNA</vpn-id>
+ <svc-topo>any-to-any</svc-topo>
+ <extranet-vpns>
+ <extranet-vpn>
+ <vpn-id>VPNB</vpn-id>
+ <local-sites-role>spoke-role</local-sites-role>
+ </extranet-vpn>
+ </extranet-vpns>
+ <ce-vlan-preservation>true</ce-vlan-preservation>
+ <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
+ </vpn-service>
+ </vpn-services>
+ </l2vpn-svc>
+
+ This model does not define how the extranet configuration will be
+ achieved within the network.
+
+ 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 5.5.2 and, in particular, a VPN policy as defined in
+ Section 5.5.2.2.
+
+5.2.5. Frame Delivery Service
+
+ If a BUM (Broadcast, Unknown Unicast, or Multicast) frame delivery
+ service is supported for an L2VPN, some global frame delivery
+ parameters are required as input for the service request. When a CE
+ sends BUM packets, replication occurs at the ingress PE and three
+ frame types need to be supported.
+
+ Users of this model will need to provide the flavors of trees that
+ will be used by customers within the L2VPN (customer-tree-flavors).
+ The model defined in this document supports bidirectional, shared,
+ and source-based trees (and can be augmented to contain other tree
+ types). Multiple flavors of trees can be supported simultaneously.
+
+
+
+
+
+Wen, et al. Standards Track [Page 28]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ Operator network
+ ______________
+ / \
+ | |
+ | |
+ Recv -- Site 2 ------- PE2 |
+ | PE1 --- Site 1 --- Source 1
+ | | \
+ | | -- Source 2
+ | |
+ | |
+ Recv -- Site 3 ------- PE3 |
+ | |
+ | |
+ Recv -- Site 4 ------- PE4 |
+ / | |
+ Recv -- Site 5 ------- | |
+ | |
+ | |
+ \______________/
+
+ Figure 10: BUM Frame Delivery Service Example
+
+ Multicast-group-to-port mappings can be created using the
+ "rp-group-mappings" leaf. Two group-to-port mapping methods are
+ supported:
+
+ o Static configuration of multicast Ethernet addresses and
+ ports/interfaces.
+
+ o A multicast control protocol based on Layer 2 technology that
+ signals mappings of multicast addresses to ports/interfaces, such
+ as the Generic Attribute Registration Protocol (GARP) / GARP
+ Multicast Registration Protocol (GARP/GMRP) [IEEE-802-1D].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 29]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+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.
+
+
+
+Wen, et al. Standards Track [Page 30]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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.
+
+
+
+Wen, et al. Standards Track [Page 31]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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).
+
+
+
+
+Wen, et al. Standards Track [Page 32]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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.
+
+
+
+
+Wen, et al. Standards Track [Page 33]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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.
+
+
+
+
+
+Wen, et al. Standards Track [Page 34]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 35]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+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.
+
+
+
+
+Wen, et al. Standards Track [Page 36]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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.
+
+
+
+Wen, et al. Standards Track [Page 37]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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.
+
+
+
+Wen, et al. Standards Track [Page 38]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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
+
+
+
+Wen, et al. Standards Track [Page 39]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 40]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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>
+
+
+
+Wen, et al. Standards Track [Page 41]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ <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>
+
+
+
+Wen, et al. Standards Track [Page 42]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ <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.
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 43]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ +---------------------------------------------------------------+
+ | 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>
+
+
+
+Wen, et al. Standards Track [Page 44]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ <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>
+
+
+
+Wen, et al. Standards Track [Page 45]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ <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>
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 46]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 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>
+
+
+
+Wen, et al. Standards Track [Page 47]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ <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>
+
+5.6. Deciding Where to Connect the Site
+
+ The management system will have to determine where to connect each
+ site-network-access of a particular site to the provider network
+ (e.g., PE or aggregation switch).
+
+
+
+
+
+Wen, et al. Standards Track [Page 48]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ This model defines parameters and constraints that can influence the
+ meshing of the site-network-access.
+
+ The management system MUST honor all customer constraints, or, if a
+ constraint is too strict and cannot be fulfilled, the management
+ system MUST NOT provision the site and MUST provide the user with
+ information regarding any constraints that could not be fulfilled.
+ How this information is provided is out of scope for this document.
+ Whether or not to relax the constraint would then be left up to
+ the user.
+
+ Parameters such as site location (see Section 5.6.2) and access type
+ (see Section 5.6.3) affect the service placement that the management
+ system applies.
+
+ In addition to parameters and constraints, the management system's
+ decision MAY be based on any other internal constraints that are left
+ up to the SP, e.g., least load, distance.
+
+5.6.1. Constraint: Device
+
+ In the case of provider management or co-management, one or more
+ devices have been ordered by the customer to a particular location
+ that has already been configured. The customer may force a
+ particular site-network-access to be connected on a particular device
+ that it ordered.
+
+ New York Site
+ +------------------+ Site
+ | +--------------+ |-------------------------------------
+ | | Manhattan | |
+ | | CE1********* (site-network-access#1) ******
+ | +--------------+ |
+ | +--------------+ |
+ | | Brooklyn | |
+ | | CE2********* (site-network-access#2) ******
+ | +--------------+ |
+ | |-------------------------------------
+ +------------------+
+
+ Figure 18: Example of a Constraint Applied to a Device
+
+ In Figure 18, site-network-access#1 is associated with CE1 in the
+ service request. The SP must ensure the provisioning of this
+ connection.
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 49]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5.6.2. Constraint/Parameter: Site Location
+
+ The location information provided in this model MAY be used by a
+ management system to determine the target PE to mesh the site (SP
+ side). A particular location must be associated with each site
+ network access when configuring it. The SP MUST honor the
+ termination of the access on the location associated with the site
+ network access (customer side). The "country-code" in the site
+ location should be expressed as an ISO 3166 code and is similar to
+ the "country" label defined in [RFC4119].
+
+ The site-network-access location is determined by the
+ "location-flavor". In the case of a provider-managed or co-managed
+ site, the user is expected to configure a "device-reference" (device
+ case) that will bind the site-network-access to a particular device
+ that the customer ordered. As each device is already associated with
+ a particular location, in such a case the location information is
+ retrieved from the device location. In the case of a
+ customer-managed site, the user is expected to configure a
+ "location-reference" (location case); this provides a reference to an
+ existing configured location and will help with placement.
+
+ POP#1 (New York)
+ +---------+
+ | PE1 |
+ Site 1 ---... | PE2 |
+ (Atlantic City) | PE3 |
+ +---------+
+
+ POP#2 (Washington)
+ +---------+
+ | PE4 |
+ | PE5 |
+ | PE6 |
+ +---------+
+
+ POP#3 (Philadelphia)
+ +---------+
+ | PE7 |
+ Site 2 CE#1---... | PE8 |
+ (Reston) | PE9 |
+ +---------+
+
+ Figure 19: Location Information for Sites
+
+ In Figure 19, Site 1 is a customer-managed site with a location "L1",
+ while Site 2 is a provider-managed site for which a CE (CE#1) was
+ ordered. Site 2 is configured with "L2" as its location. When
+
+
+
+Wen, et al. Standards Track [Page 50]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ configuring a site-network-access for Site 1, the user will need to
+ reference location L1 so that the management system will know that
+ the access will need to terminate on this location. Then, for
+ distance reasons, this management system may mesh Site 1 on a PE in
+ the Philadelphia POP. It may also take into account resources
+ available on PEs to determine the exact target PE (e.g., least
+ loaded). For Site 2, the user is expected to configure the
+ site-network-access with a device-reference to CE#1 so that the
+ management system will know that the access must terminate on the
+ location of CE#1 and must be connected to CE#1. For placement of the
+ SP side of the access connection, in the case of the nearest PE used,
+ it may mesh Site 2 on the Washington POP.
+
+5.6.3. Constraint/Parameter: Access Type
+
+ The management system needs to elect the access media to connect the
+ site to the customer (for example, xDSL, leased line, Ethernet
+ backhaul). The customer may provide some parameters/constraints that
+ will provide hints to the management system.
+
+ The bearer container information SHOULD be the first piece of
+ information considered when making this decision:
+
+ o The "requested-type" parameter provides information about the
+ media type that the customer would like to use. If the "strict"
+ leaf is equal to "true", this MUST be considered a strict
+ constraint so that the management system cannot connect the site
+ with another media type. If the "strict" leaf is equal to "false"
+ (default) and if the requested media type cannot be fulfilled, the
+ management system can select another media type. The supported
+ media types SHOULD be communicated by the SP to the customer via a
+ mechanism that is out of scope for this document.
+
+ o The "always-on" leaf defines a strict constraint: if set to
+ "true", the management system MUST elect a media type that is
+ "always-on" (e.g., this means no dial-in access type).
+
+ o The "bearer-reference" parameter is used in cases where the
+ customer has already ordered a network connection to the SP apart
+ from the L2VPN site and wants to reuse this connection. The
+ string used is an internal reference from the SP and describes the
+ already-available connection. This is also a strict requirement
+ that cannot be relaxed. How the reference is given to the
+ customer is out of scope for this document, but as an example,
+ when the customer ordered the bearer (through a process that is
+ out of scope for this model), the SP may have provided the bearer
+ reference that can be used for provisioning services on top.
+
+
+
+
+Wen, et al. Standards Track [Page 51]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ Any other internal parameters from the SP can also be used. The
+ management system MAY use other parameters, such as the requested
+ "input svc-bandwidth" and "output svc-bandwidth", to help decide
+ which access type to use.
+
+5.6.4. Constraint: Access Diversity
+
+ Each site-network-access may have one or more constraints that would
+ drive the placement of the access. By default, the model assumes
+ that there are no constraints, but allocation of a unique bearer per
+ site-network-access is expected.
+
+ In order to help with the different placement scenarios, a
+ site-network-access may be tagged using one or multiple group
+ identifiers. The group identifier is a string, so it can accommodate
+ both explicit naming of a group of sites (e.g., "multihomed-set1")
+ and the use of a numbered identifier (e.g., 12345678). The meaning
+ of each group-id is local to each customer administrator, and the
+ management system MUST ensure that different customers can use the
+ same group-ids. One or more group-ids can also be defined at the
+ site level; as a consequence, all site-network-accesses under the
+ site MUST inherit the group-ids of the site to which they belong.
+ When, in addition to the site group-ids some group-ids are defined at
+ the site-network-access level, the management system MUST consider
+ the union of all groups (site level and site-network-access level)
+ for this particular site-network-access.
+
+ For an already-configured site-network-access, each constraint MUST
+ be expressed against a targeted set of site-network-accesses. This
+ site-network-access (i.e., the already-configured
+ site-network-access) MUST never be taken into account in the targeted
+ set of site-network-accesses -- for example, "My site-network-access
+ S must not be connected on the same POP as the site-network-accesses
+ that are part of Group 10." The set of site-network-accesses against
+ which the constraint is evaluated can be expressed as a list of
+ groups, "all-other-accesses", or "all-other-groups". The
+ all-other-accesses option means that the current site-network-access
+ constraint MUST be evaluated against all the other
+ site-network-accesses belonging to the current site. The
+ all-other-groups option means that the constraint MUST be evaluated
+ against all groups to which the current site-network-access does not
+ belong.
+
+ The current model defines multiple constraint-types:
+
+ o pe-diverse: The current site-network-access MUST NOT be connected
+ to the same PE as the targeted site-network-accesses.
+
+
+
+
+Wen, et al. Standards Track [Page 52]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ o pop-diverse: The current site-network-access MUST NOT be connected
+ to the same POP as the targeted site-network-accesses.
+
+ o linecard-diverse: The current site-network-access MUST NOT be
+ connected to the same linecard as the targeted site-network-
+ accesses. Note that the customer can request linecard-diverse for
+ site-network-accesses, but the specific linecard identifier used
+ should not be exposed to the customer.
+
+ o bearer-diverse: The current site-network-access MUST NOT use
+ common bearer components compared to bearers used by the targeted
+ site-network-accesses. "bearer-diverse" provides some level of
+ diversity at the access level. As an example, two bearer-diverse
+ site-network-accesses must not use the same Digital Subscriber
+ Line Access Multiplexer (DSLAM), Broadband Access Switch (BAS), or
+ Layer 2 switch.
+
+ o same-pe: The current site-network-access MUST be connected to the
+ same PE as the targeted site-network-accesses.
+
+ o same-bearer: The current site-network-access MUST be connected
+ using the same bearer as the targeted site-network-accesses.
+
+ These constraint-types can be extended through augmentation. Each
+ constraint is expressed as "The site-network-access S must be
+ <constraint-type> (e.g., pe-diverse, pop-diverse) from these <target>
+ site-network-accesses."
+
+ The group-id used to target some site-network-accesses may be the
+ same as the one used by the current site-network-access. This eases
+ the configuration of scenarios where a group of site-network-access
+ points has a constraint between the access points in the group.
+
+5.7. Route Distinguisher and Network Instance Allocation
+
+ The Route Distinguisher (RD) is a critical parameter of BGP-based
+ L2VPNs as described in [RFC4364] that provides the ability to
+ distinguish common addressing plans in different VPNs. As for Route
+ Targets (RTs), a management system is expected to allocate a MAC-VRF
+ on the target PE and an RD for that MAC-VRF; that RD MUST be unique
+ across all MAC-VRFs on the target PE.
+
+ If a MAC-VRF already exists on the target PE and the MAC-VRF fulfills
+ the connectivity constraints for the site, there is no need to
+ recreate another MAC-VRF, and the site MAY be meshed within the
+ existing MAC-VRF. How the management system checks to see if an
+ existing MAC-VRF fulfills the connectivity constraints for a site is
+ out of scope for this document.
+
+
+
+Wen, et al. Standards Track [Page 53]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ If no such MAC-VRF exists on the target PE, the management system has
+ to initiate the creation of a new MAC-VRF on the target PE and has to
+ allocate a new RD for the new MAC-VRF.
+
+ The management system MAY apply a per-VPN or per-MAC-VRF allocation
+ policy for the RD, depending on the SP's policy. In a per-VPN
+ allocation policy, all MAC-VRFs (dispatched on multiple PEs) within a
+ VPN will share the same RD value. In a per-MAC-VRF model, all
+ MAC-VRFs should always have a unique RD value. Some other allocation
+ policies are also possible, and this document does not restrict the
+ allocation policies to be used.
+
+ The allocation of RDs MAY be done in the same way as RTs. The
+ information provided in Section 5.2.2.1 could also be used in this
+ scenario.
+
+ Note that an SP MAY configure a target PE for an automated allocation
+ of RDs. In this case, there will be no need for any backend system
+ to allocate an RD value.
+
+5.8. Site-Network-Access Availability
+
+ A site may be multihomed, meaning that it has multiple
+ site-network-access points. The placement constraints defined in
+ Section 5.6 will help ensure physical diversity.
+
+ When the site-network-accesses are placed on the network, a customer
+ may want to use a particular routing policy on those accesses. The
+ "site-network-access/availability" container defines parameters for
+ site redundancy. The "access-priority" leaf defines a preference for
+ a particular access. This preference is used to model load-balancing
+ or primary/backup scenarios. The higher the access-priority value,
+ the higher the preference will be. The "redundancy-mode" attribute
+ is defined for a multihoming site and used to model single-active and
+ active/active scenarios. It allows for multiple active paths in
+ forwarding state and for load-balancing options.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 54]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ Figure 20 illustrates how the access-priority attribute can be used.
+
+ Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing)
+ | |
+ | access-priority 1 access-priority 1 |
+ |--- CE1 ------- PE1 PE3 --------- CE3 --- |
+ | |
+ | |
+ |--- CE2 ------- PE2 PE4 --------- CE4 --- |
+ | access-priority 2 access-priority 1 |
+
+ PE5
+ |
+ |
+ |
+ CE5
+ |
+ Spoke#1 site (Single-homed)
+
+ Figure 20: Example: Configuring Access Priority
+
+ In Figure 20, Hub#2 requires load-sharing, so all the site-network-
+ accesses must use the same access-priority value. On the other hand,
+ as Hub#1 requires a primary site-network-access and a backup
+ site-network-access, a higher access-priority setting will be
+ configured on the primary site-network-access.
+
+ Scenarios that are more complex can also be modeled. Let's consider
+ a Hub site with five accesses to the network (A1, A2, A3, A4, and
+ A5). The customer wants to load-share its traffic on A1 and A2 in
+ the nominal situation. If A1 and A2 fail, the customer wants to
+ load-share its traffic on A3 and A4; finally, if A1, A2, A3, and A4
+ are all down, the customer wants to use A5. We can model this easily
+ by configuring the following access-priority values: A1=100, A2=100,
+ A3=50, A4=50, A5=10.
+
+ The access-priority scenario has some limitations. An
+ access-priority scenario like the previous one with five accesses but
+ with the constraint of having traffic load-shared between A3 and A4
+ in the case where only A1 or A2 (not both) is down is not achievable.
+ But the access-priority attribute defined will cover most of the
+ deployment use cases, and if necessary the model can be extended via
+ augmentation to support additional use cases.
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 55]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5.9. SVC MTU
+
+ The MTU of subscriber service frames can be derived from the physical
+ interface MTU by default, or it can be specified under the "svc-mtu"
+ leaf if it is different than the default number.
+
+5.10. Service
+
+ The service container defines service parameters associated with
+ the site.
+
+5.10.1. Bandwidth
+
+ The service bandwidth refers to the bandwidth requirement between the
+ CE and the PE and can be represented using the Committed Information
+ Rate (CIR), the Excess Information Rate (EIR), or the Peak
+ Information Rate (PIR). The requested bandwidth is expressed as
+ ingress bandwidth and egress bandwidth. The ingress or egress
+ direction uses the customer site as the point of reference:
+ "ingress-direction bandwidth" refers to download bandwidth for the
+ site, and "egress-direction bandwidth" refers to upload bandwidth for
+ the site.
+
+ The service bandwidth is only configurable at the site-network-access
+ level (i.e., for the site network access associated with the site).
+
+ Using a different ingress and egress bandwidth will allow an SP to
+ know if a customer allows for asymmetric bandwidth access like ADSL.
+ It can also be used to set the rate limit in a different way for
+ uploads and downloads on symmetric bandwidth access.
+
+ The svc-bandwidth parameter has a specific type. This document
+ defines four types:
+
+ o bw-per-access: bandwidth is per connection or site network access,
+ providing rate enforcement for all service frames at the interface
+ that are associated with a particular network access.
+
+ o bw-per-cos: bandwidth is per CoS, providing rate enforcement for
+ all service frames for a given CoS with a specific cos-id.
+
+ o bw-per-svc: bandwidth is per site, providing rate enforcement for
+ all service frames that are associated with a particular VPN
+ service.
+
+ o opaque bandwidth is the total bandwidth that is not associated
+ with any particular cos-id, VPN service identified with the
+ vpn-id, or site network access ID.
+
+
+
+Wen, et al. Standards Track [Page 56]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ The svc-bandwidth parameter must include a "cos-id" parameter if the
+ "type" is set to "bw-per-cos". The cos-id can be assigned based on
+ either (1) the IEEE 802.1p value [IEEE-802-1D] in the C-tag or
+ (2) the Differentiated Services Code Point (DSCP) in the Ethernet
+ frame header. Service frames are metered against the bandwidth
+ profile based on the cos-id.
+
+ The svc-bandwidth parameter must be associated with a specific
+ "site-network-access-id" parameter if the "type" is set to
+ "bw-per-access". Multiple bandwidths per cos-id can be associated
+ with the same site network access.
+
+ The svc-bandwidth parameter must include a specific "vpn-id"
+ parameter if the "type" is set to "bw-per-svc". Multiple bandwidths
+ per cos-id can be associated with the same EVPN service.
+
+5.10.2. QoS
+
+ The model defines QoS parameters as an abstraction:
+
+ o qos-classification-policy: Defines a set of ordered rules to
+ classify customer traffic.
+
+ o qos-profile: Provides a QoS scheduling profile to be applied.
+
+5.10.2.1. QoS Classification
+
+ QoS classification rules are handled by "qos-classification-policy".
+ qos-classification-policy is an ordered list of rules that match a
+ flow or application and set the appropriate target CoS
+ (target-class-id). The user can define the match using a
+ more specific flow definition (based on Layer 2 source and
+ destination MAC addresses, cos, dscp, cos-id, color-id, etc.). A
+ "color-id" will be assigned to a service frame to identify its QoS
+ profile conformance. A service frame is "green" if it is conformant
+ with the "committed" rate of the bandwidth profile. A service frame
+ is "yellow" if it exceeds the "committed" rate but is conformant with
+ the "excess" rate of the bandwidth profile. Finally, a service frame
+ is "red" if it is conformant with neither the "committed" rate nor
+ the "excess" rate of the bandwidth profile.
+
+ When a flow definition is used, the user can use a target-sites
+ leaf-list to identify the destination of a flow rather than using
+ destination addresses. In such a case, an association between the
+ site abstraction and the MAC addresses used by this site must be done
+ dynamically. How this association is done is out of scope for this
+ document. The association of a site to an L2VPN is done through the
+ vpn-attachment container. Therefore, the user can also employ the
+
+
+
+Wen, et al. Standards Track [Page 57]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "target-sites" leaf-list and "vpn-attachment" to identify the
+ destination of a flow targeted to a specific VPN service. A rule
+ that does not have a "match" statement is considered a "match-all"
+ rule. An SP may implement a default terminal classification rule if
+ the customer does not provide it. It will be up to the SP to
+ determine its default target class. This model defines some
+ applications, but new application identities may be added through
+ augmentation. The exact meaning of each application identity is up
+ to the SP, so it will be necessary for the SP to advise the customer
+ on the usage of application-matching.
+
+5.10.2.2. QoS Profile
+
+ A user can choose between the standard profile provided by the
+ operator or a custom profile. The QoS profile ("qos-profile")
+ defines the traffic-scheduling policy to be used by the SP.
+
+ A custom QoS profile is defined as a list of CoS entries and
+ associated properties. The properties are as follows:
+
+ o direction: Used to specify the direction to which the qos-profile
+ setting is applied. This model supports the site-to-WAN direction
+ ("site-to-wan"), the WAN-to-site direction ("wan-to-site"), and
+ both directions ("bidirectional"). By default, "bidirectional" is
+ used. In the case of both directions, the provider should ensure
+ scheduling according to the requested policy in both traffic
+ directions (SP to customer and customer to SP). As an example, a
+ device-scheduling policy may be implemented on both the PE side
+ and the CE side of the WAN link. In the case of the WAN-to-site
+ direction, the provider should ensure scheduling from the SP
+ network to the customer site. As an example, a device-scheduling
+ policy may be implemented only on the PE side of the WAN link
+ towards the customer.
+
+ o policing: Optional. Indicates whether policing should apply to
+ one-rate, two-color or to two-rate, three-color.
+
+ o byte-offset: Optional. Indicates how many bytes in the service
+ frame header are excluded from rate enforcement.
+
+ o frame-delay: Used to define the latency constraint of the class.
+ The latency constraint can be expressed as the lowest possible
+ latency or as a latency boundary expressed in milliseconds. How
+ this latency constraint will be fulfilled is up to the SP
+ implementation: a strict priority-queuing mechanism may be used on
+ the access and in the core network, or a low-latency routing path
+ may be created for this traffic class.
+
+
+
+
+Wen, et al. Standards Track [Page 58]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ o frame-jitter: Used to define the jitter constraint of the class.
+ The jitter constraint can be expressed as the lowest possible
+ jitter or as a jitter boundary expressed in microseconds. How
+ this jitter constraint will be fulfilled is up to the SP
+ implementation: a strict priority-queuing mechanism may be used on
+ the access and in the core network, or a jitter-aware routing path
+ may be created for this traffic class.
+
+ o bandwidth: Used to define a guaranteed amount of bandwidth for
+ the CoS. It is expressed as a percentage. The
+ "guaranteed-bw-percent" parameter uses available bandwidth as a
+ reference. The available bandwidth should not fall below the CIR
+ value defined under the input svc-bandwidth or the output
+ svc-bandwidth. When the "qos-profile" container is implemented on
+ the CE side, the output svc-bandwidth is taken into account as a
+ reference. When it is implemented on the PE side, the input
+ svc-bandwidth is used. By default, the bandwidth reservation is
+ only guaranteed at the access level. The user can use the
+ "end-to-end" leaf to request an end-to-end bandwidth reservation,
+ including across the MPLS transport network. (In other words, the
+ SP will activate something in the MPLS core to ensure that the
+ bandwidth request from the customer will be fulfilled by the MPLS
+ core as well.) How this is done (e.g., RSVP-TE reservation,
+ controller reservation) is out of scope for this document.
+
+ In addition, due to network conditions, some constraints may not be
+ completely fulfilled by the SP; in this case, the SP should advise
+ the customer about the limitations. How this communication is done
+ is out of scope for this document.
+
+5.10.3. Support for BUM
+
+ The "broadcast-unknown-unicast-multicast" container defines the type
+ of site in the customer multicast service topology: source, receiver,
+ or both. These parameters will help the management system optimize
+ the multicast service.
+
+ Multiple multicast group-to-port mappings can be created using the
+ "multicast-gp-address-mapping" list. The
+ "multicast-gp-address-mapping" list defines the multicast group
+ address and port LAG number. Those parameters will help the SP
+ select the appropriate association between an interface and a
+ multicast group to fulfill the customer service requirement.
+
+ To ensure that a given frame is transparently transported, a whole
+ Layer 2 multicast frame (whether for data or control) should not be
+ altered from a CE to other CEs, except for the VLAN ID field. VLAN
+ IDs assigned by the SP can also be altered.
+
+
+
+Wen, et al. Standards Track [Page 59]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ For point-to-point services, the provider only needs to deliver a
+ single copy of each service frame to the remote PE, regardless of
+ whether the destination MAC address of the incoming frame is unicast,
+ multicast, or broadcast. Therefore, all service frames should be
+ delivered unconditionally.
+
+ BUM frame forwarding in multipoint-to-multipoint services, on the
+ other hand, involves both local flooding to other ACs on the same PE
+ and remote replication to all other PEs, thus consuming additional
+ resources and core bandwidth. Special BUM frame disposition rules
+ can be implemented at external-facing interfaces (UNIs or External
+ NNIs (E-NNIs)) to rate-limit the BUM frames, in terms of the number
+ of packets per second or bits per second.
+
+ The threshold can apply to all BUM traffic, or one threshold can be
+ applied for each category of traffic.
+
+5.11. Site Management
+
+ The "management" sub-container is intended for site management
+ options, depending on device ownership and security access control.
+ Three common management models are as follows:
+
+ Provider-managed CE: The provider has sole ownership of the CE
+ device. Only the provider has access to the CE. The
+ responsibility boundary between the SP and the customer is between
+ the CE and the customer network. This is the most common
+ use case.
+
+ Customer-managed CE: The customer has sole ownership of the CE
+ device. Only the customer has access to the CE. In this model,
+ the responsibility boundary between the SP and the customer is
+ between the PE and the CE.
+
+ Co-managed CE: The provider has ownership of the CE device and is
+ responsible for managing the CE. However, the provider grants the
+ customer access to the CE for some configuration/monitoring
+ purposes. In this co-managed mode, the responsibility boundary is
+ the same as for the provider-managed model.
+
+ The selected management mode is specified under the "type" leaf. The
+ "address" leaf stores CE device management addressing information.
+ The "management-transport" leaf is used to identify the transport
+ protocol for management traffic: IPv4 or IPv6. Additional security
+ options may be derived based on the particular management model
+ selected.
+
+
+
+
+
+Wen, et al. Standards Track [Page 60]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5.12. MAC Loop Protection
+
+ MAC address flapping between different physical ports typically
+ indicates a bridge loop condition in the customer network.
+ Misleading entries in the MAC cache table can cause service frames to
+ circulate around the network indefinitely and saturate the links
+ throughout the provider's network, affecting other services in the
+ same network. In the case of EVPNs, it also introduces massive BGP
+ updates and control-plane instability.
+
+ The SP may opt to implement a switching loop-prevention mechanism at
+ the external-facing interfaces for multipoint-to-multipoint services
+ by imposing a MAC address move threshold.
+
+ The MAC move rate and prevention-type options are listed in the
+ "mac-loop-prevention" container.
+
+5.13. MAC Address Limit
+
+ The optional "mac-addr-limit" container contains the customer MAC
+ address limit and information that describes the action taken when
+ the limit is exceeded and the aging time for a MAC address.
+
+ When multiple services are provided on the same network element, the
+ MAC address table (and the Routing Information Base space for
+ MAC routes in the case of EVPNs) is a shared common resource. SPs
+ may impose a maximum number of MAC addresses learned from the
+ customer for a single service instance by using the "mac-addr-limit"
+ leaf and may use the "action" leaf to specify the action taken when
+ the upper limit is exceeded: drop the packet, flood the packet, or
+ simply send a warning log message.
+
+ For point-to-point services, if MAC learning is disabled, then the
+ MAC address limit is not necessary.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 61]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5.14. Enhanced VPN Features
+
+5.14.1. Carriers' Carriers
+
+ In the case of Carriers' Carriers (CsC) [RFC8299], a customer may
+ want to build an MPLS service using an L2VPN to carry its traffic.
+
+ LAN customer1
+ |
+ |
+ CE1
+ |
+ | -------------
+ (vrf_cust1)
+ CE1_ISP1
+ | ISP1 POP
+ | MPLS link
+ | -------------
+ |
+ (vrf ISP1)
+ PE1
+
+ (...) Provider backbone
+
+ PE2
+ (vrf ISP1)
+ |
+ | ------------
+ |
+ | MPLS link
+ | ISP1 POP
+ CE2_ISP1
+ (vrf_cust1)
+ | ------------
+ |
+ CE2
+ |
+ LAN customer1
+
+ Figure 21: MPLS Service Using an L2VPN to Carry Traffic
+
+ In Figure 21, ISP1 resells an L2VPN service but has no core network
+ infrastructure between its POPs. ISP1 uses an L2VPN as the core
+ network infrastructure (belonging to another provider) between
+ its POPs.
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 62]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ In order to support CsC, the VPN service must indicate MPLS support
+ by setting the "carrierscarrier" leaf to "true" in the vpn-service
+ list. The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run
+ an MPLS signaling protocol. This configuration is done at the site
+ level.
+
+ In this model, LDP or BGP can be used as the MPLS signaling protocol.
+ In the case of LDP, an IGP routing protocol MUST also be activated.
+ In the case of BGP signaling, BGP MUST also be configured as the
+ routing protocol.
+
+ If CsC is enabled, the requested "svc-mtu" leaf will refer to the
+ MPLS MTU and not to the link MTU.
+
+5.15. External ID References
+
+ The service model sometimes refers to external information through
+ identifiers. As an example, to order cloud access to a particular
+ Cloud Service Provider (CSP), the model uses an identifier to refer
+ to the targeted CSP. If a customer is directly using this service
+ model as an API (through RESTCONF or NETCONF, for example) to order a
+ particular service, the SP should provide a list of authorized
+ identifiers. In the case of cloud access, the SP will provide the
+ associated identifiers for each available CSP. The same applies to
+ other identifiers, such as qos-profile.
+
+ As a usage example, the remote-carrier-name setting is used in the
+ NNI case because it should be known by the current L2VPN SP to which
+ it is connecting, while the cloud-identifier setting should be known
+ by both the current L2VPN SP and the customer because it is applied
+ to the public cloud or Internet access.
+
+ How an SP provides the meanings of those identifiers to the customer
+ is out of scope for this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 63]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5.16. Defining NNIs and Inter-AS Support
+
+ An Autonomous System (AS) is a single network or group of networks
+ that are controlled by a common system administration group and that
+ use a single, clearly defined routing protocol. In some cases, VPNs
+ need to span different ASes in different geographical areas or span
+ different SPs. The connection between ASes is established by the SPs
+ and is seamless to the customer. Examples include:
+
+ o A partnership between SPs (e.g., carrier, cloud) to extend their
+ VPN services seamlessly.
+
+ o An internal administrative boundary within a single SP (e.g.,
+ backhaul versus core versus data center).
+
+ NNIs have to be defined to extend the VPNs across multiple ASes.
+ [RFC4761] defines multiple flavors of VPN NNI implementations (e.g.,
+ VPLSs). Each implementation has pros and cons; this topic is outside
+ the scope of this document. For example, in an inter-AS option A
+ (two ASes), AS Border Router (ASBR) peers are connected by multiple
+ interfaces with at least one of those interfaces spanning the two
+ ASes while being present in the same VPN. In order for these ASBRs
+ to signal label blocks, they associate each interface with a MAC-VRF
+ (VSI) (Section 2) and a BGP session. As a result, traffic between
+ devices in the back-to-back VPLS is Ethernet. In this scenario, the
+ VPNs are isolated from each other, and because the traffic is
+ Ethernet, QoS mechanisms that operate on Ethernet traffic can be
+ applied to achieve customer SLAs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 64]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ -------- -------------- -----------
+ / \ / \ / \
+ | Cloud | | | | |
+ | Provider |-----NNI-----| |----NNI---| Data Center |
+ | #1 | | | | |
+ \ / | | \ /
+ -------- | | -----------
+ | |
+ -------- | My network | -----------
+ / \ | | / \
+ | Cloud | | | | |
+ | Provider |-----NNI-----| |---NNI---| L2VPN |
+ | #2 | | | | Partner |
+ \ / | | | |
+ -------- | | | |
+ \ / | |
+ -------------- \ /
+ | -----------
+ |
+ NNI
+ |
+ |
+ -------------------
+ / \
+ | |
+ | |
+ | |
+ | L2VPN Partner |
+ | |
+ \ /
+ -------------------
+
+ Figure 22: SP Network with Several NNIs
+
+ Figure 22 illustrates an SP network called "My network" that has
+ several NNIs. This network uses NNIs to:
+
+ o increase its footprint by relying on L2VPN partners.
+
+ o connect its own data-center services to the customer L2VPN.
+
+ o enable the customer to access its private resources located in a
+ private cloud owned by some CSPs.
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 65]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5.16.1. Defining an NNI with the Option A Flavor
+
+ AS A AS 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 23: NNI Defined with the Option A Flavor: Example 1
+
+ In option A, the two ASes are connected to each other with physical
+ links on ASBRs. For resiliency purposes, there may be multiple
+ physical connections between the ASes. A VPN connection -- physical
+ or logical (on top of physical) -- is created for each VPN that needs
+ to cross the AS boundary, thus providing a back-to-back VPLS model.
+
+ From a service model's perspective, this VPN connection can be seen
+ as a site. Let's say that AS B wants to extend some VPN connections
+ for VPN C on AS A. The administrator of AS B can use this service
+ model to order a site on AS A. All connection scenarios could be
+ realized using the features of the current model. As an example,
+ Figure 23 shows two physical connections that have logical
+ connections per VPN overlaid on them. This could be seen as a
+ multi-VPN scenario. Also, the administrator of AS B will be able to
+
+
+
+Wen, et al. Standards Track [Page 66]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ choose the appropriate routing protocol (e.g., External BGP (EBGP))
+ to dynamically exchange routes between ASes.
+
+ This document assumes that the option A NNI flavor SHOULD reuse the
+ existing VPN site modeling.
+
+ Figure 24 illustrates an example where a customer wants its CSP A to
+ attach its virtual network N to an existing L2VPN (VPN1) that it has
+ from L2VPN SP B.
+
+ CSP A L2VPN SP B
+ ----------------- -----------
+ / \ / \
+ | | | | |
+ | VM --| ++++++++ NNI ++++++++++ |--- VPN1
+ | | + +____________+ + | Site 1
+ | |-------+(MAC-VRF1)-(VPN1)-(MAC-VRF1)+ |
+ | | + + + + |
+ | | + ASBR + + ASBR + |
+ | | + +____________+ + |
+ | | ++++++++ ++++++++++ |
+ | VM --| | | |--- VPN1
+ | |Virtual | | | Site 2
+ | |Network | | |
+ | VM --| | | |--- VPN1
+ | | | | | Site 3
+ \ / \ /
+ ----------------- -----------
+ |
+ |
+ VPN1
+ Site 4
+
+ VM = Virtual Machine
+
+ Figure 24: NNI Defined with the Option A Flavor: Example 2
+
+ To create the VPN connectivity, the CSP or the customer may use the
+ L2SM that SP B exposes. We could consider that, as the NNI is
+ shared, the physical connection (bearer) between CSP A and SP B
+ already exists. CSP A may request through a service model the
+ creation of a new site with a single site-network-access
+ (single-homing is used in Figure 24). As a placement constraint, CSP
+ A may use the existing bearer reference it has from SP A to force the
+ placement of the VPN NNI on the existing link. The XML below
+ illustrates a possible configuration request to SP B:
+
+
+
+
+
+Wen, et al. Standards Track [Page 67]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ <?xml version="1.0"?>
+ <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
+ <vpn-profiles>
+ <valid-provider-identifiers>
+ <qos-profile-identifier>
+ <id>GOLD</id>
+ </qos-profile-identifier>
+ <qos-profile-identifier>
+ <id>PLATINUM</id>
+ </qos-profile-identifier>
+ </valid-provider-identifiers>
+ </vpn-profiles>
+ <vpn-services>
+ <vpn-service>
+ <vpn-id>VPN1</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>CSP_A_attachment</site-id>
+ <locations>
+ <location>
+ <location-id>NY1</location-id>
+ <city>NY</city>
+ <country-code>US</country-code>
+ </location>
+ </locations>
+ <site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
+ <site-network-accesses>
+ <site-network-access>
+ <network-access-id>CSP_A_VN1</network-access-id>
+ <connection>
+ <encapsulation-type>vlan</encapsulation-type>
+ <eth-inf-type>tagged</eth-inf-type>
+ <tagged-interface>
+ <tagged-inf-type>dot1q</tagged-inf-type>
+ <dot1q-vlan-tagged>
+ <cvlan-id>17</cvlan-id>
+ </dot1q-vlan-tagged>
+ </tagged-interface>
+ </connection>
+ <service>
+ <svc-bandwidth>
+ <bandwidth>
+ <direction>input-bw</direction>
+ <type>bw-per-cos</type>
+
+
+
+Wen, et al. Standards Track [Page 68]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ <cir>450000000</cir>
+ <cbs>20000000</cbs>
+ <eir>1000000000</eir>
+ <ebs>200000000</ebs>
+ </bandwidth>
+ </svc-bandwidth>
+ <carrierscarrier>
+ <signaling-type>bgp</signaling-type>
+ </carrierscarrier>
+ </service>
+ <vpn-attachment>
+ <vpn-id>12456487</vpn-id>
+ <site-role>spoke-role</site-role>
+ </vpn-attachment>
+ </site-network-access>
+ </site-network-accesses>
+ <management>
+ <type>customer-managed</type>
+ </management>
+ </site>
+ </sites>
+ </l2vpn-svc>
+
+ The case described above is different from a scenario using the
+ cloud-accesses container, as the cloud-access provides a public cloud
+ access while this example enables access to private resources located
+ in a CSP network.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 69]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5.16.2. Defining an NNI with the Option B Flavor
+
+ AS A AS B
+ ------------------- -------------------
+ / \ / \
+ | | | |
+ | ++++++++ Inter-AS link ++++++++ |
+ | + +_______________+ + |
+ | + + + + |
+ | + ASBR +<---MP-BGP---->+ ASBR + |
+ | + + + + |
+ | + +_______________+ + |
+ | ++++++++ ++++++++ |
+ | | | |
+ | | | |
+ | | | |
+ | ++++++++ Inter-AS link ++++++++ |
+ | + +_______________+ + |
+ | + + + + |
+ | + ASBR +<---MP-BGP---->+ ASBR + |
+ | + + + + |
+ | + +_______________+ + |
+ | ++++++++ ++++++++ |
+ | | | |
+ | | | |
+ \ / \ /
+ ------------------- -------------------
+
+ Figure 25: NNI Defined with the Option B Flavor: Example 1
+
+ In option B, the two ASes are connected to each other with physical
+ links on ASBRs. For resiliency purposes, there may be multiple
+ physical connections between the ASes. The VPN "connection" between
+ ASes is done by exchanging VPN routes through MP-BGP [RFC4761].
+
+ There are multiple flavors of implementations of such an NNI. For
+ example:
+
+ 1. The NNI is internal to the provider and is situated between a
+ backbone and a data center. There is enough trust between the
+ domains to not filter the VPN routes. So, all the VPN routes are
+ exchanged. RT filtering may be implemented to save some
+ unnecessary route states.
+
+ 2. The NNI is used between providers that agreed to exchange VPN
+ routes for specific RTs only. Each provider is authorized to use
+ the RT values from the other provider.
+
+
+
+
+Wen, et al. Standards Track [Page 70]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ 3. The NNI is used between providers that agreed to exchange VPN
+ routes for specific RTs only. Each provider has its own RT
+ scheme. So, a customer spanning the two networks will have
+ different RTs in each network for a particular VPN.
+
+ Case 1 does not require any service modeling, as the protocol enables
+ the dynamic exchange of necessary VPN routes.
+
+ Case 2 requires that an RT-filtering policy on ASBRs be maintained.
+ From a service-modeling point of view, it is necessary to agree on
+ the list of RTs to authorize.
+
+ In Case 3, both ASes need to agree on the VPN RT to exchange, as well
+ as how to map a VPN RT from AS A to the corresponding RT in AS B (and
+ vice versa).
+
+ Those modelings are currently out of scope for this document.
+
+ CSP A L3VPN SP B
+ ----------------- ------------------
+ / \ / \
+ | | | | |
+ | VM --| ++++++++ NNI ++++++++ |--- VPN1
+ | | + +__________+ + | Site 1
+ | |-------+ + + + |
+ | | + ASBR +<-MP-BGP->+ ASBR + |
+ | | + +__________+ + |
+ | | ++++++++ ++++++++ |
+ | VM --| | | |--- VPN1
+ | |Virtual | | | Site 2
+ | |Network | | |
+ | VM --| | | |--- VPN1
+ | | | | | Site 3
+ \ / | |
+ ----------------- | |
+ \ /
+ ------------------
+ |
+ |
+ VPN1
+ Site 4
+
+ VM = Virtual Machine
+
+ Figure 26: NNI Defined with the Option B Flavor: Example 2
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 71]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ Figure 26 shows an NNI connection between CSP A and SP network B.
+ The SPs do not trust each other and use different RT allocation
+ policies. So, in terms of implementation, the customer VPN has a
+ different RT in each network (RT A in CSP A and RT B in SP
+ network B). In order to connect the customer's virtual network in
+ CSP A to the customer's L2VPN (VPN1) in SP network B, CSP A should
+ request that SP network B open the customer VPN on the NNI (accept
+ the appropriate RT). Who does the RT translation depends on the
+ agreement between the two SPs: SP B may permit CSP A to request VPN
+ (RT) translation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 72]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+5.16.3. Defining an NNI with the Option C Flavor
+
+ AS A AS B
+ ------------------- -------------------
+ / \ / \
+ | | | |
+ | | | |
+ | | | |
+ | ++++++++ Multihop EBGP ++++++++ |
+ | + + + + |
+ | + + + + |
+ | + RGW +<----MP-BGP---->+ RGW + |
+ | + + + + |
+ | + + + + |
+ | ++++++++ ++++++++ |
+ | | | |
+ | | | |
+ | | | |
+ | | | |
+ | | | |
+ | ++++++++ Inter-AS link ++++++++ |
+ | + +_______________+ + |
+ | + + + + |
+ | + ASBR + + ASBR + |
+ | + + + + |
+ | + +_______________+ + |
+ | ++++++++ ++++++++ |
+ | | | |
+ | | | |
+ | | | |
+ | ++++++++ Inter-AS link ++++++++ |
+ | + +_______________+ + |
+ | + + + + |
+ | + ASBR + + ASBR + |
+ | + + + + |
+ | + +_______________+ + |
+ | ++++++++ ++++++++ |
+ | | | |
+ | | | |
+ \ / \ /
+ ------------------- -------------------
+
+ Figure 27: NNI Defined with the Option C Flavor
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 73]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ From a VPN service's perspective, the option C NNI is very similar to
+ option B, as an MP-BGP session is used to exchange VPN routes between
+ the ASes. The difference is that the forwarding plane and the
+ control plane are on different nodes, so the MP-BGP session is
+ multihop between routing gateway (RGW) nodes. From a VPN service's
+ point of view, modeling options B and C will be configured
+ identically.
+
+5.17. Applicability of L2SM in Inter-provider and Inter-domain
+ Orchestration
+
+ In the case where the ASes belong to different providers, one might
+ imagine that providers would like to have fewer signaling sessions
+ crossing the AS boundary and that the entities that terminate the
+ sessions could be restricted to a smaller set of devices. Two
+ approaches can be taken:
+
+ a. Construct inter-provider control connections to run only between
+ the two border routers.
+
+ b. Allow end-to-end, multi-segment connectivity to be constructed
+ out of several connectivity segments, without maintaining an
+ end-to-end control connection.
+
+ Inter-provider control connections as described in approach (a) can
+ be realized using the techniques provided in Section 5.16 (e.g.,
+ defining NNIs). Multi-segment connectivity as described in
+ approach (b) can produce an inter-AS solution that more closely
+ resembles scheme (b) in Section 10 of [RFC4364]. It may be realized
+ using "stitching" of per-site connectivity and service segments at
+ different domains, e.g., end-to-end connectivity between Site 1 and
+ Site 3 spans multiple domains (e.g., metropolitan area networks) and
+ can be constructed by stitching network access connectivity within
+ Site 1 with SEG1, SEG3, and SEG4, and network access connectivity
+ within Site 3 (as shown in Figure 28). The assumption is that the
+ service orchestration component in Figure 3 should have visibility
+ into the complete abstract topology and resource availability. This
+ may rely on network planning.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 74]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ ---------- ---------- ----------
+ | | | | | |
+ +--+ +---+ +---+ +--+
+ Site 1|PE|==SEG1==| |==SEG3==| |==SEG4==|PE|Site 3
+ +--+ +---+ | | +--+
+ | | | | | | ----------
+ | | | | | | | |
+ +--+ +---+ | | +---+ +--+
+ Site 2|PE|==SEG2==| |==SEG5==| |==SEG6==| |==SEG7==|PE|Site 4
+ +--+ +---+ +---+ +---+ +--+
+ | | | | | | | |
+ ---------- ---------- ---------- ----------
+
+ Figure 28: Example: Inter-provider and Inter-domain Orchestration
+
+ Note that SEG1, SEG2, SEG3, SEG4, SEG5, and SEG6 can also be regarded
+ as network access connectivity within a site and can be created as a
+ normal site using the L2SM.
+
+ In Figure 28, we use BGP redistribution of L2VPN Network Layer
+ Reachability Information (NLRI) instances from AS to neighboring AS.
+ First, the PE routers use BGP to redistribute L2VPN NLRIs to either
+ an ASBR or a route reflector of which an ASBR is a client. The ASBR
+ then uses BGP to redistribute those L2VPN NLRIs to an ASBR in another
+ AS, which in turn distributes them to the PE routers in that AS, or
+ perhaps to another ASBR that in turn distributes them, and so on.
+
+ In this case, a PE can learn the address of an ASBR through which it
+ could reach another PE to which it wishes to establish connectivity.
+ That is, a local PE will receive a BGP advertisement containing an
+ L2VPN NLRI corresponding to an L2VPN instance in which the local PE
+ has some attached members. The BGP next hop for that L2VPN NLRI will
+ be an ASBR of the local AS. Then, rather than building a control
+ connection all the way to the remote PE, it builds one only to the
+ ASBR. A connectivity segment can now be established from the PE to
+ the ASBR. The ASBR in turn can establish connectivity to the ASBR of
+ the next AS and then stitch that connectivity to the connectivity
+ from the PE as described in [RFC6073]. Repeating the process at each
+ ASBR leads to a sequence of connectivity segments that, when stitched
+ together, connect the two PEs.
+
+ Note that in the approach just described, the local PE may never
+ learn the IP address of the remote PE. It learns the L2VPN NLRI
+ advertised by the remote PE, which need not contain the remote PE
+ address, and it learns the IP address of the ASBR that is the BGP
+ next hop for that NLRI.
+
+
+
+
+
+Wen, et al. Standards Track [Page 75]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ When this approach is used for VPLS or for full-mesh VPWS, it leads
+ to a full mesh of connectivity among the PEs, but it does not require
+ a full mesh of control connections (LDP or L2TPv3 sessions).
+ Instead, the control connections within a single AS run among all the
+ PEs of that AS and the ASBRs of the AS. A single control connection
+ between the ASBRs of adjacent ASes can be used to support as many
+ AS-to-AS connectivity segments as may be needed.
+
+6. Interaction with Other YANG Modules
+
+ As explained in Section 4, this service model is not intended to
+ configure network elements; rather, it is instantiated in a
+ management system.
+
+ The management system might follow modular design and comprise two
+ different components:
+
+ a. The component instantiating the service model (let's call it the
+ service component).
+
+ b. The component responsible for network element configuration
+ (let's call it the configuration component).
+
+ In some cases, when a split is needed between the behavior and
+ functions that a customer requests and the technology that the
+ network operator has available to deliver the service [RFC8309], a
+ new component can be separated out of the service component (let's
+ call it the control component). This component is responsible for
+ network-centric operation and is aware of many features such as
+ topology, technology, and operator policy. As an optional component,
+ it can use the service model as input and is not required at all if
+ the control component delegates its control operations to the
+ configuration component.
+
+ In Section 7, we provide an example of translation of service
+ provisioning requests to router configuration lines as an
+ illustration. In the YANG-based ecosystem, it is expected that
+ NETCONF and YANG will be used between the configuration component and
+ network elements to configure the requested service on those
+ elements.
+
+ In this framework, it is expected that YANG data models will be used
+ to configure service components on network elements. There will be a
+ strong relationship between the abstracted view provided by this
+ service model and the detailed configuration view that will be
+ provided by specific configuration models for network elements such
+
+
+
+
+
+Wen, et al. Standards Track [Page 76]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ as those defined in [MPLS-L2VPN-YANG] and [EVPN-YANG]. Service
+ components that would need configuration of network elements in
+ support of the service model defined in this document include:
+
+ o Network instance definitions that include defined VPN policies.
+
+ o Physical interfaces.
+
+ o Ethernet-layer parameters (e.g., VLAN IDs).
+
+ o QoS: classification, profiles, etc.
+
+ o Support for Ethernet Service OAM.
+
+7. Service Model Usage Example
+
+ As explained in Section 4, this service model is intended to be
+ instantiated at a management layer and is not intended to be used
+ directly on network elements. The management system serves as a
+ central point of configuration of the overall service.
+
+ This section provides an example of how a management system can use
+ this model to configure an L2VPN service on network elements.
+
+ This example provides a VPN service for three sites using
+ point-to-point VPWS and a Hub-and-Spoke VPN service topology as shown
+ in Figure 29. Load balancing is not considered in this case.
+
+ Site 1
+ ............
+ : : P2P VPWS
+ :Spoke Site:-----PE1--------------------------+
+ : : | Site 3
+ :..........: | ............
+ | : :
+ PE3-----: Hub Site :
+ Site 2 | : :
+ ............ | :..........:
+ : : P2P VPWS |
+ :Spoke Site:-----PE2--------------------------+
+ : :
+ :..........:
+
+ Figure 29: Reference Network for Simple Example
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 77]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ The following XML describes the overall simplified service
+ configuration of this VPN.
+
+ <?xml version="1.0"?>
+ <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
+ <vpn-services>
+ <vpn-service>
+ <vpn-id>12456487</vpn-id>
+ <vpn-svc-type>vpws</vpn-svc-type>
+ <svc-topo>hub-spoke</svc-topo>
+ <ce-vlan-preservation>true</ce-vlan-preservation>
+ <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
+ </vpn-service>
+ <vpn-service>
+ <vpn-id>12456488</vpn-id>
+ <vpn-svc-type>vpws</vpn-svc-type>
+ <svc-topo>hub-spoke</svc-topo>
+ <ce-vlan-preservation>true</ce-vlan-preservation>
+ <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
+ </vpn-service>
+ </vpn-services>
+ </l2vpn-svc>
+
+ When receiving the request for provisioning the VPN service, the
+ management system will internally (or through communication with
+ another OSS component) allocate VPN RTs. In this specific case, two
+ RTs will be allocated (100:1 for Hubs and 100:2 for Spokes). The
+ output below describes the configuration of Spoke Site 1.
+
+ <?xml version="1.0"?>
+ <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
+ <vpn-services>
+ <vpn-service>
+ <vpn-id>12456487</vpn-id>
+ <svc-topo>hub-spoke</svc-topo>
+ <ce-vlan-preservation>true</ce-vlan-preservation>
+ <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
+ </vpn-service>
+ </vpn-services>
+ <sites>
+ <site>
+ <site-id>Spoke_Site1</site-id>
+ <locations>
+ <location>
+ <location-id>NY1</location-id>
+ <city>NY</city>
+ <country-code>US</country-code>
+ </location>
+
+
+
+Wen, et al. Standards Track [Page 78]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ </locations>
+ <site-network-accesses>
+ <site-network-access>
+ <network-access-id>Spoke_UNI-Site1</network-access-id>
+ <access-diversity>
+ <groups>
+ <group>
+ <group-id>20</group-id>
+ </group>
+ </groups>
+ </access-diversity>
+ <connection>
+ <encapsulation-type>vlan</encapsulation-type>
+ <tagged-interface>
+ <dot1q-vlan-tagged>
+ <cvlan-id>17</cvlan-id>
+ </dot1q-vlan-tagged>
+ </tagged-interface>
+ <l2cp-control>
+ <stp-rstp-mstp>tunnel</stp-rstp-mstp>
+ <lldp>true</lldp>
+ </l2cp-control>
+ </connection>
+ <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>
+ </service>
+ <vpn-attachment>
+ <vpn-id>12456487</vpn-id>
+ <site-role>spoke-role</site-role>
+ </vpn-attachment>
+ </site-network-access>
+ </site-network-accesses>
+ <management>
+ <type>provider-managed</type>
+ </management>
+ </site>
+
+
+
+Wen, et al. Standards Track [Page 79]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ </sites>
+ </l2vpn-svc>
+
+ When receiving the request for provisioning Spoke Site 1, the
+ management system MUST allocate network resources for this site. It
+ MUST first determine the target network elements to provision the
+ access and, in particular, the PE router (or possibly an aggregation
+ switch). As described in Sections 5.3.1 and 5.6, the management
+ system SHOULD use the location information and MUST use the
+ access-diversity constraint to find the appropriate PE. In this
+ case, we consider that Spoke Site 1 requires PE diversity with Hubs
+ and that the management system will allocate PEs based on least
+ distance. Based on the location information, the management system
+ finds the available PEs in the area closest to the customer and picks
+ one that fits the access-diversity constraint.
+
+ When the PE is chosen, the management system needs to allocate
+ interface resources on the node. One interface is selected from the
+ PE's available pool of resources. The management system can start
+ provisioning the PE node using any means it wishes (e.g., NETCONF,
+ CLI). The management system will check to see if a VSI that fits its
+ needs is already present. If not, it will provision the VSI: the RD
+ will come from the internal allocation policy model, and the RTs will
+ come from the vpn-policy configuration of the site (i.e., the
+ management system will allocate some RTs for the VPN). As the site
+ is a Spoke site (site-role), the management system knows which RTs
+ must be imported and exported. As the site is provider managed, some
+ management RTs may also be added (100:5000). Standard provider VPN
+ policies MAY also be added in the configuration.
+
+ Example of a generated PE configuration:
+
+l2vpn vsi context one
+ vpn id 12456487
+ autodiscovery bgp signaling bgp
+ ve id 1001 <---- identify the PE routers within the VPLS domain
+ ve range 50 <---- VPLS Edge (VE) size
+ route-distinguisher 100:3123234324
+ route-target import 100:1
+ route-target import 100:5000 <---- Standard SP configuration
+ route-target export 100:2 for provider-managed CE
+ !
+
+ When the VSI has been provisioned, the management system can start
+ configuring the access on the PE using the allocated interface
+ information. The tag or VLAN (e.g., service instance tag) is chosen
+ by the management system. One tag will be picked from an allocated
+ subnet for the PE, and another will be used for the CE configuration.
+
+
+
+Wen, et al. Standards Track [Page 80]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ LACP protocols will also be configured between the PE and the CE; in
+ the case of the provider-managed model, the choice is left to the SP.
+ This choice is independent of the LACP protocol chosen by the
+ customer.
+
+ Example of a generated PE configuration:
+
+ !
+ bridge-domain 1
+ member Ethernet0/0 service-instance 100
+ member vsi one
+ !
+ l2 router-id 198.51.100.1
+ !
+ l2 router-id 2001:db8::10:1/64
+ !
+
+ interface Ethernet0/0
+ no ip address
+ service instance 100 ethernet
+ encapsulation dot1q 100
+ !
+
+ !
+ router bgp 1
+ bgp log-neighbor-changes
+ neighbor 198.51.100.4 remote-as 1
+ neighbor 198.51.100.4 update-source Loopback0
+ !
+ address-family l2vpn vpls
+ neighbor 198.51.100.4 activate
+ neighbor 198.51.100.4 send-community extended
+ neighbor 198.51.100.4 suppress-signaling-protocol ldp
+ neighbor 2001:db8::0a10:4 activate
+ neighbor 2001:db8::0a10:4 send-community extended
+ exit-address-family
+
+ !
+ interface vlan 100 <---- Associating the AC with
+ no ip address the MAC-VRF at the PE
+ xconnect vsi PE1-VPLS-A
+ !
+ vlan 100
+ state active
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 81]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ As the CE router is not reachable at this stage, the management
+ system can produce a complete CE configuration that can be manually
+ uploaded to the node (e.g., before sending the CE to the customer
+ premises at the appropriate postal address, as described in
+ Section 5.3.1). The CE configuration will be built in the same way
+ as the PE configuration is built. Based on (1) the CE type
+ (vendor/model) allocated to the customer and (2) bearer information,
+ the management system knows which interface must be configured on the
+ CE. PE-CE link configuration is expected to be handled automatically
+ using the SP's OSS, as both resources are managed internally.
+ CE-to-LAN interface parameters, such as dot1Q tags, are derived from
+ the Ethernet connection, taking into account how the management
+ system distributes dot1Q tags between the PE and the CE within the
+ subnet. This will allow a plug'n'play configuration to be produced
+ for the CE.
+
+ Example of a generated CE configuration:
+
+ interface Ethernet0/1
+ switchport trunk allowed vlan none
+ switchport mode trunk
+ service instance 100 ethernet
+ encapsulation default
+ l2protocol forward cdp
+ xconnect 203.0.113.1 100 encapsulation mpls
+ !
+
+8. YANG Module
+
+ This YANG module imports typedefs from [RFC6991] and [RFC8341].
+
+<CODE BEGINS> file "ietf-l2vpn-svc@2018-10-09.yang"
+module ietf-l2vpn-svc {
+ yang-version 1.1;
+ namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc";
+ prefix l2vpn-svc;
+
+ import ietf-inet-types {
+ prefix inet;
+ }
+ import ietf-yang-types {
+ prefix yang;
+ }
+ import ietf-netconf-acm {
+ prefix nacm;
+ }
+
+
+
+
+
+Wen, et al. Standards Track [Page 82]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ organization
+ "IETF L2SM Working Group.";
+ contact
+ "WG Web: <https://datatracker.ietf.org/wg/l2sm/>
+ WG List: <mailto:l2sm@ietf.org>
+ Editor: Giuseppe Fioccola
+ <mailto:giuseppe.fioccola@tim.it>";
+ description
+ "This YANG module defines a generic service configuration model
+ for Layer 2 VPN services common across all vendor
+ implementations.
+
+ Copyright (c) 2018 IETF Trust and the persons
+ identified as authors of the code. All rights reserved.
+
+ Redistribution and use in source and binary forms, with or
+ without modification, is permitted pursuant to, and subject
+ to the license terms contained in, the Simplified BSD License
+ set forth in Section 4.c of the IETF Trust's Legal Provisions
+ Relating to IETF Documents
+ (https://trustee.ietf.org/license-info).
+
+ This version of this YANG module is part of RFC 8466;
+ see the RFC itself for full legal notices.";
+
+ revision 2018-10-09 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 8466: A YANG Data Model for Layer 2 Virtual Private
+ Network (L2VPN) Service Delivery";
+ }
+
+ feature carrierscarrier {
+ description
+ "Enables the support of carriers' carriers (CsC).";
+ }
+
+ feature ethernet-oam {
+ description
+ "Enables the support of Ethernet Service OAM.";
+ }
+
+ feature extranet-vpn {
+ description
+ "Enables the support of extranet VPNs.";
+ }
+
+
+
+
+Wen, et al. Standards Track [Page 83]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ feature l2cp-control {
+ description
+ "Enables the support of L2CP control.";
+ }
+
+ feature input-bw {
+ description
+ "Enables the support of input bandwidth in a VPN.";
+ }
+
+ feature output-bw {
+ description
+ "Enables the support of output bandwidth in a VPN.";
+ }
+
+ feature uni-list {
+ description
+ "Enables the support of a list of UNIs in a VPN.";
+ }
+
+ feature cloud-access {
+ description
+ "Allows the VPN to connect to a Cloud Service Provider (CSP)
+ or an ISP.";
+ }
+
+ feature oam-3ah {
+ description
+ "Enables the support of OAM 802.3ah.";
+ }
+
+ feature micro-bfd {
+ description
+ "Enables the support of micro-BFD.";
+ }
+
+ feature bfd {
+ description
+ "Enables the support of BFD.";
+ }
+
+ feature signaling-options {
+ description
+ "Enables the support of signaling options.";
+ }
+
+ feature site-diversity {
+ description
+
+
+
+Wen, et al. Standards Track [Page 84]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Enables the support of site diversity constraints in a VPN.";
+ }
+
+ feature encryption {
+ description
+ "Enables the support of encryption.";
+ }
+
+ feature always-on {
+ description
+ "Enables support for the 'always-on' access constraint.";
+ }
+
+ feature requested-type {
+ description
+ "Enables support for the 'requested-type' access constraint.";
+ }
+
+ feature bearer-reference {
+ description
+ "Enables support for the 'bearer-reference' access
+ constraint.";
+ }
+
+ feature qos {
+ description
+ "Enables support for QoS.";
+ }
+
+ feature qos-custom {
+ description
+ "Enables the support of a custom QoS profile.";
+ }
+
+ feature lag-interface {
+ description
+ "Enables LAG interfaces.";
+ }
+
+ feature vlan {
+ description
+ "Enables the support of VLANs.";
+ }
+
+ feature dot1q {
+ description
+ "Enables the support of dot1Q.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 85]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ feature qinq {
+ description
+ "Enables the support of QinQ.";
+ }
+
+ feature qinany {
+ description
+ "Enables the support of QinAny.";
+ }
+
+ feature vxlan {
+ description
+ "Enables the support of VXLANs.";
+ }
+
+ feature lan-tag {
+ description
+ "Enables LAN tag support in a VPN.";
+ }
+
+ feature target-sites {
+ description
+ "Enables the support of the 'target-sites'
+ match-flow parameter.";
+ }
+
+ feature bum {
+ description
+ "Enables BUM capabilities in a VPN.";
+ }
+
+ feature mac-loop-prevention {
+ description
+ "Enables the MAC loop-prevention capability in a VPN.";
+ }
+
+ feature lacp {
+ description
+ "Enables the Link Aggregation Control Protocol (LACP)
+ capability in a VPN.";
+ }
+
+ feature mac-addr-limit {
+ description
+ "Enables the MAC address limit capability in a VPN.";
+ }
+
+ feature acl {
+
+
+
+Wen, et al. Standards Track [Page 86]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ description
+ "Enables the ACL capability in a VPN.";
+ }
+
+ feature cfm {
+ description
+ "Enables the 802.1ag CFM capability in a VPN.";
+ }
+
+ feature y-1731 {
+ description
+ "Enables the Y.1731 capability in a VPN.";
+ }
+
+ typedef svc-id {
+ type string;
+ description
+ "Defines the type of service component identifier.";
+ }
+
+ typedef ccm-priority-type {
+ type uint8 {
+ range "0..7";
+ }
+ description
+ "A 3-bit priority value to be used in the VLAN tag,
+ if present in the transmitted frame.";
+ }
+
+ typedef control-mode {
+ type enumeration {
+ enum peer {
+ description
+ "'peer' mode, i.e., participate in the protocol towards
+ the CE. Peering is common for LACP and the Ethernet
+ Local Management Interface (E-LMI) and, occasionally,
+ for LLDP. For VPLSs and VPWSs, the subscriber can also
+ request that the SP peer enable spanning tree.";
+ }
+ enum tunnel {
+ description
+ "'tunnel' mode, i.e., pass to the egress or destination
+ site. For EPLs, the expectation is that L2CP frames are
+ tunneled.";
+ }
+ enum discard {
+ description
+ "'discard' mode, i.e., discard the frame.";
+
+
+
+Wen, et al. Standards Track [Page 87]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+ }
+ description
+ "Defines the type of control mode on L2CP protocols.";
+ }
+
+ typedef neg-mode {
+ type enumeration {
+ enum full-duplex {
+ description
+ "Defines full-duplex mode.";
+ }
+ enum auto-neg {
+ description
+ "Defines auto-negotiation mode.";
+ }
+ }
+ description
+ "Defines the type of negotiation mode.";
+ }
+
+ identity site-network-access-type {
+ description
+ "Base identity for the site-network-access type.";
+ }
+
+ identity point-to-point {
+ base site-network-access-type;
+ description
+ "Identity for a point-to-point connection.";
+ }
+
+ identity multipoint {
+ base site-network-access-type;
+ description
+ "Identity for a multipoint connection, e.g.,
+ an Ethernet broadcast segment.";
+ }
+
+ identity tag-type {
+ description
+ "Base identity from which all tag types are derived.";
+ }
+
+ identity c-vlan {
+ base tag-type;
+ description
+ "A CVLAN tag, normally using the 0x8100 Ethertype.";
+
+
+
+Wen, et al. Standards Track [Page 88]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+
+ identity s-vlan {
+ base tag-type;
+ description
+ "An SVLAN tag.";
+ }
+
+ identity c-s-vlan {
+ base tag-type;
+ description
+ "Using both a CVLAN tag and an SVLAN tag.";
+ }
+
+ identity multicast-tree-type {
+ description
+ "Base identity for the multicast tree type.";
+ }
+
+ identity ssm-tree-type {
+ base multicast-tree-type;
+ description
+ "Identity for the Source-Specific Multicast (SSM) tree type.";
+ reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
+ }
+
+ identity asm-tree-type {
+ base multicast-tree-type;
+ description
+ "Identity for the Any-Source Multicast (ASM) tree type.";
+ reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
+ }
+
+ identity bidir-tree-type {
+ base multicast-tree-type;
+ description
+ "Identity for the bidirectional tree type.";
+ reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
+ }
+
+ identity multicast-gp-address-mapping {
+ description
+ "Identity for mapping type.";
+ }
+
+ identity static-mapping {
+ base multicast-gp-address-mapping;
+ description
+
+
+
+Wen, et al. Standards Track [Page 89]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Identity for static mapping, i.e., attach the interface
+ to the multicast group as a static member.";
+ }
+
+ identity dynamic-mapping {
+ base multicast-gp-address-mapping;
+ description
+ "Identity for dynamic mapping, i.e., an interface was added
+ to the multicast group as a result of snooping.";
+ }
+
+ identity tf-type {
+ description
+ "Identity for the traffic type.";
+ }
+
+ identity multicast-traffic {
+ base tf-type;
+ description
+ "Identity for multicast traffic.";
+ }
+
+ identity broadcast-traffic {
+ base tf-type;
+ description
+ "Identity for broadcast traffic.";
+ }
+
+ identity unknown-unicast-traffic {
+ base tf-type;
+ description
+ "Identity for unknown unicast traffic.";
+ }
+
+ identity encapsulation-type {
+ description
+ "Identity for the encapsulation type.";
+ }
+
+ identity ethernet {
+ base encapsulation-type;
+ description
+ "Identity for Ethernet type.";
+ }
+
+ identity vlan {
+ base encapsulation-type;
+ description
+
+
+
+Wen, et al. Standards Track [Page 90]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Identity for the VLAN type.";
+ }
+
+ identity carrierscarrier-type {
+ description
+ "Identity of the CsC type.";
+ }
+
+ identity ldp {
+ base carrierscarrier-type;
+ description
+ "Use LDP as the signaling protocol
+ between the PE and the CE.";
+ }
+
+ identity bgp {
+ base carrierscarrier-type;
+ description
+ "Use BGP (as per RFC 8277) as the signaling protocol
+ between the PE and the CE.
+ In this case, BGP must also be configured as
+ the routing protocol.";
+ }
+
+ identity eth-inf-type {
+ description
+ "Identity of the Ethernet interface type.";
+ }
+
+ identity tagged {
+ base eth-inf-type;
+ description
+ "Identity of the tagged interface type.";
+ }
+
+ identity untagged {
+ base eth-inf-type;
+ description
+ "Identity of the untagged interface type.";
+ }
+
+ identity lag {
+ base eth-inf-type;
+ description
+ "Identity of the LAG interface type.";
+ }
+
+ identity bw-type {
+
+
+
+Wen, et al. Standards Track [Page 91]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ description
+ "Identity of the bandwidth type.";
+ }
+
+ identity bw-per-cos {
+ base bw-type;
+ description
+ "Bandwidth is per CoS.";
+ }
+
+ identity bw-per-port {
+ base bw-type;
+ description
+ "Bandwidth is per site network access.";
+ }
+
+ identity bw-per-site {
+ base bw-type;
+ description
+ "Bandwidth is per site. It is applicable to
+ all the site network accesses within the site.";
+ }
+
+ identity bw-per-svc {
+ base bw-type;
+ description
+ "Bandwidth is per VPN service.";
+ }
+
+ identity site-vpn-flavor {
+ description
+ "Base identity for the site VPN service flavor.";
+ }
+
+ identity site-vpn-flavor-single {
+ base site-vpn-flavor;
+ description
+ "Identity for the site VPN service flavor.
+ Used when the site belongs to only one VPN.";
+ }
+
+ identity site-vpn-flavor-multi {
+ base site-vpn-flavor;
+ description
+ "Identity for the site VPN service flavor.
+ Used when a logical connection of a site
+ belongs to multiple VPNs.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 92]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ identity site-vpn-flavor-nni {
+ base site-vpn-flavor;
+ description
+ "Identity for the site VPN service flavor.
+ Used to describe an NNI option A connection.";
+ }
+
+ identity service-type {
+ description
+ "Base identity of the service type.";
+ }
+
+ identity vpws {
+ base service-type;
+ description
+ "Point-to-point Virtual Private Wire Service (VPWS)
+ service type.";
+ }
+
+ identity pwe3 {
+ base service-type;
+ description
+ "Pseudowire Emulation Edge to Edge (PWE3) service type.";
+ }
+
+ identity ldp-l2tp-vpls {
+ base service-type;
+ description
+ "LDP-based or L2TP-based multipoint Virtual Private LAN
+ Service (VPLS) service type. This VPLS uses LDP-signaled
+ Pseudowires or L2TP-signaled Pseudowires.";
+ }
+
+ identity bgp-vpls {
+ base service-type;
+ description
+ "BGP-based multipoint VPLS service type. This VPLS uses a
+ BGP control plane as described in RFCs 4761 and 6624.";
+ }
+
+ identity vpws-evpn {
+ base service-type;
+ description
+ "VPWS service type using Ethernet VPNs (EVPNs)
+ as specified in RFC 7432.";
+ }
+
+ identity pbb-evpn {
+
+
+
+Wen, et al. Standards Track [Page 93]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ base service-type;
+ description
+ "Provider Backbone Bridge (PBB) service type using
+ EVPNs as specified in RFC 7432.";
+ }
+
+ identity bundling-type {
+ description
+ "The base identity for the bundling type. It supports
+ multiple CE-VLANs associated with an L2VPN service or
+ all CE-VLANs associated with an L2VPN service.";
+ }
+
+ identity multi-svc-bundling {
+ base bundling-type;
+ description
+ "Identity for multi-service bundling, i.e.,
+ multiple CE-VLAN IDs can be associated with an
+ L2VPN service at a site.";
+ }
+
+ identity one2one-bundling {
+ base bundling-type;
+ description
+ "Identity for one-to-one service bundling, i.e.,
+ each L2VPN can be associated with only one CE-VLAN ID
+ at a site.";
+ }
+
+ identity all2one-bundling {
+ base bundling-type;
+ description
+ "Identity for all-to-one bundling, i.e., all CE-VLAN IDs
+ are mapped to one L2VPN service.";
+ }
+
+ identity color-id {
+ description
+ "Base identity of the color ID.";
+ }
+
+ identity color-id-cvlan {
+ base color-id;
+ description
+ "Identity of the color ID based on a CVLAN.";
+ }
+
+ identity cos-id {
+
+
+
+Wen, et al. Standards Track [Page 94]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ description
+ "Identity of the CoS ID.";
+ }
+
+ identity cos-id-pcp {
+ base cos-id;
+ description
+ "Identity of the CoS ID based on the
+ Port Control Protocol (PCP).";
+ }
+
+ identity cos-id-dscp {
+ base cos-id;
+ description
+ "Identity of the CoS ID based on DSCP.";
+ }
+
+ identity color-type {
+ description
+ "Identity of color types.";
+ }
+
+ identity green {
+ base color-type;
+ description
+ "Identity of the 'green' color type.";
+ }
+
+ identity yellow {
+ base color-type;
+ description
+ "Identity of the 'yellow' color type.";
+ }
+
+ identity red {
+ base color-type;
+ description
+ "Identity of the 'red' color type.";
+ }
+
+ identity policing {
+ description
+ "Identity of the type of policing applied.";
+ }
+
+ identity one-rate-two-color {
+ base policing;
+ description
+
+
+
+Wen, et al. Standards Track [Page 95]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Identity of one-rate, two-color (1R2C).";
+ }
+
+ identity two-rate-three-color {
+ base policing;
+ description
+ "Identity of two-rate, three-color (2R3C).";
+ }
+
+ identity bum-type {
+ description
+ "Identity of the BUM type.";
+ }
+
+ identity broadcast {
+ base bum-type;
+ description
+ "Identity of broadcast.";
+ }
+
+ identity unicast {
+ base bum-type;
+ description
+ "Identity of unicast.";
+ }
+
+ identity multicast {
+ base bum-type;
+ description
+ "Identity of multicast.";
+ }
+
+ identity loop-prevention-type {
+ description
+ "Identity of loop prevention.";
+ }
+
+ identity shut {
+ base loop-prevention-type;
+ description
+ "Identity of shut protection.";
+ }
+
+ identity trap {
+ base loop-prevention-type;
+ description
+ "Identity of trap protection.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 96]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ identity lacp-state {
+ description
+ "Identity of the LACP state.";
+ }
+
+ identity lacp-on {
+ base lacp-state;
+ description
+ "Identity of LACP on.";
+ }
+
+ identity lacp-off {
+ base lacp-state;
+ description
+ "Identity of LACP off.";
+ }
+
+ identity lacp-mode {
+ description
+ "Identity of the LACP mode.";
+ }
+
+ identity lacp-passive {
+ base lacp-mode;
+ description
+ "Identity of LACP passive.";
+ }
+
+ identity lacp-active {
+ base lacp-mode;
+ description
+ "Identity of LACP active.";
+ }
+
+ identity lacp-speed {
+ description
+ "Identity of the LACP speed.";
+ }
+
+ identity lacp-fast {
+ base lacp-speed;
+ description
+ "Identity of LACP fast.";
+ }
+
+ identity lacp-slow {
+ base lacp-speed;
+ description
+
+
+
+Wen, et al. Standards Track [Page 97]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Identity of LACP slow.";
+ }
+
+ identity bw-direction {
+ description
+ "Identity for the bandwidth direction.";
+ }
+
+ identity input-bw {
+ base bw-direction;
+ description
+ "Identity for the input bandwidth.";
+ }
+
+ identity output-bw {
+ base bw-direction;
+ description
+ "Identity for the output bandwidth.";
+ }
+
+ identity management {
+ description
+ "Base identity for the site management scheme.";
+ }
+
+ identity co-managed {
+ base management;
+ description
+ "Identity for a co-managed site.";
+ }
+
+ identity customer-managed {
+ base management;
+ description
+ "Identity for a customer-managed site.";
+ }
+
+ identity provider-managed {
+ base management;
+ description
+ "Identity for a provider-managed site.";
+ }
+
+ identity address-family {
+ description
+ "Identity for an address family.";
+ }
+
+
+
+
+Wen, et al. Standards Track [Page 98]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ identity ipv4 {
+ base address-family;
+ description
+ "Identity for an IPv4 address family.";
+ }
+
+ identity ipv6 {
+ base address-family;
+ description
+ "Identity for an IPv6 address family.";
+ }
+
+ identity vpn-topology {
+ description
+ "Base identity for the VPN topology.";
+ }
+
+ identity any-to-any {
+ base vpn-topology;
+ description
+ "Identity for the any-to-any VPN topology.";
+ }
+
+ identity hub-spoke {
+ base vpn-topology;
+ description
+ "Identity for the Hub-and-Spoke VPN topology.";
+ }
+
+ identity hub-spoke-disjoint {
+ base vpn-topology;
+ description
+ "Identity for the Hub-and-Spoke VPN topology,
+ where Hubs cannot communicate with each other.";
+ }
+
+ identity site-role {
+ description
+ "Base identity for a site type.";
+ }
+
+ identity any-to-any-role {
+ base site-role;
+ description
+ "Site in an any-to-any L2VPN.";
+ }
+
+ identity spoke-role {
+
+
+
+Wen, et al. Standards Track [Page 99]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ base site-role;
+ description
+ "Spoke site in a Hub-and-Spoke L2VPN.";
+ }
+
+ identity hub-role {
+ base site-role;
+ description
+ "Hub site in a Hub-and-Spoke L2VPN.";
+ }
+
+ identity pm-type {
+ description
+ "Performance-monitoring type.";
+ }
+
+ identity loss {
+ base pm-type;
+ description
+ "Loss measurement.";
+ }
+
+ identity delay {
+ base pm-type;
+ description
+ "Delay measurement.";
+ }
+
+ identity fault-alarm-defect-type {
+ description
+ "Indicates the alarm-priority defect (i.e., the
+ lowest-priority defect that is allowed to
+ generate a fault alarm).";
+ }
+
+ identity remote-rdi {
+ base fault-alarm-defect-type;
+ description
+ "Indicates the aggregate health
+ of the Remote MEPs.";
+ }
+
+ identity remote-mac-error {
+ base fault-alarm-defect-type;
+ description
+ "Indicates that one or more of the Remote MEPs are
+ reporting a failure in their Port Status TLVs or
+ Interface Status TLVs.";
+
+
+
+Wen, et al. Standards Track [Page 100]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+
+ identity remote-invalid-ccm {
+ base fault-alarm-defect-type;
+ description
+ "Indicates that at least one of the Remote MEP
+ state machines is not receiving valid
+ Continuity Check Messages (CCMs) from its Remote MEP.";
+ }
+
+ identity invalid-ccm {
+ base fault-alarm-defect-type;
+ description
+ "Indicates that one or more invalid CCMs have been
+ received and that a period of time 3.5 times the length
+ of those CCMs' transmission intervals has not yet expired.";
+ }
+
+ identity cross-connect-ccm {
+ base fault-alarm-defect-type;
+ description
+ "Indicates that one or more cross-connect CCMs have been
+ received and that 3.5 times the period of at least one of
+ those CCMs' transmission intervals has not yet expired.";
+ }
+
+ identity frame-delivery-mode {
+ description
+ "Delivery types.";
+ }
+
+ identity discard {
+ base frame-delivery-mode;
+ description
+ "Service frames are discarded.";
+ }
+
+ identity unconditional {
+ base frame-delivery-mode;
+ description
+ "Service frames are unconditionally delivered to the
+ destination site.";
+ }
+
+ identity unknown-discard {
+ base frame-delivery-mode;
+ description
+ "Service frames are conditionally delivered to the
+
+
+
+Wen, et al. Standards Track [Page 101]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ destination site. Packets with unknown destination addresses
+ will be discarded.";
+ }
+
+ identity placement-diversity {
+ description
+ "Base identity for site placement constraints.";
+ }
+
+ identity bearer-diverse {
+ base placement-diversity;
+ description
+ "Identity for bearer diversity.
+ The bearers should not use common elements.";
+ }
+
+ identity pe-diverse {
+ base placement-diversity;
+ description
+ "Identity for PE diversity.";
+ }
+
+ identity pop-diverse {
+ base placement-diversity;
+ description
+ "Identity for POP diversity.";
+ }
+
+ identity linecard-diverse {
+ base placement-diversity;
+ description
+ "Identity for linecard diversity.";
+ }
+
+ identity same-pe {
+ base placement-diversity;
+ description
+ "Identity for having sites connected on the same PE.";
+ }
+
+ identity same-bearer {
+ base placement-diversity;
+ description
+ "Identity for having sites connected using the same bearer.";
+ }
+
+ identity tagged-inf-type {
+ description
+
+
+
+Wen, et al. Standards Track [Page 102]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Identity for the tagged interface type.";
+ }
+
+ identity priority-tagged {
+ base tagged-inf-type;
+ description
+ "Identity for the priority-tagged interface.";
+ }
+
+ identity qinq {
+ base tagged-inf-type;
+ description
+ "Identity for the QinQ tagged interface.";
+ }
+
+ identity dot1q {
+ base tagged-inf-type;
+ description
+ "Identity for the dot1Q VLAN tagged interface.";
+ }
+
+ identity qinany {
+ base tagged-inf-type;
+ description
+ "Identity for the QinAny tagged interface.";
+ }
+
+ identity vxlan {
+ base tagged-inf-type;
+ description
+ "Identity for the VXLAN tagged interface.";
+ }
+
+ identity provision-model {
+ description
+ "Base identity for the provision model.";
+ }
+
+ identity single-side-provision {
+ description
+ "Identity for single-sided provisioning with discovery.";
+ }
+
+ identity doubled-side-provision {
+ description
+ "Identity for double-sided provisioning.";
+ }
+
+
+
+
+Wen, et al. Standards Track [Page 103]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ identity mac-learning-mode {
+ description
+ "MAC learning mode.";
+ }
+
+ identity data-plane {
+ base mac-learning-mode;
+ description
+ "User MAC addresses are learned through ARP broadcast.";
+ }
+
+ identity control-plane {
+ base mac-learning-mode;
+ description
+ "User MAC addresses are advertised through EVPN-BGP.";
+ }
+
+ identity vpn-policy-filter-type {
+ description
+ "Base identity for the filter type.";
+ }
+
+ identity lan {
+ base vpn-policy-filter-type;
+ description
+ "Identity for a LAN tag filter type.";
+ }
+
+ identity mac-action {
+ description
+ "Base identity for a MAC action.";
+ }
+
+ identity drop {
+ base mac-action;
+ description
+ "Identity for dropping a packet.";
+ }
+
+ identity flood {
+ base mac-action;
+ description
+ "Identity for packet flooding.";
+ }
+
+ identity warning {
+ base mac-action;
+ description
+
+
+
+Wen, et al. Standards Track [Page 104]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Identity for sending a warning log message.";
+ }
+
+ identity qos-profile-direction {
+ description
+ "Base identity for the QoS-profile direction.";
+ }
+
+ identity site-to-wan {
+ base qos-profile-direction;
+ description
+ "Identity for the site-to-WAN direction.";
+ }
+
+ identity wan-to-site {
+ base qos-profile-direction;
+ description
+ "Identity for the WAN-to-site direction.";
+ }
+
+ identity bidirectional {
+ base qos-profile-direction;
+ description
+ "Identity for both the WAN-to-site direction
+ and the site-to-WAN direction.";
+ }
+
+ identity vxlan-peer-mode {
+ description
+ "Base identity for the VXLAN peer mode.";
+ }
+
+ identity static-mode {
+ base vxlan-peer-mode;
+ description
+ "Identity for VXLAN access in the static mode.";
+ }
+
+ identity bgp-mode {
+ base vxlan-peer-mode;
+ description
+ "Identity for VXLAN access by BGP EVPN learning.";
+ }
+
+ identity customer-application {
+ description
+ "Base identity for a customer application.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 105]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ identity web {
+ base customer-application;
+ description
+ "Identity for a web application (e.g., HTTP, HTTPS).";
+ }
+
+ identity mail {
+ base customer-application;
+ description
+ "Identity for a mail application.";
+ }
+
+ identity file-transfer {
+ base customer-application;
+ description
+ "Identity for a file-transfer application
+ (e.g., FTP, SFTP).";
+ }
+
+ identity database {
+ base customer-application;
+ description
+ "Identity for a database application.";
+ }
+
+ identity social {
+ base customer-application;
+ description
+ "Identity for a social-network application.";
+ }
+
+ identity games {
+ base customer-application;
+ description
+ "Identity for a gaming application.";
+ }
+
+ identity p2p {
+ base customer-application;
+ description
+ "Identity for a peer-to-peer application.";
+ }
+
+ identity network-management {
+ base customer-application;
+ description
+ "Identity for a management application
+ (e.g., Telnet, syslog, SNMP).";
+
+
+
+Wen, et al. Standards Track [Page 106]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+
+ identity voice {
+ base customer-application;
+ description
+ "Identity for a voice application.";
+ }
+
+ identity video {
+ base customer-application;
+ description
+ "Identity for a videoconference application.";
+ }
+
+ identity embb {
+ base customer-application;
+ description
+ "Identity for the enhanced Mobile Broadband (eMBB)
+ application. Note that the eMBB application
+ requires strict threshold values for a wide variety
+ of network performance parameters (e.g., data rate,
+ latency, loss rate, reliability).";
+ }
+
+ identity urllc {
+ base customer-application;
+ description
+ "Identity for the Ultra-Reliable and Low Latency
+ Communications (URLLC) application. Note that the
+ URLLC application requires strict threshold values for
+ a wide variety of network performance parameters
+ (e.g., latency, reliability).";
+ }
+
+ identity mmtc {
+ base customer-application;
+ description
+ "Identity for the massive Machine Type
+ Communications (mMTC) application. Note that the
+ mMTC application requires strict threshold values for
+ a wide variety of network performance parameters
+ (e.g., data rate, latency, loss rate, reliability).";
+ }
+
+ grouping site-acl {
+ container access-control-list {
+ if-feature "acl";
+ list mac {
+
+
+
+Wen, et al. Standards Track [Page 107]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ key "mac-address";
+ leaf mac-address {
+ type yang:mac-address;
+ description
+ "MAC addresses.";
+ }
+ description
+ "List of MAC addresses.";
+ }
+ description
+ "Container for the ACL.";
+ }
+ description
+ "Grouping that defines the ACL.";
+ }
+
+ grouping site-bum {
+ container broadcast-unknown-unicast-multicast {
+ if-feature "bum";
+ leaf multicast-site-type {
+ type enumeration {
+ enum receiver-only {
+ description
+ "The site only has receivers.";
+ }
+ enum source-only {
+ description
+ "The site only has sources.";
+ }
+ enum source-receiver {
+ description
+ "The site has both sources and receivers.";
+ }
+ }
+ default "source-receiver";
+ description
+ "Type of multicast site.";
+ }
+ list multicast-gp-address-mapping {
+ key "id";
+ leaf id {
+ type uint16;
+ description
+ "Unique identifier for the mapping.";
+ }
+ leaf vlan-id {
+ type uint16 {
+ range "0..1024";
+
+
+
+Wen, et al. Standards Track [Page 108]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+ mandatory true;
+ description
+ "The VLAN ID of the multicast group.
+ The range of the 12-bit VLAN ID is 0 to 1024.";
+ }
+ leaf mac-gp-address {
+ type yang:mac-address;
+ mandatory true;
+ description
+ "The MAC address of the multicast group.";
+ }
+ leaf port-lag-number {
+ type uint32;
+ description
+ "The ports/LAGs belonging to the multicast group.";
+ }
+ description
+ "List of port-to-group mappings.";
+ }
+ leaf bum-overall-rate {
+ type uint64;
+ units "bps";
+ description
+ "Overall rate for BUM.";
+ }
+ list bum-rate-per-type {
+ key "type";
+ leaf type {
+ type identityref {
+ base bum-type;
+ }
+ description
+ "BUM type.";
+ }
+ leaf rate {
+ type uint64;
+ units "bps";
+ description
+ "Rate for BUM.";
+ }
+ description
+ "List of limit rates for the BUM type.";
+ }
+ description
+ "Container of BUM configurations.";
+ }
+ description
+
+
+
+Wen, et al. Standards Track [Page 109]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Grouping for BUM.";
+ }
+
+ grouping site-mac-loop-prevention {
+ container mac-loop-prevention {
+ if-feature "mac-loop-prevention";
+ leaf protection-type {
+ type identityref {
+ base loop-prevention-type;
+ }
+ default "trap";
+ description
+ "Protection type. By default, the protection
+ type is 'trap'.";
+ }
+ leaf frequency {
+ type uint32;
+ default "5";
+ description
+ "The number of times to detect MAC duplication, where
+ a 'duplicate MAC address' situation has occurred and
+ the duplicate MAC address has been added to a list of
+ duplicate MAC addresses. By default, the number of
+ times is 5.";
+ }
+ leaf retry-timer {
+ type uint32;
+ units "seconds";
+ description
+ "The retry timer. When the retry timer expires,
+ the duplicate MAC address will be flushed from
+ the MAC-VRF.";
+ }
+ description
+ "Container of MAC loop-prevention parameters.";
+ }
+ description
+ "Grouping for MAC loop prevention.";
+ }
+
+ grouping site-service-qos-profile {
+ container qos {
+ if-feature "qos";
+ container qos-classification-policy {
+ list rule {
+ key "id";
+ ordered-by user;
+ leaf id {
+
+
+
+Wen, et al. Standards Track [Page 110]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ type string;
+ description
+ "A description identifying the QoS classification
+ policy rule.";
+ }
+ choice match-type {
+ default "match-flow";
+ case match-flow {
+ container match-flow {
+ leaf dscp {
+ type inet:dscp;
+ description
+ "DSCP value.";
+ }
+ leaf dot1q {
+ type uint16;
+ description
+ "802.1Q matching. It is a VLAN tag added into
+ a frame.";
+ }
+ leaf pcp {
+ type uint8 {
+ range "0..7";
+ }
+ description
+ "PCP value.";
+ }
+ leaf src-mac {
+ type yang:mac-address;
+ description
+ "Source MAC.";
+ }
+ leaf dst-mac {
+ type yang:mac-address;
+ description
+ "Destination MAC.";
+ }
+ leaf color-type {
+ type identityref {
+ base color-type;
+ }
+ description
+ "Color types.";
+ }
+ leaf-list target-sites {
+ if-feature "target-sites";
+ type svc-id;
+ description
+
+
+
+Wen, et al. Standards Track [Page 111]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Identifies a site as a traffic destination.";
+ }
+ leaf any {
+ type empty;
+ description
+ "Allow all.";
+ }
+ leaf vpn-id {
+ type svc-id;
+ description
+ "Reference to the target VPN.";
+ }
+ description
+ "Describes flow-matching criteria.";
+ }
+ }
+ case match-application {
+ leaf match-application {
+ type identityref {
+ base customer-application;
+ }
+ description
+ "Defines the application to match.";
+ }
+ }
+ description
+ "Choice for classification.";
+ }
+ leaf target-class-id {
+ type string;
+ description
+ "Identification of the CoS.
+ This identifier is internal to the
+ administration.";
+ }
+ description
+ "List of marking rules.";
+ }
+ description
+ "Configuration of the traffic classification policy.";
+ }
+ container qos-profile {
+ choice qos-profile {
+ description
+ "Choice for the QoS profile.
+ Can be a standard profile or a customized profile.";
+ case standard {
+ description
+
+
+
+Wen, et al. Standards Track [Page 112]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Standard QoS profile.";
+ leaf profile {
+ type leafref {
+ path "/l2vpn-svc/vpn-profiles/"
+ + "valid-provider-identifiers/"
+ + "qos-profile-identifier";
+ }
+ description
+ "QoS profile to be used.";
+ }
+ }
+ case custom {
+ description
+ "Customized QoS profile.";
+ container classes {
+ if-feature "qos-custom";
+ list class {
+ key "class-id";
+ leaf class-id {
+ type string;
+ description
+ "Identification of the CoS. This identifier is
+ internal to the administration.";
+ }
+ leaf direction {
+ type identityref {
+ base qos-profile-direction;
+ }
+ default "bidirectional";
+ description
+ "The direction in which the QoS profile is
+ applied. By default, the direction is
+ bidirectional.";
+ }
+ leaf policing {
+ type identityref {
+ base policing;
+ }
+ default "one-rate-two-color";
+ description
+ "The policing type can be either one-rate,
+ two-color (1R2C) or two-rate, three-color
+ (2R3C). By default, the policing type is
+ 'one-rate-two-color'.";
+ }
+ leaf byte-offset {
+ type uint16;
+ description
+
+
+
+Wen, et al. Standards Track [Page 113]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Number of bytes in the service frame header
+ that are excluded from the QoS calculation
+ (e.g., extra VLAN tags).";
+ }
+ container frame-delay {
+ choice flavor {
+ case lowest {
+ leaf use-lowest-latency {
+ type empty;
+ description
+ "The traffic class should use the path
+ with the lowest delay.";
+ }
+ }
+ case boundary {
+ leaf delay-bound {
+ type uint16;
+ units "milliseconds";
+ description
+ "The traffic class should use a path
+ with a defined maximum delay.";
+ }
+ }
+ description
+ "Delay constraint on the traffic class.";
+ }
+ description
+ "Delay constraint on the traffic class.";
+ }
+ container frame-jitter {
+ choice flavor {
+ case lowest {
+ leaf use-lowest-jitter {
+ type empty;
+ description
+ "The traffic class should use the path
+ with the lowest jitter.";
+ }
+ }
+ case boundary {
+ leaf delay-bound {
+ type uint32;
+ units "microseconds";
+ description
+ "The traffic class should use a path
+ with a defined maximum jitter.";
+ }
+ }
+
+
+
+Wen, et al. Standards Track [Page 114]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ description
+ "Jitter constraint on the traffic class.";
+ }
+ description
+ "Jitter constraint on the traffic class.";
+ }
+ container frame-loss {
+ leaf rate {
+ type decimal64 {
+ fraction-digits 2;
+ range "0..100";
+ }
+ units "percent";
+ description
+ "Frame loss rate constraint on the traffic
+ class.";
+ }
+ description
+ "Container for frame loss rate.";
+ }
+ container bandwidth {
+ leaf guaranteed-bw-percent {
+ type decimal64 {
+ fraction-digits 5;
+ range "0..100";
+ }
+ units "percent";
+ mandatory true;
+ description
+ "Used to define the guaranteed bandwidth
+ as a percentage of the available service
+ bandwidth.";
+ }
+ leaf end-to-end {
+ type empty;
+ description
+ "Used if the bandwidth reservation
+ must be done on the MPLS network too.";
+ }
+ description
+ "Bandwidth constraint on the traffic class.";
+ }
+ description
+ "List of CoS entries.";
+ }
+ description
+ "Container for list of CoS entries.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 115]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+ }
+ description
+ "Qos profile configuration.";
+ }
+ description
+ "QoS configuration.";
+ }
+ description
+ "Grouping that defines QoS parameters for a site.";
+ }
+
+ grouping site-service-mpls {
+ container carrierscarrier {
+ if-feature "carrierscarrier";
+ leaf signaling-type {
+ type identityref {
+ base carrierscarrier-type;
+ }
+ default "bgp";
+ description
+ "CsC. By default, the signaling type is 'bgp'.";
+ }
+ description
+ "Container for CsC.";
+ }
+ description
+ "Grouping for CsC.";
+ }
+
+ container l2vpn-svc {
+ container vpn-profiles {
+ container valid-provider-identifiers {
+ leaf-list cloud-identifier {
+ if-feature "cloud-access";
+ type string;
+ description
+ "Identification of the public cloud service or
+ Internet service. Local to each administration.";
+ }
+ leaf-list qos-profile-identifier {
+ type string;
+ description
+ "Identification of the QoS profile to be used.
+ Local to each administration.";
+ }
+ leaf-list bfd-profile-identifier {
+ type string;
+
+
+
+Wen, et al. Standards Track [Page 116]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ description
+ "Identification of the SP BFD profile to be used.
+ Local to each administration.";
+ }
+ leaf-list remote-carrier-identifier {
+ type string;
+ description
+ "Identification of the remote carrier name to be used.
+ It can be an L2VPN partner, data-center SP, or
+ private CSP. Local to each administration.";
+ }
+ nacm:default-deny-write;
+ description
+ "Container for valid provider identifiers.";
+ }
+ description
+ "Container for VPN profiles.";
+ }
+ container vpn-services {
+ list vpn-service {
+ key "vpn-id";
+ leaf vpn-id {
+ type svc-id;
+ description
+ "Defines a service identifier.";
+ }
+ leaf vpn-svc-type {
+ type identityref {
+ base service-type;
+ }
+ default "vpws";
+ description
+ "Service type. By default, the service type is 'vpws'.";
+ }
+ leaf customer-name {
+ type string;
+ description
+ "Customer name.";
+ }
+ leaf svc-topo {
+ type identityref {
+ base vpn-topology;
+ }
+ default "any-to-any";
+ description
+ "Defines the service topology, e.g.,
+ 'any-to-any', 'hub-spoke'.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 117]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ container cloud-accesses {
+ if-feature "cloud-access";
+ list cloud-access {
+ key "cloud-identifier";
+ leaf cloud-identifier {
+ type leafref {
+ path "/l2vpn-svc/vpn-profiles/"
+ + "valid-provider-identifiers"
+ + "/cloud-identifier";
+ }
+ description
+ "Identification of the cloud service.
+ Local to each administration.";
+ }
+ choice list-flavor {
+ case permit-any {
+ leaf permit-any {
+ type empty;
+ description
+ "Allow all sites.";
+ }
+ }
+ case deny-any-except {
+ leaf-list permit-site {
+ type leafref {
+ path "/l2vpn-svc/sites/site/site-id";
+ }
+ description
+ "Site ID to be authorized.";
+ }
+ }
+ case permit-any-except {
+ leaf-list deny-site {
+ type leafref {
+ path "/l2vpn-svc/sites/site/site-id";
+ }
+ description
+ "Site ID to be denied.";
+ }
+ }
+ description
+ "Choice for cloud access policy.
+ By default, all sites in the L2VPN
+ MUST be authorized to access the cloud.";
+ }
+ description
+ "Cloud access configuration.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 118]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ description
+ "Container for cloud access configurations.";
+ }
+ container frame-delivery {
+ if-feature "bum";
+ container customer-tree-flavors {
+ leaf-list tree-flavor {
+ type identityref {
+ base multicast-tree-type;
+ }
+ description
+ "Type of tree to be used.";
+ }
+ description
+ "Types of trees used by the customer.";
+ }
+ container bum-deliveries {
+ list bum-delivery {
+ key "frame-type";
+ leaf frame-type {
+ type identityref {
+ base tf-type;
+ }
+ description
+ "Type of frame delivery. It supports unicast
+ frame delivery, multicast frame delivery,
+ and broadcast frame delivery.";
+ }
+ leaf delivery-mode {
+ type identityref {
+ base frame-delivery-mode;
+ }
+ default "unconditional";
+ description
+ "Defines the frame delivery mode
+ ('unconditional' (default), 'conditional',
+ or 'discard'). By default, service frames are
+ unconditionally delivered to the destination site.";
+ }
+ description
+ "List of frame delivery types and modes.";
+ }
+ description
+ "Defines the frame delivery types and modes.";
+ }
+ leaf multicast-gp-port-mapping {
+ type identityref {
+ base multicast-gp-address-mapping;
+
+
+
+Wen, et al. Standards Track [Page 119]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+ mandatory true;
+ description
+ "Describes the way in which each interface is
+ associated with the multicast group.";
+ }
+ description
+ "Multicast global parameters for the VPN service.";
+ }
+ container extranet-vpns {
+ if-feature "extranet-vpn";
+ list extranet-vpn {
+ key "vpn-id";
+ leaf vpn-id {
+ type svc-id;
+ description
+ "Identifies the target VPN that the local VPN wants to
+ access.";
+ }
+ leaf local-sites-role {
+ type identityref {
+ base site-role;
+ }
+ default "any-to-any-role";
+ description
+ "Describes the role of the local sites in the target
+ VPN topology. In the any-to-any VPN service topology,
+ the local 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, the local sites must have a Hub role or a
+ Spoke role.";
+ }
+ description
+ "List of extranet VPNs to which the local VPN
+ is attached.";
+ }
+ description
+ "Container for extranet VPN configurations.";
+ }
+ leaf ce-vlan-preservation {
+ type boolean;
+ mandatory true;
+ description
+ "Preserves the CE-VLAN ID from ingress to egress, i.e.,
+ the CE-VLAN tag of the egress frame is identical to
+ that of the ingress frame that yielded this
+ egress service frame. If all-to-one bundling within
+
+
+
+Wen, et al. Standards Track [Page 120]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ a site is enabled, then preservation applies to all
+ ingress service frames. If all-to-one bundling is
+ disabled, then preservation applies to tagged
+ ingress service frames having CE-VLAN IDs 1 through 4094.";
+ }
+ leaf ce-vlan-cos-preservation {
+ type boolean;
+ mandatory true;
+ description
+ "CE VLAN CoS preservation. The PCP bits in the CE-VLAN tag
+ of the egress frame are identical to those of the
+ ingress frame that yielded this egress service frame.";
+ }
+ leaf carrierscarrier {
+ if-feature "carrierscarrier";
+ type boolean;
+ default "false";
+ description
+ "The VPN is using CsC, and so MPLS is required.";
+ }
+ description
+ "List of VPN services.";
+ }
+ description
+ "Container for VPN services.";
+ }
+ container sites {
+ list site {
+ key "site-id";
+ leaf site-id {
+ type string;
+ description
+ "Identifier of the site.";
+ }
+ leaf site-vpn-flavor {
+ type identityref {
+ base site-vpn-flavor;
+ }
+ default "site-vpn-flavor-single";
+ description
+ "Defines the way that the VPN multiplexing is
+ done, e.g., whether the site belongs to
+ a single VPN site or a multi-VPN site. By
+ default, the site belongs to a single VPN.";
+ }
+ container devices {
+ when "derived-from-or-self(../management/type, "
+ + "'l2vpn-svc:provider-managed') or "
+
+
+
+Wen, et al. Standards Track [Page 121]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ + "derived-from-or-self(../management/type, "
+ + "'l2vpn-svc:co-managed')" {
+ description
+ "Applicable only for a provider-managed or
+ co-managed device.";
+ }
+ list device {
+ key "device-id";
+ leaf device-id {
+ type string;
+ description
+ "Identifier for the device.";
+ }
+ leaf location {
+ type leafref {
+ path "../../../locations/location/location-id";
+ }
+ mandatory true;
+ description
+ "Location of the device.";
+ }
+ container management {
+ when "derived-from-or-self(../../../management/type, "
+ + "'l2vpn-svc:co-managed')" {
+ description
+ "Applicable only for a co-managed device.";
+ }
+ leaf transport {
+ type identityref {
+ base address-family;
+ }
+ description
+ "Transport protocol or address family
+ used for management.";
+ }
+ leaf address {
+ when '(../ transport)' {
+ description
+ "If the address family is specified, then the
+ address should also be specified. If the
+ transport is not specified, then the address
+ should not be specified.";
+ }
+ type inet:ip-address;
+ description
+ "Management address.";
+ }
+ description
+
+
+
+Wen, et al. Standards Track [Page 122]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Management configuration. Applicable only for a
+ co-managed device.";
+ }
+ description
+ "List of devices requested by the customer.";
+ }
+ description
+ "Device configurations.";
+ }
+ container management {
+ leaf type {
+ type identityref {
+ base management;
+ }
+ mandatory true;
+ description
+ "Management type of the connection.";
+ }
+ description
+ "Management configuration.";
+ }
+ container locations {
+ list location {
+ key "location-id";
+ leaf location-id {
+ type string;
+ description
+ "Location ID.";
+ }
+ leaf address {
+ type string;
+ description
+ "Address (number and street) of the site.";
+ }
+ leaf postal-code {
+ type string;
+ description
+ "Postal code of the site. The format of 'postal-code'
+ is similar to the 'PC' (postal code) label format
+ defined in RFC 4119.";
+ }
+ leaf state {
+ type string;
+ description
+ "State (region) of the site. This leaf can also be used
+ to describe a region of a country that does not have
+ states.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 123]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ leaf city {
+ type string;
+ description
+ "City of the site.";
+ }
+ leaf country-code {
+ type string;
+ description
+ "Country of the site. The format of 'country-code' is
+ similar to the 'country' label defined in RFC 4119.";
+ }
+ description
+ "List of locations.";
+ }
+ description
+ "Location of the site.";
+ }
+ container site-diversity {
+ if-feature "site-diversity";
+ container groups {
+ list group {
+ key "group-id";
+ leaf group-id {
+ type string;
+ description
+ "The group-id to which the site belongs.";
+ }
+ description
+ "List of group-ids.";
+ }
+ description
+ "Groups to which the site belongs.
+ All site network accesses will inherit those group
+ values.";
+ }
+ description
+ "The type of diversity constraint.";
+ }
+ container vpn-policies {
+ list vpn-policy {
+ key "vpn-policy-id";
+ leaf vpn-policy-id {
+ type string;
+ description
+ "Unique identifier for the VPN policy.";
+ }
+ list entries {
+ key "id";
+
+
+
+Wen, et al. Standards Track [Page 124]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ leaf id {
+ type string;
+ description
+ "Unique identifier for the policy entry.";
+ }
+ container filters {
+ list filter {
+ key "type";
+ ordered-by user;
+ leaf type {
+ type identityref {
+ base vpn-policy-filter-type;
+ }
+ description
+ "Type of VPN policy filter.";
+ }
+ leaf-list lan-tag {
+ when "derived-from-or-self(../type, "
+ + "'l2vpn-svc:lan')" {
+ description
+ "Only applies when the VPN policy filter is a
+ LAN tag filter.";
+ }
+ if-feature "lan-tag";
+ type uint32;
+ description
+ "List of Ethernet LAN tags to be matched. An
+ Ethernet LAN tag identifies a particular
+ broadcast domain in a VPN.";
+ }
+ description
+ "List of filters used on the site. This list can
+ be augmented.";
+ }
+ description
+ "If a more granular VPN attachment is necessary,
+ filtering can be used. If used, it permits the
+ splitting of site LANs among multiple VPNs. The
+ site LAN can be split based on either the LAN tag or
+ the LAN prefix. If no filter is used, all the LANs
+ will be part of the same VPNs with the same role.";
+ }
+ list vpn {
+ key "vpn-id";
+ leaf vpn-id {
+ type leafref {
+ path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
+ }
+
+
+
+Wen, et al. Standards Track [Page 125]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ description
+ "Reference to an L2VPN.";
+ }
+ leaf site-role {
+ type identityref {
+ base site-role;
+ }
+ default "any-to-any-role";
+ description
+ "Role of the site in the L2VPN.";
+ }
+ description
+ "List of VPNs with which the LAN is associated.";
+ }
+ description
+ "List of entries for an export policy.";
+ }
+ description
+ "List of VPN policies.";
+ }
+ description
+ "VPN policy.";
+ }
+ container service {
+ uses site-service-qos-profile;
+ uses site-service-mpls;
+ description
+ "Service parameters on the attachment.";
+ }
+ uses site-bum;
+ uses site-mac-loop-prevention;
+ uses site-acl;
+ leaf actual-site-start {
+ type yang:date-and-time;
+ config false;
+ description
+ "This leaf is optional. It indicates the date and time
+ when the service at a particular site actually started.";
+ }
+ leaf actual-site-stop {
+ type yang:date-and-time;
+ config false;
+ description
+ "This leaf is optional. It indicates the date and time
+ when the service at a particular site actually stopped.";
+ }
+ leaf bundling-type {
+ type identityref {
+
+
+
+Wen, et al. Standards Track [Page 126]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ base bundling-type;
+ }
+ default "one2one-bundling";
+ description
+ "Bundling type. By default, each L2VPN
+ can be associated with only one
+ CE-VLAN, i.e., one-to-one bundling is used.";
+ }
+ leaf default-ce-vlan-id {
+ type uint32;
+ mandatory true;
+ description
+ "Default CE VLAN ID set at the site level.";
+ }
+ container site-network-accesses {
+ list site-network-access {
+ key "network-access-id";
+ leaf network-access-id {
+ type string;
+ description
+ "Identifier of network access.";
+ }
+ leaf remote-carrier-name {
+ when "derived-from-or-self(../../../site-vpn-flavor,"
+ + "'l2vpn-svc:site-vpn-flavor-nni')" {
+ description
+ "Relevant when the site's VPN flavor is
+ 'site-vpn-flavor-nni'.";
+ }
+ type leafref {
+ path "/l2vpn-svc/vpn-profiles/"
+ + "valid-provider-identifiers"
+ + "/remote-carrier-identifier";
+ }
+ description
+ "Remote carrier name. The 'remote-carrier-name'
+ parameter must be configured only when
+ 'site-vpn-flavor' is set to 'site-vpn-flavor-nni'.
+ If it is not set, it indicates that the customer
+ does not know the remote carrier's name
+ beforehand.";
+ }
+ leaf type {
+ type identityref {
+ base site-network-access-type;
+ }
+ default "point-to-point";
+ description
+
+
+
+Wen, et al. Standards Track [Page 127]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Describes the type of connection, e.g.,
+ point-to-point or multipoint.";
+ }
+ choice location-flavor {
+ case location {
+ when "derived-from-or-self(../../management/type, "
+ + "'l2vpn-svc:customer-managed')" {
+ description
+ "Applicable only for a customer-managed device.";
+ }
+ leaf location-reference {
+ type leafref {
+ path "../../../locations/location/location-id";
+ }
+ description
+ "Location of the site-network-access.";
+ }
+ }
+ case device {
+ when "derived-from-or-self(../../management/type, "
+ + "'l2vpn-svc:provider-managed') or "
+ + "derived-from-or-self(../../management/type, "
+ + "'l2vpn-svc:co-managed')" {
+ description
+ "Applicable only for a provider-managed
+ or co-managed device.";
+ }
+ leaf device-reference {
+ type leafref {
+ path "../../../devices/device/device-id";
+ }
+ description
+ "Identifier of the CE to use.";
+ }
+ }
+ mandatory true;
+ description
+ "Choice of how to describe the site's location.";
+ }
+ container access-diversity {
+ if-feature "site-diversity";
+ container groups {
+ list group {
+ key "group-id";
+ leaf group-id {
+ type string;
+ description
+ "Group-id to which the site belongs.";
+
+
+
+Wen, et al. Standards Track [Page 128]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+ description
+ "List of group-ids.";
+ }
+ description
+ "Groups to which the site or site-network-access
+ belongs.";
+ }
+ container constraints {
+ list constraint {
+ key "constraint-type";
+ leaf constraint-type {
+ type identityref {
+ base placement-diversity;
+ }
+ description
+ "The type of diversity constraint.";
+ }
+ container target {
+ choice target-flavor {
+ default "id";
+ case id {
+ list group {
+ key "group-id";
+ leaf group-id {
+ type string;
+ description
+ "The constraint will apply against this
+ particular group-id.";
+ }
+ description
+ "List of groups.";
+ }
+ }
+ case all-accesses {
+ leaf all-other-accesses {
+ type empty;
+ description
+ "The constraint will apply against all other
+ site network accesses of this site.";
+ }
+ }
+ case all-groups {
+ leaf all-other-groups {
+ type empty;
+ description
+ "The constraint will apply against all other
+ groups the customer is managing.";
+
+
+
+Wen, et al. Standards Track [Page 129]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+ }
+ description
+ "Choice for the group definition.";
+ }
+ description
+ "The constraint will apply against
+ this list of groups.";
+ }
+ description
+ "List of constraints.";
+ }
+ description
+ "Constraints for placing this site network access.";
+ }
+ description
+ "Diversity parameters.";
+ }
+ container bearer {
+ container requested-type {
+ if-feature "requested-type";
+ leaf type {
+ type string;
+ description
+ "Type of requested bearer: Ethernet, ATM, Frame
+ Relay, IP Layer 2 transport, Frame Relay Data
+ Link Connection Identifier (DLCI), SONET/SDH,
+ PPP.";
+ }
+ leaf strict {
+ type boolean;
+ default "false";
+ description
+ "Defines whether the requested type is a preference
+ or a strict requirement.";
+ }
+ description
+ "Container for requested types.";
+ }
+ leaf always-on {
+ if-feature "always-on";
+ type boolean;
+ default "true";
+ description
+ "Request for an 'always-on' access type.
+ For example, this could mean no dial-in access
+ type.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 130]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ leaf bearer-reference {
+ if-feature "bearer-reference";
+ type string;
+ description
+ "An internal reference for the SP.";
+ }
+ description
+ "Bearer-specific parameters. To be augmented.";
+ }
+ container connection {
+ leaf encapsulation-type {
+ type identityref {
+ base encapsulation-type;
+ }
+ default "ethernet";
+ description
+ "Encapsulation type. By default, the
+ encapsulation type is set to 'ethernet'.";
+ }
+ leaf eth-inf-type {
+ type identityref {
+ base eth-inf-type;
+ }
+ default "untagged";
+ description
+ "Ethernet interface type. By default, the
+ Ethernet interface type is set to 'untagged'.";
+ }
+ container tagged-interface {
+ leaf type {
+ type identityref {
+ base tagged-inf-type;
+ }
+ default "priority-tagged";
+ description
+ "Tagged interface type. By default,
+ the type of the tagged interface is
+ 'priority-tagged'.";
+ }
+ container dot1q-vlan-tagged {
+ when "derived-from-or-self(../type, "
+ + "'l2vpn-svc:dot1q')" {
+ description
+ "Only applies when the type of the tagged
+ interface is 'dot1q'.";
+ }
+ if-feature "dot1q";
+ leaf tg-type {
+
+
+
+Wen, et al. Standards Track [Page 131]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ type identityref {
+ base tag-type;
+ }
+ default "c-vlan";
+ description
+ "Tag type. By default, the tag type is
+ 'c-vlan'.";
+ }
+ leaf cvlan-id {
+ type uint16;
+ mandatory true;
+ description
+ "VLAN identifier.";
+ }
+ description
+ "Tagged interface.";
+ }
+ container priority-tagged {
+ when "derived-from-or-self(../type, "
+ + "'l2vpn-svc:priority-tagged')" {
+ description
+ "Only applies when the type of the tagged
+ interface is 'priority-tagged'.";
+ }
+ leaf tag-type {
+ type identityref {
+ base tag-type;
+ }
+ default "c-vlan";
+ description
+ "Tag type. By default, the tag type is
+ 'c-vlan'.";
+ }
+ description
+ "Priority tagged.";
+ }
+ container qinq {
+ when "derived-from-or-self(../type, "
+ + "'l2vpn-svc:qinq')" {
+ description
+ "Only applies when the type of the tagged
+ interface is 'qinq'.";
+ }
+ if-feature "qinq";
+ leaf tag-type {
+ type identityref {
+ base tag-type;
+ }
+
+
+
+Wen, et al. Standards Track [Page 132]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ default "c-s-vlan";
+ description
+ "Tag type. By default, the tag type is
+ 'c-s-vlan'.";
+ }
+ leaf svlan-id {
+ type uint16;
+ mandatory true;
+ description
+ "SVLAN identifier.";
+ }
+ leaf cvlan-id {
+ type uint16;
+ mandatory true;
+ description
+ "CVLAN identifier.";
+ }
+ description
+ "QinQ.";
+ }
+ container qinany {
+ when "derived-from-or-self(../type, "
+ + "'l2vpn-svc:qinany')" {
+ description
+ "Only applies when the type of the tagged
+ interface is 'qinany'.";
+ }
+ if-feature "qinany";
+ leaf tag-type {
+ type identityref {
+ base tag-type;
+ }
+ default "s-vlan";
+ description
+ "Tag type. By default, the tag type is
+ 's-vlan'.";
+ }
+ leaf svlan-id {
+ type uint16;
+ mandatory true;
+ description
+ "SVLAN ID.";
+ }
+ description
+ "Container for QinAny.";
+ }
+ container vxlan {
+ when "derived-from-or-self(../type, "
+
+
+
+Wen, et al. Standards Track [Page 133]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ + "'l2vpn-svc:vxlan')" {
+ description
+ "Only applies when the type of the tagged
+ interface is 'vxlan'.";
+ }
+ if-feature "vxlan";
+ leaf vni-id {
+ type uint32;
+ mandatory true;
+ description
+ "VXLAN Network Identifier (VNI).";
+ }
+ leaf peer-mode {
+ type identityref {
+ base vxlan-peer-mode;
+ }
+ default "static-mode";
+ description
+ "Specifies the VXLAN access mode. By default,
+ the peer mode is set to 'static-mode'.";
+ }
+ list peer-list {
+ key "peer-ip";
+ leaf peer-ip {
+ type inet:ip-address;
+ description
+ "Peer IP.";
+ }
+ description
+ "List of peer IP addresses.";
+ }
+ description
+ "QinQ.";
+ }
+ description
+ "Container for tagged interfaces.";
+ }
+ container untagged-interface {
+ leaf speed {
+ type uint32;
+ units "mbps";
+ default "10";
+ description
+ "Port speed.";
+ }
+ leaf mode {
+ type neg-mode;
+ default "auto-neg";
+
+
+
+Wen, et al. Standards Track [Page 134]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ description
+ "Negotiation mode.";
+ }
+ leaf phy-mtu {
+ type uint32;
+ units "bytes";
+ description
+ "PHY MTU.";
+ }
+ leaf lldp {
+ type boolean;
+ default "false";
+ description
+ "LLDP. Indicates that LLDP is supported.";
+ }
+ container oam-802.3ah-link {
+ if-feature "oam-3ah";
+ leaf enabled {
+ type boolean;
+ default "false";
+ description
+ "Indicates whether or not to support
+ OAM 802.3ah links.";
+ }
+ description
+ "Container for OAM 802.3ah links.";
+ }
+ leaf uni-loop-prevention {
+ type boolean;
+ default "false";
+ description
+ "If this leaf is set to 'true', then the port
+ automatically goes down when a physical
+ loopback is detected.";
+ }
+ description
+ "Container of untagged interface attribute
+ configurations.";
+ }
+ container lag-interfaces {
+ if-feature "lag-interface";
+ list lag-interface {
+ key "index";
+ leaf index {
+ type string;
+ description
+ "LAG interface index.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 135]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ container lacp {
+ if-feature "lacp";
+ leaf enabled {
+ type boolean;
+ default "false";
+ description
+ "LACP on/off. By default, LACP is disabled.";
+ }
+ leaf mode {
+ type neg-mode;
+ description
+ "LACP mode. LACP modes have active mode and
+ passive mode ('false'). 'Active mode' means
+ initiating the auto-speed negotiation and
+ trying to form an Ethernet channel with the
+ other end. 'Passive mode' means not initiating
+ the negotiation but responding to LACP packets
+ initiated by the other end (e.g., full duplex
+ or half duplex).";
+ }
+ leaf speed {
+ type uint32;
+ units "mbps";
+ default "10";
+ description
+ "LACP speed. By default, the LACP speed is 10
+ Mbps.";
+ }
+ leaf mini-link-num {
+ type uint32;
+ description
+ "Defines the minimum number of links that must
+ be active before the aggregating link is put
+ into service.";
+ }
+ leaf system-priority {
+ type uint16;
+ default "32768";
+ description
+ "Indicates the LACP priority for the system.
+ The range is from 0 to 65535.
+ The default is 32768.";
+ }
+ container micro-bfd {
+ if-feature "micro-bfd";
+ leaf enabled {
+ type enumeration {
+ enum on {
+
+
+
+Wen, et al. Standards Track [Page 136]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ description
+ "Micro-bfd on.";
+ }
+ enum off {
+ description
+ "Micro-bfd off.";
+ }
+ }
+ default "off";
+ description
+ "Micro-BFD on/off. By default, micro-BFD
+ is set to 'off'.";
+ }
+ leaf interval {
+ type uint32;
+ units "milliseconds";
+ description
+ "BFD interval.";
+ }
+ leaf hold-timer {
+ type uint32;
+ units "milliseconds";
+ description
+ "BFD hold timer.";
+ }
+ description
+ "Container of micro-BFD configurations.";
+ }
+ container bfd {
+ if-feature "bfd";
+ leaf enabled {
+ type boolean;
+ default "false";
+ description
+ "BFD activation. By default, BFD is not
+ activated.";
+ }
+ choice holdtime {
+ default "fixed";
+ case profile {
+ leaf profile-name {
+ type leafref {
+ path "/l2vpn-svc/vpn-profiles/"
+ + "valid-provider-identifiers"
+ + "/bfd-profile-identifier";
+ }
+ description
+ "SP well-known profile.";
+
+
+
+Wen, et al. Standards Track [Page 137]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+ description
+ "SP well-known profile.";
+ }
+ case fixed {
+ leaf fixed-value {
+ type uint32;
+ units "milliseconds";
+ description
+ "Expected hold time expressed in
+ milliseconds.";
+ }
+ }
+ description
+ "Choice for the hold-time flavor.";
+ }
+ description
+ "Container for BFD.";
+ }
+ container member-links {
+ list member-link {
+ key "name";
+ leaf name {
+ type string;
+ description
+ "Member link name.";
+ }
+ leaf speed {
+ type uint32;
+ units "mbps";
+ default "10";
+ description
+ "Port speed.";
+ }
+ leaf mode {
+ type neg-mode;
+ default "auto-neg";
+ description
+ "Negotiation mode.";
+ }
+ leaf link-mtu {
+ type uint32;
+ units "bytes";
+ description
+ "Link MTU size.";
+ }
+ container oam-802.3ah-link {
+ if-feature "oam-3ah";
+
+
+
+Wen, et al. Standards Track [Page 138]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ leaf enabled {
+ type boolean;
+ default "false";
+ description
+ "Indicates whether OAM 802.3ah links are
+ supported.";
+ }
+ description
+ "Container for OAM 802.3ah links.";
+ }
+ description
+ "Member link.";
+ }
+ description
+ "Container of the member link list.";
+ }
+ leaf flow-control {
+ type boolean;
+ default "false";
+ description
+ "Flow control. Indicates whether flow control
+ is supported.";
+ }
+ leaf lldp {
+ type boolean;
+ default "false";
+ description
+ "LLDP. Indicates whether LLDP is supported.";
+ }
+ description
+ "LACP.";
+ }
+ description
+ "List of LAG interfaces.";
+ }
+ description
+ "Container of LAG interface attribute
+ configurations.";
+ }
+ list cvlan-id-to-svc-map {
+ key "svc-id";
+ leaf svc-id {
+ type leafref {
+ path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
+ }
+ description
+ "VPN service identifier.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 139]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ list cvlan-id {
+ key "vid";
+ leaf vid {
+ type uint16;
+ description
+ "CVLAN ID.";
+ }
+ description
+ "List of CVLAN-ID-to-SVC-map configurations.";
+ }
+ description
+ "List of CVLAN-ID-to-L2VPN-service-map
+ configurations.";
+ }
+ container l2cp-control {
+ if-feature "l2cp-control";
+ leaf stp-rstp-mstp {
+ type control-mode;
+ description
+ "STP / Rapid STP (RSTP) / Multiple STP (MSTP)
+ protocol type applicable to all sites.";
+ }
+ leaf pause {
+ type control-mode;
+ description
+ "Pause protocol type applicable to all sites.";
+ }
+ leaf lacp-lamp {
+ type control-mode;
+ description
+ "LACP / Link Aggregation Marker Protocol (LAMP).";
+ }
+ leaf link-oam {
+ type control-mode;
+ description
+ "Link OAM.";
+ }
+ leaf esmc {
+ type control-mode;
+ description
+ "Ethernet Synchronization Messaging Channel
+ (ESMC).";
+ }
+ leaf l2cp-802.1x {
+ type control-mode;
+ description
+ "IEEE 802.1x.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 140]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ leaf e-lmi {
+ type control-mode;
+ description
+ "E-LMI.";
+ }
+ leaf lldp {
+ type boolean;
+ description
+ "LLDP protocol type applicable to all sites.";
+ }
+ leaf ptp-peer-delay {
+ type control-mode;
+ description
+ "Precision Time Protocol (PTP) peer delay.";
+ }
+ leaf garp-mrp {
+ type control-mode;
+ description
+ "GARP/MRP.";
+ }
+ description
+ "Container of L2CP control configurations.";
+ }
+ container oam {
+ if-feature "ethernet-oam";
+ leaf md-name {
+ type string;
+ mandatory true;
+ description
+ "Maintenance domain name.";
+ }
+ leaf md-level {
+ type uint16 {
+ range "0..255";
+ }
+ mandatory true;
+ description
+ "Maintenance domain level. The level may be
+ restricted in certain protocols (e.g.,
+ protocols in Layer 0 to Layer 7).";
+ }
+ list cfm-8021-ag {
+ if-feature "cfm";
+ key "maid";
+ leaf maid {
+ type string;
+ mandatory true;
+ description
+
+
+
+Wen, et al. Standards Track [Page 141]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Identifies a Maintenance Association (MA).";
+ }
+ leaf mep-id {
+ type uint32;
+ description
+ "Local Maintenance Entity Group End Point (MEP)
+ ID. The non-existence of this leaf means
+ that no defects are to be reported.";
+ }
+ leaf mep-level {
+ type uint32;
+ description
+ "Defines the MEP level. The non-existence of this
+ leaf means that no defects are to be reported.";
+ }
+ leaf mep-up-down {
+ type enumeration {
+ enum up {
+ description
+ "MEP up.";
+ }
+ enum down {
+ description
+ "MEP down.";
+ }
+ }
+ default "up";
+ description
+ "MEP up/down. By default, MEP up is used.
+ The non-existence of this leaf means that
+ no defects are to be reported.";
+ }
+ leaf remote-mep-id {
+ type uint32;
+ description
+ "Remote MEP ID. The non-existence of this leaf
+ means that no defects are to be reported.";
+ }
+ leaf cos-for-cfm-pdus {
+ type uint32;
+ description
+ "CoS for CFM PDUs. The non-existence of this leaf
+ means that no defects are to be reported.";
+ }
+ leaf ccm-interval {
+ type uint32;
+ units "milliseconds";
+ default "10000";
+
+
+
+Wen, et al. Standards Track [Page 142]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ description
+ "CCM interval. By default, the CCM interval is
+ 10,000 milliseconds (10 seconds).";
+ }
+ leaf ccm-holdtime {
+ type uint32;
+ units "milliseconds";
+ default "35000";
+ description
+ "CCM hold time. By default, the CCM hold time
+ is 3.5 times the CCM interval.";
+ }
+ leaf alarm-priority-defect {
+ type identityref {
+ base fault-alarm-defect-type;
+ }
+ default "remote-invalid-ccm";
+ description
+ "The lowest-priority defect that is
+ allowed to generate a fault alarm. By default,
+ 'fault-alarm-defect-type' is set to
+ 'remote-invalid-ccm'. The non-existence of
+ this leaf means that no defects are
+ to be reported.";
+ }
+ leaf ccm-p-bits-pri {
+ type ccm-priority-type;
+ description
+ "The priority parameter for CCMs transmitted by
+ the MEP. The non-existence of this leaf means
+ that no defects are to be reported.";
+ }
+ description
+ "List of 802.1ag CFM attributes.";
+ }
+ list y-1731 {
+ if-feature "y-1731";
+ key "maid";
+ leaf maid {
+ type string;
+ mandatory true;
+ description
+ "Identifies an MA.";
+ }
+ leaf mep-id {
+ type uint32;
+ description
+ "Local MEP ID. The non-existence of this leaf
+
+
+
+Wen, et al. Standards Track [Page 143]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ means that no measurements are to be reported.";
+ }
+ leaf type {
+ type identityref {
+ base pm-type;
+ }
+ default "delay";
+ description
+ "Performance-monitoring types. By default, the
+ performance-monitoring type is set to 'delay'.
+ The non-existence of this leaf means that no
+ measurements are to be reported.";
+ }
+ leaf remote-mep-id {
+ type uint32;
+ description
+ "Remote MEP ID. The non-existence of this
+ leaf means that no measurements are to be
+ reported.";
+ }
+ leaf message-period {
+ type uint32;
+ units "milliseconds";
+ default "10000";
+ description
+ "Defines the interval between Y.1731
+ performance-monitoring messages. The message
+ period is expressed in milliseconds.";
+ }
+ leaf measurement-interval {
+ type uint32;
+ units "seconds";
+ description
+ "Specifies the measurement interval for
+ statistics. The measurement interval is
+ expressed in seconds.";
+ }
+ leaf cos {
+ type uint32;
+ description
+ "CoS. The non-existence of this leaf means that
+ no measurements are to be reported.";
+ }
+ leaf loss-measurement {
+ type boolean;
+ default "false";
+ description
+ "Indicates whether or not to enable loss
+
+
+
+Wen, et al. Standards Track [Page 144]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ measurement. By default, loss
+ measurement is not enabled.";
+ }
+ leaf synthetic-loss-measurement {
+ type boolean;
+ default "false";
+ description
+ "Indicates whether or not to enable synthetic loss
+ measurement. By default, synthetic loss
+ measurement is not enabled.";
+ }
+ container delay-measurement {
+ leaf enable-dm {
+ type boolean;
+ default "false";
+ description
+ "Indicates whether or not to enable delay
+ measurement. By default, delay measurement
+ is not enabled.";
+ }
+ leaf two-way {
+ type boolean;
+ default "false";
+ description
+ "Indicates whether delay measurement is two-way
+ ('true') or one-way ('false'). By default,
+ one-way measurement is enabled.";
+ }
+ description
+ "Container for delay measurement.";
+ }
+ leaf frame-size {
+ type uint32;
+ units "bytes";
+ description
+ "Frame size. The non-existence of this leaf
+ means that no measurements are to be reported.";
+ }
+ leaf session-type {
+ type enumeration {
+ enum proactive {
+ description
+ "Proactive mode.";
+ }
+ enum on-demand {
+ description
+ "On-demand mode.";
+ }
+
+
+
+Wen, et al. Standards Track [Page 145]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+ default "on-demand";
+ description
+ "Session type. By default, the session type
+ is 'on-demand'. The non-existence of this
+ leaf means that no measurements are to be
+ reported.";
+ }
+ description
+ "List of configured Y-1731 instances.";
+ }
+ description
+ "Container for Ethernet Service OAM.";
+ }
+ description
+ "Container for connection requirements.";
+ }
+ container availability {
+ leaf access-priority {
+ type uint32;
+ default "100";
+ description
+ "Access priority. The higher the access-priority
+ value, the higher the preference will be for the
+ access in question.";
+ }
+ choice redundancy-mode {
+ case single-active {
+ leaf single-active {
+ type empty;
+ description
+ "Single-active mode.";
+ }
+ description
+ "In single-active mode, only one node forwards
+ traffic to and from the Ethernet segment.";
+ }
+ case all-active {
+ leaf all-active {
+ type empty;
+ description
+ "All-active mode.";
+ }
+ description
+ "In all-active mode, all nodes can forward
+ traffic.";
+ }
+ description
+
+
+
+Wen, et al. Standards Track [Page 146]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ "Redundancy mode choice.";
+ }
+ description
+ "Container of available optional configurations.";
+ }
+ container vpn-attachment {
+ choice attachment-flavor {
+ case vpn-id {
+ leaf vpn-id {
+ type leafref {
+ path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
+ }
+ description
+ "Reference to an L2VPN. Referencing a vpn-id
+ provides an easy way to attach a particular
+ logical access to a VPN. In this case,
+ the vpn-id must be configured.";
+ }
+ leaf site-role {
+ type identityref {
+ base site-role;
+ }
+ default "any-to-any-role";
+ description
+ "Role of the site in the L2VPN. 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.";
+ }
+ }
+ case vpn-policy-id {
+ leaf vpn-policy-id {
+ type leafref {
+ path "../../../../vpn-policies/vpn-policy/"
+ + "vpn-policy-id";
+ }
+ description
+ "Reference to a VPN policy.";
+ }
+ }
+ mandatory true;
+ description
+ "Choice for the VPN attachment flavor.";
+ }
+ description
+ "Defines the VPN attachment of a site.";
+ }
+ container service {
+
+
+
+Wen, et al. Standards Track [Page 147]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ container svc-bandwidth {
+ if-feature "input-bw";
+ list bandwidth {
+ key "direction type";
+ leaf direction {
+ type identityref {
+ base bw-direction;
+ }
+ description
+ "Indicates the bandwidth direction. It can be
+ the bandwidth download direction from the SP to
+ the site or the bandwidth upload direction from
+ the site to the SP.";
+ }
+ leaf type {
+ type identityref {
+ base bw-type;
+ }
+ description
+ "Bandwidth type. By default, the bandwidth type
+ is set to 'bw-per-cos'.";
+ }
+ leaf cos-id {
+ when "derived-from-or-self(../type, "
+ + "'l2vpn-svc:bw-per-cos')" {
+ description
+ "Relevant when the bandwidth type is set to
+ 'bw-per-cos'.";
+ }
+ type uint8;
+ description
+ "Identifier of the CoS, indicated by DSCP or a
+ CE-VLAN CoS (802.1p) value in the service frame.
+ If the bandwidth type is set to 'bw-per-cos',
+ the CoS ID MUST also be specified.";
+ }
+ leaf vpn-id {
+ when "derived-from-or-self(../type, "
+ + "'l2vpn-svc:bw-per-svc')" {
+ description
+ "Relevant when the bandwidth type is
+ set as bandwidth per VPN service.";
+ }
+ type svc-id;
+ description
+ "Identifies the target VPN. If the bandwidth
+ type is set as bandwidth per VPN service, the
+ vpn-id MUST be specified.";
+
+
+
+Wen, et al. Standards Track [Page 148]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+ leaf cir {
+ type uint64;
+ units "bps";
+ mandatory true;
+ description
+ "Committed Information Rate. The maximum number
+ of bits that a port can receive or send over
+ an interface in one second.";
+ }
+ leaf cbs {
+ type uint64;
+ units "bps";
+ mandatory true;
+ description
+ "Committed Burst Size (CBS). Controls the bursty
+ nature of the traffic. Traffic that does not
+ use the configured Committed Information Rate
+ (CIR) accumulates credits until the credits
+ reach the configured CBS.";
+ }
+ leaf eir {
+ type uint64;
+ units "bps";
+ description
+ "Excess Information Rate (EIR), i.e., excess frame
+ delivery allowed that is not subject to an SLA.
+ The traffic rate can be limited by the EIR.";
+ }
+ leaf ebs {
+ type uint64;
+ units "bps";
+ description
+ "Excess Burst Size (EBS). The bandwidth available
+ for burst traffic from the EBS is subject to the
+ amount of bandwidth that is accumulated during
+ periods when traffic allocated by the EIR
+ policy is not used.";
+ }
+ leaf pir {
+ type uint64;
+ units "bps";
+ description
+ "Peak Information Rate, i.e., maximum frame
+ delivery allowed. It is equal to or less
+ than the sum of the CIR and the EIR.";
+ }
+ leaf pbs {
+
+
+
+Wen, et al. Standards Track [Page 149]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ type uint64;
+ units "bps";
+ description
+ "Peak Burst Size. It is measured in bytes per
+ second.";
+ }
+ description
+ "List of bandwidth values (e.g., per CoS,
+ per vpn-id).";
+ }
+ description
+ "From the customer site's perspective, the service
+ input/output bandwidth of the connection or
+ download/upload bandwidth from the SP/site
+ to the site/SP.";
+ }
+ leaf svc-mtu {
+ type uint16;
+ units "bytes";
+ mandatory true;
+ description
+ "SVC MTU. It is also known as the maximum
+ transmission unit or maximum frame size. When
+ a frame is larger than the MTU, it is broken
+ down, or fragmented, into smaller pieces by
+ the network protocol to accommodate the MTU
+ of the network. If CsC is enabled,
+ the requested svc-mtu leaf will refer to the
+ MPLS MTU and not to the link MTU.";
+ }
+ uses site-service-qos-profile;
+ uses site-service-mpls;
+ description
+ "Container for services.";
+ }
+ uses site-bum;
+ uses site-mac-loop-prevention;
+ uses site-acl;
+ container mac-addr-limit {
+ if-feature "mac-addr-limit";
+ leaf limit-number {
+ type uint16;
+ default "2";
+ description
+ "Maximum number of MAC addresses learned from
+ the subscriber for a single service instance.
+ The default allowed maximum number of MAC
+ addresses is 2.";
+
+
+
+Wen, et al. Standards Track [Page 150]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ }
+ leaf time-interval {
+ type uint32;
+ units "seconds";
+ default "300";
+ description
+ "The aging time of the MAC address. By default,
+ the aging time is set to 300 seconds.";
+ }
+ leaf action {
+ type identityref {
+ base mac-action;
+ }
+ default "warning";
+ description
+ "Specifies the action taken when the upper limit is
+ exceeded: drop the packet, flood the packet, or
+ simply send a warning log message. By default,
+ the action is set to 'warning'.";
+ }
+ description
+ "Container of MAC address limit configurations.";
+ }
+ description
+ "List of site network accesses.";
+ }
+ description
+ "Container of port configurations.";
+ }
+ description
+ "List of sites.";
+ }
+ description
+ "Container of site configurations.";
+ }
+ description
+ "Container for L2VPN services.";
+ }
+}
+
+<CODE ENDS>
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 151]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+9. Security Considerations
+
+ The YANG module specified in this document defines a schema for data
+ that is designed to be accessed via network management protocols such
+ as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
+ is the secure transport layer, and the mandatory-to-implement secure
+ transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
+ is HTTPS, and the mandatory-to-implement secure transport is TLS
+ [RFC8446].
+
+ The NETCONF access control model [RFC8341] provides the means to
+ restrict access for particular NETCONF or RESTCONF users to a
+ preconfigured subset of all available NETCONF or RESTCONF protocol
+ operations and content.
+
+ There are a number of data nodes defined in this YANG module that are
+ writable/creatable/deletable (i.e., config true, which is the
+ default). These data nodes may be considered sensitive or vulnerable
+ in some network environments. Write operations (e.g., edit-config)
+ to these data nodes without proper protection can have a negative
+ effect on network operations. These are the subtrees and data nodes
+ and their sensitivity/vulnerability:
+
+ o /l2vpn-svc/vpn-services/vpn-service
+
+ The entries in the list above include all of the VPN service
+ configurations to which the customer subscribes and will use to
+ indirectly create or modify the PE and CE device configurations.
+ Unexpected changes to these entries could lead to service
+ disruptions and/or network misbehavior.
+
+ o /l2vpn-svc/sites/site
+
+ The entries in the list above include the customer site
+ configurations. As noted in the previous paragraph, unexpected
+ changes to these entries could lead to service disruptions and/or
+ network misbehavior.
+
+ Some of the readable data nodes in this YANG module may be considered
+ sensitive or vulnerable in some network environments. It is thus
+ important to control read access (e.g., via get, get-config, or
+ notification) to these data nodes. These are the subtrees and data
+ nodes and their sensitivity/vulnerability:
+
+ o /l2vpn-svc/vpn-services/vpn-service
+
+ o /l2vpn-svc/sites/site
+
+
+
+
+Wen, et al. Standards Track [Page 152]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ The entries in the lists above include customer-proprietary or
+ confidential information, e.g., customer name, site location,
+ services to which the customer subscribes.
+
+ When an SP collaborates with multiple customers, it has to ensure
+ that a given customer can only view and modify its (the customer's)
+ own service information.
+
+ The data model defines some security parameters that can be extended
+ via augmentation as part of the customer service request; those
+ parameters are described in Sections 5.12 and 5.13.
+
+10. IANA Considerations
+
+ IANA has assigned a new URI from the "IETF XML Registry" [RFC3688].
+
+ URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
+ Registrant Contact: The IESG
+ XML: N/A; the requested URI is an XML namespace
+
+ IANA has assigned a new YANG module name in the "YANG Module Names"
+ registry [RFC6020].
+
+ name: ietf-l2vpn-svc
+ namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
+ prefix: l2vpn-svc
+ reference: RFC 8466
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+ DOI 10.17487/RFC3688, January 2004,
+ <https://www.rfc-editor.org/info/rfc3688>.
+
+ [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+ Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
+ 2006, <https://www.rfc-editor.org/info/rfc4364>.
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 153]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
+ LAN Service (VPLS) Using BGP for Auto-Discovery and
+ Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
+ <https://www.rfc-editor.org/info/rfc4761>.
+
+ [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+ the Network Configuration Protocol (NETCONF)", RFC 6020,
+ DOI 10.17487/RFC6020, October 2010,
+ <https://www.rfc-editor.org/info/rfc6020>.
+
+ [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
+ Aissaoui, "Segmented Pseudowire", RFC 6073,
+ DOI 10.17487/RFC6073, January 2011,
+ <https://www.rfc-editor.org/info/rfc6073>.
+
+ [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
+ "Provisioning, Auto-Discovery, and Signaling in Layer 2
+ Virtual Private Networks (L2VPNs)", RFC 6074,
+ DOI 10.17487/RFC6074, January 2011,
+ <https://www.rfc-editor.org/info/rfc6074>.
+
+ [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+ and A. Bierman, Ed., "Network Configuration Protocol
+ (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+ <https://www.rfc-editor.org/info/rfc6241>.
+
+ [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
+ Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
+ <https://www.rfc-editor.org/info/rfc6242>.
+
+ [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
+ RFC 6991, DOI 10.17487/RFC6991, July 2013,
+ <https://www.rfc-editor.org/info/rfc6991>.
+
+ [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
+ Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
+ Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
+ 2015, <https://www.rfc-editor.org/info/rfc7432>.
+
+ [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
+ RFC 7950, DOI 10.17487/RFC7950, August 2016,
+ <https://www.rfc-editor.org/info/rfc7950>.
+
+ [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+ Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
+ <https://www.rfc-editor.org/info/rfc8040>.
+
+
+
+
+
+Wen, et al. Standards Track [Page 154]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
+ Rabadan, "Virtual Private Wire Service Support in Ethernet
+ VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
+ <https://www.rfc-editor.org/info/rfc8214>.
+
+ [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
+ Access Control Model", STD 91, RFC 8341,
+ DOI 10.17487/RFC8341, March 2018,
+ <https://www.rfc-editor.org/info/rfc8341>.
+
+ [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
+ and R. Wilton, "Network Management Datastore Architecture
+ (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
+ <https://www.rfc-editor.org/info/rfc8342>.
+
+ [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
+ Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+ <https://www.rfc-editor.org/info/rfc8446>.
+
+ [W3C.REC-xml-20081126]
+ Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
+ F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
+ Edition)", World Wide Web Consortium Recommendation
+ REC-xml-20081126, November 2008,
+ <https://www.w3.org/TR/2008/REC-xml-20081126>.
+
+11.2. Informative References
+
+ [EVPN-YANG]
+ Brissette, P., Ed., Shah, H., Ed., Chen, I., Ed., Hussain,
+ I., Ed., Tiruveedhula, K., Ed., and J. Rabadan, Ed., "Yang
+ Data Model for EVPN", Work in Progress, draft-ietf-bess-
+ evpn-yang-05, February 2018.
+
+ [IEEE-802-1ag]
+ IEEE, "802.1ag - 2007 - IEEE Standard for Local and
+ Metropolitan Area Networks - Virtual Bridged Local Area
+ Networks Amendment 5: Connectivity Fault Management",
+ DOI 10.1109/IEEESTD.2007.4431836.
+
+ [IEEE-802-1D]
+ IEEE, "802.1D-2004 - IEEE Standard for Local and
+ metropolitan area networks: Media Access Control (MAC)
+ Bridges", DOI 10.1109/IEEESTD.2004.94569.
+
+
+
+Wen, et al. Standards Track [Page 155]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ [IEEE-802-1Q]
+ IEEE, "802.1Q - 2014 - IEEE Standard for Local and
+ metropolitan area networks--Bridges and Bridged Networks",
+ DOI 10.1109/IEEESTD.2014.6991462.
+
+ [IEEE-802-3ah]
+ IEEE, "802.3ah - 2004 - IEEE Standard for Information
+ technology-- Local and metropolitan area networks-- Part
+ 3: CSMA/CD Access Method and Physical Layer Specifications
+ Amendment: Media Access Control Parameters, Physical
+ Layers, and Management Parameters for Subscriber Access
+ Networks", DOI 10.1109/IEEESTD.2004.94617.
+
+ [ITU-T-Y-1731]
+ International Telecommunication Union, "Operations,
+ administration and maintenance (OAM) functions and
+ mechanisms for Ethernet-based networks",
+ ITU-T Recommendation Y.1731, August 2015,
+ <https://www.itu.int/rec/T-REC-Y.1731/en>.
+
+ [MEF-6] Metro Ethernet Forum, "Ethernet Services Definitions -
+ Phase 2", April 2008, <https://mef.net/PDF_Documents/
+ technical-specifications/MEF6-1.pdf>.
+
+ [MPLS-L2VPN-YANG]
+ Shah, H., Ed., Brissette, P., Ed., Chen, I., Ed., Hussain,
+ I., Ed., Wen, B., Ed., and K. Tiruveedhula, Ed., "YANG
+ Data Model for MPLS-based L2VPN", Work in Progress,
+ draft-ietf-bess-l2vpn-yang-08, February 2018.
+
+ [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
+ Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,
+ <https://www.rfc-editor.org/info/rfc4119>.
+
+ [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
+ Virtual Private Networks Using BGP for Auto-Discovery and
+ Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
+ <https://www.rfc-editor.org/info/rfc6624>.
+
+ [RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed.,
+ Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional
+ Forwarding Detection (BFD) on Link Aggregation Group (LAG)
+ Interfaces", RFC 7130, DOI 10.17487/RFC7130, February
+ 2014, <https://www.rfc-editor.org/info/rfc7130>.
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 156]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+ [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
+ Henderickx, W., and A. Isaac, "Requirements for Ethernet
+ VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014,
+ <https://www.rfc-editor.org/info/rfc7209>.
+
+ [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
+ L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
+ eXtensible Local Area Network (VXLAN): A Framework for
+ Overlaying Virtualized Layer 2 Networks over Layer 3
+ Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
+ <https://www.rfc-editor.org/info/rfc7348>.
+
+ [RFC7436] Shah, H., Rosen, E., Le Faucheur, F., and G. Heron,
+ "IP-Only LAN Service (IPLS)", RFC 7436,
+ DOI 10.17487/RFC7436, January 2015,
+ <https://www.rfc-editor.org/info/rfc7436>.
+
+ [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
+ Classification", RFC 8199, DOI 10.17487/RFC8199, July
+ 2017, <https://www.rfc-editor.org/info/rfc8199>.
+
+ [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
+ "YANG Data Model for L3VPN Service Delivery", RFC 8299,
+ DOI 10.17487/RFC8299, January 2018,
+ <https://www.rfc-editor.org/info/rfc8299>.
+
+ [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
+ Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
+ <https://www.rfc-editor.org/info/rfc8309>.
+
+ [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
+ BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
+ <https://www.rfc-editor.org/info/rfc8340>.
+
+Acknowledgements
+
+ Thanks to Qin Wu and Adrian Farrel for facilitating work on the
+ initial draft revisions of this document. Thanks to Zonghe Huang,
+ Wei Deng, and Xiaoling Song for their review of this document.
+
+ Special thanks to Jan Lindblad for his careful review of the YANG.
+
+ This document has drawn on the work of the L3SM Working Group as
+ provided in [RFC8299].
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 157]
+
+RFC 8466 L2VPN Service Model (L2SM) October 2018
+
+
+Authors' Addresses
+
+ Bin Wen
+ Comcast
+
+ Email: bin_wen@comcast.com
+
+
+ Giuseppe Fioccola (editor)
+ Telecom Italia
+
+ Email: giuseppe.fioccola@tim.it
+
+
+ Chongfeng Xie
+ China Telecom
+
+ Email: xiechf.bri@chinatelecom.cn
+
+
+ Luay Jalil
+ Verizon
+
+ Email: luay.jalil@verizon.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wen, et al. Standards Track [Page 158]
+