diff options
Diffstat (limited to 'doc/rfc/rfc9182.txt')
| -rw-r--r-- | doc/rfc/rfc9182.txt | 6827 |
1 files changed, 6827 insertions, 0 deletions
diff --git a/doc/rfc/rfc9182.txt b/doc/rfc/rfc9182.txt new file mode 100644 index 0000000..75c2bb1 --- /dev/null +++ b/doc/rfc/rfc9182.txt @@ -0,0 +1,6827 @@ + + + + +Internet Engineering Task Force (IETF) S. Barguil +Request for Comments: 9182 O. Gonzalez de Dios, Ed. +Category: Standards Track Telefonica +ISSN: 2070-1721 M. Boucadair, Ed. + Orange + L. Munoz + Vodafone + A. Aguado + Nokia + February 2022 + + + A YANG Network Data Model for Layer 3 VPNs + +Abstract + + As a complement to the Layer 3 Virtual Private Network Service Model + (L3SM), which is used for communication between customers and service + providers, this document defines an L3VPN Network Model (L3NM) that + can be used for the provisioning of Layer 3 Virtual Private Network + (L3VPN) services within a service provider network. The model + provides a network-centric view of L3VPN services. + + The L3NM is meant to be used by a network controller to derive the + configuration information that will be sent to relevant network + devices. The model can also facilitate communication between a + service orchestrator and a network controller/orchestrator. + +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/rfc9182. + +Copyright Notice + + Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Acronyms and Abbreviations + 4. L3NM Reference Architecture + 5. Relationship to Other YANG Data Models + 6. Sample Uses of the L3NM Data Model + 6.1. Enterprise Layer 3 VPN Services + 6.2. Multi-Domain Resource Management + 6.3. Management of Multicast Services + 7. Description of the L3NM YANG Module + 7.1. Overall Structure of the Module + 7.2. VPN Profiles + 7.3. VPN Services + 7.4. VPN Instance Profiles + 7.5. VPN Nodes + 7.6. VPN Network Accesses + 7.6.1. Connection + 7.6.2. IP Connection + 7.6.3. CE-PE Routing Protocols + 7.6.3.1. Static Routing + 7.6.3.2. BGP + 7.6.3.3. OSPF + 7.6.3.4. IS-IS + 7.6.3.5. RIP + 7.6.3.6. VRRP + 7.6.4. OAM + 7.6.5. Security + 7.6.6. Services + 7.6.6.1. Overview + 7.6.6.2. QoS + 7.7. Multicast + 8. L3NM YANG Module + 9. Security Considerations + 10. IANA Considerations + 11. References + 11.1. Normative References + 11.2. Informative References + Appendix A. L3VPN Examples + A.1. 4G VPN Provisioning Example + A.2. Loopback Interface + A.3. Overriding VPN Instance Profile Parameters + A.4. Multicast VPN Provisioning Example + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + [RFC8299] defines a YANG Layer 3 Virtual Private Network Service + Model (L3SM) that can be used for communication between customers and + service providers. Such a model focuses on describing the customer + view of the Virtual Private Network (VPN) services and provides an + abstracted view of the customer's requested services. That approach + limits the usage of the L3SM to the role of a customer service model + (as per [RFC8309]). + + This document defines a YANG module called the "L3VPN Network Model" + (L3NM). The L3NM is aimed at providing a network-centric view of + Layer 3 (L3) VPN services. This data model can be used to facilitate + communication between the service orchestrator and the network + controller/orchestrator by allowing more network-centric information + to be included. It enables such additional capabilities as resource + management, or it serves as a multi-domain orchestration interface + where logical resources (such as route targets or route + distinguishers) must be coordinated. + + This document uses the common VPN YANG module defined in [RFC9181]. + + This document does not obsolete [RFC8299]. These two modules are + used for similar objectives but with different scopes and views. + + The L3NM YANG module was initially built with a "prune and extend" + approach, taking as a starting point the YANG module described in + [RFC8299]. Nevertheless, the L3NM is not defined as an augment to + the L3SM, because a specific structure is required to meet network- + oriented L3 needs. + + Some information captured in the L3SM can be passed by the + orchestrator in the L3NM (e.g., customer) or be used to feed some + L3NM attributes (e.g., actual forwarding policies). Also, some + information captured in the L3SM may be maintained locally within the + orchestrator, which is in charge of maintaining the correlation + between a customer view and its network instantiation. Likewise, + some information captured and exposed using the L3NM can feed the + service layer (e.g., capabilities) to drive VPN service order + handling and thus the L3SM. + + Section 5.1 of [RFC8969] illustrates how the L3NM can be used within + the network management automation architecture. + + The L3NM does not attempt to address all deployment cases, especially + those where L3VPN connectivity is supported through the coordination + of different VPNs in different underlying networks. More complex + deployment scenarios involving the coordination of different VPN + instances and different technologies to provide end-to-end VPN + connectivity are addressed by complementary YANG modules, e.g., + [YANG-Composed-VPN]. + + The L3NM focuses on Layer 3 VPNs based on BGP Provider Edges (PEs) as + described in [RFC4026], [RFC4110], and [RFC4364]; and Multicast VPNs + as described in [RFC6037] and [RFC6513]. + + The YANG data model in this document conforms to the Network + Management Datastore Architecture (NMDA) defined in [RFC8342]. + +2. Terminology + + 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. + + This document assumes that the reader is familiar with the contents + of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses + the terminology defined in those documents. + + This document uses the term "network model" as defined in Section 2.1 + of [RFC8969]. + + The meanings of the symbols in the tree diagrams are defined in + [RFC8340]. + + This document makes use of the following terms: + + Layer 3 VPN Service Model (L3SM): A YANG data model that describes + the service requirements of an L3VPN that interconnects a set of + sites from the point of view of the customer. The customer + service model does not provide details on the service provider + network. The L3VPN customer service model is defined in + [RFC8299]. + + Layer 3 VPN Network Model (L3NM): A YANG data model that describes a + VPN service in the service provider network. It contains + information on the service provider network and might include + allocated resources. It can be used by network controllers to + manage and control the VPN service configuration in the service + provider network. The corresponding YANG module can be used by a + service orchestrator to request a VPN service to a network + controller. + + Service orchestrator: A functional entity that interacts with the + customer of an L3VPN. The service orchestrator interacts with the + customer using the L3SM. The service orchestrator is responsible + for the Customer Edge to Provider Edge (CE-PE) attachment + circuits, the PE selection, and requesting the VPN service to the + network controller. + + Network orchestrator: A functional entity that is hierarchically + intermediate between a service orchestrator and network + controllers. A network orchestrator can manage one or several + network controllers. + + Network controller: A functional entity responsible for the control + and management of the service provider network. + + VPN node: An abstraction that represents a set of policies applied + on a PE and belonging to a single VPN service. A VPN service + involves one or more VPN nodes. As it is an abstraction, the + network controller will decide how to implement a VPN node. For + example, in a BGP-based VPN, a VPN node could typically be mapped + to a Virtual Routing and Forwarding (VRF) instance. + + VPN network access: An abstraction that represents the network + interfaces that are associated with a given VPN node. Traffic + coming from the VPN network access belongs to the VPN. The + attachment circuits (bearers) between CEs and PEs are terminated + in the VPN network access. A reference to the bearer is + maintained to allow keeping the link between the L3SM and L3NM + when both models are used in a given deployment. + + VPN site: A VPN customer's location that is connected to the service + provider network via a CE-PE link, which can access at least one + VPN [RFC4176]. + + VPN service provider: A service provider that offers VPN-related + services [RFC4176]. + + Service provider network: A network that is able to provide VPN- + related services. + + This document is aimed at modeling BGP PE-based VPNs in a service + provider network, so the terms defined in [RFC4026] and [RFC4176] are + used in this document as well. + +3. Acronyms and Abbreviations + + The following acronyms and abbreviations are used in this document: + + ACL Access Control List + AS Autonomous System + ASM Any-Source Multicast + ASN AS Number + BFD Bidirectional Forwarding Detection + BGP Border Gateway Protocol + BSR Bootstrap Router + CE Customer Edge + CsC Carriers' Carriers + IGMP Internet Group Management Protocol + L3NM L3VPN Network Model + L3SM L3VPN Service Model + L3VPN Layer 3 Virtual Private Network + MLD Multicast Listener Discovery + MSDP Multicast Source Discovery Protocol + MVPN Multicast VPN + NAT Network Address Translation + OAM Operations, Administration, and Maintenance + OSPF Open Shortest Path First + PE Provider Edge + PIM Protocol Independent Multicast + QoS Quality of Service + RD Route Distinguisher + RP Rendezvous Point + RT Route Target + SA Security Association + SSM Source-Specific Multicast + VPN Virtual Private Network + VRF Virtual Routing and Forwarding + +4. L3NM Reference Architecture + + Figure 1 depicts the reference architecture for the L3NM. The figure + is an expansion of the architecture presented in Section 5 of + [RFC8299]; it decomposes the box marked "orchestration" in that + section into three separate functional components: service + orchestration, network orchestration, and domain orchestration. + + Although some deployments may choose to construct a monolithic + orchestration component (covering both service and network matters), + this document advocates for a clear separation between service and + network orchestration components for the sake of better flexibility. + Such a design adheres to the L3VPN reference architecture defined in + Section 1.3 of [RFC4176]. This separation relies upon a dedicated + communication interface between these components and appropriate YANG + modules that reflect network-related information. Such information + is hidden from customers. + + The intelligence for translating customer-facing information into + network-centric information (and vice versa) is implementation + specific. + + The terminology from [RFC8309] is used here to show the distinction + between the customer service model, the service delivery model, the + network configuration model, and the device configuration model. In + that context, the "domain orchestration" and "config manager" roles + may be performed by "controllers". + + +---------------+ + | Customer | + +-------+-------+ + Customer Service Model | + (e.g., 'l3vpn-svc') | + +-------+-------+ + | Service | + | Orchestration | + +-------+-------+ + Service Delivery Model | + 'l3vpn-ntw' | + +-------+-------+ + | Network | + | Orchestration | + +-------+-------+ + Network Configuration Model | + +-----------+-----------+ + | | + +--------+------+ +--------+------+ + | Domain | | Domain | + | Orchestration | | Orchestration | + +---+-----------+ +--------+------+ + Device | | | + Configuration | | | + Model | | | + +----+----+ | | + | Config | | | + | Manager | | | + +----+----+ | | + | | | + | NETCONF/CLI.................. + | | | + +------------------------------------------------+ + Network + + NETCONF: Network Configuration Protocol + CLI: Command-Line Interface + + Figure 1: L3NM Reference Architecture + + The customer may use a variety of means to request a service that may + trigger the instantiation of an L3NM. The customer may use the L3SM + or more abstract models to request a service that relies upon an + L3VPN service. For example, the customer may supply an IP + Connectivity Provisioning Profile (CPP) that characterizes the + requested service [RFC7297], an enhanced VPN (VPN+) service + [Enhanced-VPN-Framework], or an IETF network slice service + [Network-Slices-Framework]. + + Note also that both the L3SM and the L3NM may be used in the context + of the Abstraction and Control of TE Networks (ACTN) framework + [RFC8453]. Figure 2 shows the Customer Network Controller (CNC), the + Multi-Domain Service Coordinator (MDSC), the Provisioning Network + Controller (PNC) components, and the interfaces where the L3SM and + L3NM are used. + + +----------------------------------+ + | Customer | + | +-----------------------------+ | + | | CNC | | + | +-----------------------------+ | + +----+-----------------------+-----+ + | | + | L3SM | L3SM + | | + +---------+---------+ +---------+---------+ + | MDSC | | MDSC | + | +---------------+ | | (parent) | + | | Service | | +---------+---------+ + | | Orchestration | | | + | +-------+-------+ | | L3NM + | | | | + | | L3NM | +---------+---------+ + | | | | MDSC | + | +-------+-------+ | | (child) | + | | Network | | +---------+---------+ + | | Orchestration | | | + | +---------------+ | | + +---------+---------+ | + | | + | Network Configuration | + | | + +------------+-------+ +---------+------------+ + | Domain | | Domain | + | Controller | | Controller | + | +---------+ | | +---------+ | + | | PNC | | | | PNC | | + | +---------+ | | +---------+ | + +------------+-------+ +---------+------------+ + | | + | Device Configuration | + | | + +----+---+ +----+---+ + | Device | | Device | + +--------+ +--------+ + + Figure 2: L3SM and L3NM in the Context of the ACTN + +5. Relationship to Other YANG Data Models + + The "ietf-vpn-common" module [RFC9181] includes a set of identities, + types, and groupings that are meant to be reused by VPN-related YANG + modules independently of the layer (e.g., Layer 2, Layer 3) and the + type of the module (e.g., network model, service model), including + future revisions of existing models (e.g., [RFC8299] or [RFC8466]). + The L3NM reuses these common types and groupings. + + In order to avoid data duplication and to ease passing data between + layers when required (service layer to network layer and vice versa), + early versions of the L3NM reused many of the data nodes that are + defined in [RFC8299]. Nevertheless, that approach was abandoned in + favor of the "ietf-vpn-common" module because that initial design was + interpreted as if the deployment of the L3NM depends on the L3SM, + while this is not the case. For example, a service provider may + decide to use the L3NM to build its L3VPN services without exposing + the L3SM. + + As discussed in Section 4, the L3NM is meant to manage L3VPN services + within a service provider network. The module provides a network + view of the service. Such a view is only visible within the service + provider and is not exposed outside (to customers, for example). The + items below discuss how the L3NM interfaces with other YANG modules: + + L3SM: The L3NM is not a customer service model. + + The internal view of the service (i.e., the L3NM) may be mapped to + an external view that is visible to customers: the L3VPN Service + Model (L3SM) [RFC8299]. + + The L3NM can be fed with inputs that are requested by customers. + Such requests typically rely upon an L3SM template. Concretely, + some parts of the L3SM module can be directly mapped to the L3NM, + while other parts are generated as a function of the requested + service and local guidelines. Some other parts are local to the + service provider and do not map directly to the L3SM. + + Note that using the L3NM within a service provider does not + assume, nor does it preclude, exposing the VPN service via the + L3SM. This is deployment specific. Nevertheless, the design of + the L3NM tries to align as much as possible with the features + supported by the L3SM to ease the grafting of both the L3NM and + the L3SM for the sake of highly automated VPN service provisioning + and delivery. + + Network Topology Modules: An L3VPN involves nodes that are part of a + topology managed by the service provider network. The topology + can be represented using the network topology YANG module defined + in [RFC8345] or its extension, such as a network YANG module for + Service Attachment Points (SAPs) [YANG-SAPs]. + + Device Modules: The L3NM is not a device model. + + Once a global VPN service is captured by means of the L3NM, the + actual activation and provisioning of the VPN service will involve + a variety of device modules to tweak the required functions for + the delivery of the service. These functions are supported by the + VPN nodes and can be managed using device YANG modules. A non- + comprehensive list of such device YANG modules is provided below: + + * Routing management [RFC8349]. + + * BGP [BGP-YANG]. + + * PIM [PIM-YANG]. + + * NAT management [RFC8512]. + + * QoS management [QoS-YANG]. + + * ACLs [RFC8519]. + + How the L3NM is used to derive device-specific actions is + implementation specific. + +6. Sample Uses of the L3NM Data Model + + This section provides a non-exhaustive list of examples that + illustrate contexts where the L3NM can be used. + +6.1. Enterprise Layer 3 VPN Services + + Enterprise L3VPNs are one of the most demanded services for carriers; + therefore, L3NM can be useful for automating the provisioning and + maintenance of these VPNs. Templates and batch processes can be + built, and as a result many parameters are needed for the creation + from scratch of a VPN that can be abstracted to the upper Software- + Defined Networking (SDN) layer [RFC7149] [RFC7426], but some manual + intervention will still be required. + + A common function that is supported by VPNs is the addition or + removal of VPN nodes. Workflows can use the L3NM in these scenarios + to add or prune nodes from the network data model as required. + +6.2. Multi-Domain Resource Management + + The implementation of L3VPN services that span administratively + separated domains (i.e., that are under the administration of + different management systems or controllers) requires some network + resources to be synchronized between systems. Particularly, + resources must be adequately managed in each domain to avoid broken + configurations. + + For example, route targets (RTs) shall be synchronized between PEs. + When all PEs are controlled by the same management system, RT + allocation can be performed by that management system. In cases + where the service spans multiple management systems, the task of + allocating RTs has to be aligned across the domains; therefore, the + network model must provide a way to specify RTs. In addition, route + distinguishers (RDs) must also be synchronized to avoid collisions of + RD allocations between separate management systems. An incorrect + allocation might lead to the same RD and IP prefixes being exported + by different PEs. + +6.3. Management of Multicast Services + + Multicast services over L3VPNs can be implemented using dual PIM + MVPNs (also known as the draft-rosen model) [RFC6037] or MVPNs based + on Multiprotocol BGP (MP-BGP) [RFC6513] [RFC6514]. Both methods are + supported and equally effective, but the main difference is that MP- + BGP-based MVPNs do not require multicast configuration on the service + provider network. MP-BGP MVPNs employ the intra-AS BGP control plane + and PIM Sparse Mode [RFC7761] as the data plane. The PIM state + information is maintained between PEs using the same architecture + that is used for unicast VPNs. + + On the other hand, [RFC6037] has limitations, such as reduced options + for transport, control plane scalability, availability, operational + inconsistency, and the need to maintain state in the backbone. + Because of these limitations, MP-BGP MVPNs provide the architectural + model that has been taken as the base for implementing multicast + services in L3VPNs. In this scenario, BGP is used to autodiscover + MVPN PE members and the customer PIM signaling is sent across the + provider's core through MP-BGP. The multicast traffic is transported + on MPLS Point-to-Multipoint (P2MP) Label Switched Paths (LSPs). + +7. Description of the L3NM YANG Module + + The L3NM ("ietf-l3vpn-ntw") is defined to manage L3VPNs in a service + provider network. In particular, the "ietf-l3vpn-ntw" module can be + used to create, modify, and retrieve L3VPN services of a network. + + The full tree diagram of the module can be generated using the + "pyang" tool [PYANG]. That tree is not included here because it is + too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided + for the reader's convenience. + +7.1. Overall Structure of the Module + + The "ietf-l3vpn-ntw" module uses two main containers: 'vpn-profiles' + and 'vpn-services' (see Figure 3). + + The 'vpn-profiles' container is used by the provider to maintain a + set of common VPN profiles that apply to one or several VPN services + (Section 7.2). + + The 'vpn-services' container maintains the set of VPN services + managed within the service provider network. The 'vpn-service' is + the data structure that abstracts a VPN service (Section 7.3). + + module: ietf-l3vpn-ntw + +--rw l3vpn-ntw + +--rw vpn-profiles + | ... + +--rw vpn-services + +--rw vpn-service* [vpn-id] + ... + +--rw vpn-nodes + +--rw vpn-node* [vpn-node-id] + ... + +--rw vpn-network-accesses + +--rw vpn-network-access* [id] + ... + + Figure 3: Overall L3NM Tree Structure + + Some of the data nodes are keyed by the address family. For the sake + of data representation compactness, it is RECOMMENDED to use the + dual-stack address family for data nodes that have the same value for + both IPv4 and IPv6. If, for some reason, a data node is present for + both dual-stack and IPv4 (or IPv6), the value that is indicated under + dual-stack takes precedence over the value that is indicated under + IPv4 (or IPv6). + +7.2. VPN Profiles + + The 'vpn-profiles' container (Figure 4) allows the VPN service + provider to define and maintain a set of VPN profiles [RFC9181] that + apply to one or several VPN services. + + +--rw l3vpn-ntw + +--rw vpn-profiles + | +--rw valid-provider-identifiers + | +--rw external-connectivity-identifier* [id] + | | {external-connectivity}? + | | +--rw id string + | +--rw encryption-profile-identifier* [id] + | | +--rw id string + | +--rw qos-profile-identifier* [id] + | | +--rw id string + | +--rw bfd-profile-identifier* [id] + | | +--rw id string + | +--rw forwarding-profile-identifier* [id] + | | +--rw id string + | +--rw routing-profile-identifier* [id] + | +--rw id string + +--rw vpn-services + ... + + Figure 4: VPN Profiles Subtree Structure + + This document does not make any assumption about the exact definition + of these profiles. The exact definition of the profiles is local to + each VPN service provider. The model only includes an identifier for + these profiles in order to facilitate identifying and binding local + policies when building a VPN service. As shown in Figure 4, the + following identifiers can be included: + + 'external-connectivity-identifier': This identifier refers to a + profile that defines the external connectivity provided to a VPN + service (or a subset of VPN sites). External connectivity may be + access to the Internet or restricted connectivity, such as access + to a public/private cloud. + + 'encryption-profile-identifier': An encryption profile refers to a + set of policies related to the encryption schemes and setup that + can be applied when building and offering a VPN service. + + 'qos-profile-identifier': A Quality of Service (QoS) profile refers + to a set of policies, such as classification, marking, and actions + (e.g., [RFC3644]). + + 'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD) + profile refers to a set of BFD policies [RFC5880] that can be + invoked when building a VPN service. + + 'forwarding-profile-identifier': A forwarding profile refers to the + policies that apply to the forwarding of packets conveyed within a + VPN. Such policies may consist, for example, of applying Access + Control Lists (ACLs). + + 'routing-profile-identifier': A routing profile refers to a set of + routing policies that will be invoked (e.g., BGP policies) when + delivering the VPN service. + +7.3. VPN Services + + The 'vpn-service' is the data structure that abstracts a VPN service + in the service provider network. Each 'vpn-service' is uniquely + identified by an identifier: 'vpn-id'. Such a 'vpn-id' is only + meaningful locally (e.g., the network controller). The subtree of + the 'vpn-services' is shown in Figure 5. + + +--rw l3vpn-ntw + +--rw vpn-profiles + | ... + +--rw vpn-services + +--rw vpn-service* [vpn-id] + +--rw vpn-id vpn-common:vpn-id + +--rw vpn-name? string + +--rw vpn-description? string + +--rw customer-name? string + +--rw parent-service-id? vpn-common:vpn-id + +--rw vpn-type? identityref + +--rw vpn-service-topology? identityref + +--rw status + | +--rw admin-status + | | +--rw status? identityref + | | +--rw last-change? yang:date-and-time + | +--ro oper-status + | +--ro status? identityref + | +--ro last-change? yang:date-and-time + +--rw vpn-instance-profiles + | ... + +--rw underlay-transport + | +-- (type)? + | +--:(abstract) + | | +--rw transport-instance-id? string + | | +--rw instance-type? identityref + | +--:(protocol) + | +--rw protocol* identityref + +--rw external-connectivity + | {vpn-common:external-connectivity}? + | +--rw (profile)? + | +--:(profile) + | +--rw profile-name? leafref + +--rw vpn-nodes + ... + + Figure 5: VPN Services Subtree Structure + + The descriptions of the VPN service data nodes that are depicted in + Figure 5 are as follows: + + 'vpn-id': An identifier that is used to uniquely identify the L3VPN + service within the L3NM scope. + + 'vpn-name': Associates a name with the service in order to + facilitate the identification of the service. + + 'vpn-description': Includes a textual description of the service. + + The internal structure of a VPN description is local to each VPN + service provider. + + 'customer-name': Indicates the name of the customer who ordered the + service. + + 'parent-service-id': Refers to an identifier of the parent service + (e.g., L3SM, IETF network slice, VPN+) that triggered the creation + of the VPN service. This identifier is used to easily correlate + the (network) service as built in the network with a service + order. A controller can use that correlation to enrich or + populate some fields (e.g., description fields) as a function of + local deployments. + + 'vpn-type': Indicates the VPN type. The values are taken from + [RFC9181]. For the L3NM, this is typically set to "BGP/MPLS + L3VPN", but other values may be defined to support specific Layer + 3 VPN capabilities (e.g., [RFC9136]). + + 'vpn-service-topology': Indicates the network topology for the + service: 'hub-spoke', 'any-to-any', or 'custom'. The network + implementation of this attribute is defined by the correct usage + of import and export targets (Section 4.3.5 of [RFC4364]). + + 'status': Used to track the service status of a given VPN service. + Both operational status and administrative status are maintained + together with a timestamp. For example, a service can be created + but not put into effect. + + Administrative status and operational status can be used as a + trigger to detect service anomalies. For example, a service that + is declared active at the service layer but is still inactive at + the network layer may be an indication that network provision + actions are needed to align the observed service status with the + expected service status. + + 'vpn-instance-profiles': Defines reusable parameters for the same + 'vpn-service'. + + More details are provided in Section 7.4. + + 'underlay-transport': Describes the preference for the transport + technology to carry the traffic of the VPN service. This + preference is especially useful in networks with multiple domains + and Network-to-Network Interface (NNI) types. The underlay + transport can be expressed as an abstract transport instance + (e.g., an identifier of a VPN+ instance, a virtual network + identifier, or a network slice name) or as an ordered list of the + actual protocols to be enabled in the network. + + A rich set of protocol identifiers that can be used to refer to an + underlay transport are defined in [RFC9181]. + + 'external-connectivity': Indicates whether/how external connectivity + is provided to the VPN service. For example, a service provider + may provide external connectivity to a VPN customer (e.g., to a + public cloud). Such a service may involve tweaking both filtering + and NAT rules (e.g., binding a Virtual Routing and Forwarding + (VRF) interface with a NAT instance as discussed in Section 2.10 + of [RFC8512]). These value-added features may be bound to all, or + a subset of, network accesses. Some of these value-added features + may be implemented in a PE or in nodes other than PEs (e.g., a P + node or even a dedicated node that hosts the NAT function). + + Only a pointer to a local profile that defines the external- + connectivity feature is supported in this document. + + 'vpn-node': An abstraction that represents a set of policies applied + to a network node and belonging to a single 'vpn-service'. A VPN + service is typically built by adding instances of 'vpn-node' to + the 'vpn-nodes' container. + + A 'vpn-node' contains 'vpn-network-accesses', which are the + interfaces attached to the VPN by which the customer traffic is + received. Therefore, the customer sites are connected to the + 'vpn-network-accesses'. + + Note that because this is a network data model, information about + customers' sites is not required in the model. Rather, such + information is relevant in the L3SM. Whether that information is + included in the L3NM, e.g., to populate the various 'description' + data nodes, is implementation specific. + + More details are provided in Section 7.5. + +7.4. VPN Instance Profiles + + VPN instance profiles are meant to factorize data nodes that are used + at many levels of the model. Generic VPN instance profiles are + defined at the VPN service level and then called at the VPN node and + VPN network access levels. Each VPN instance profile is identified + by 'profile-id'. This identifier is then referenced for one or + multiple VPN nodes (Section 7.5) so that the controller can identify + generic resources (e.g., RTs and RDs) to be configured for a given + VRF instance. + + The subtree of the 'vpn-instance-profiles' is shown in Figure 6. + + +--rw l3vpn-ntw + +--rw vpn-profiles + | ... + +--rw vpn-services + +--rw vpn-service* [vpn-id] + +--rw vpn-id vpn-common:vpn-id + ... + +--rw vpn-instance-profiles + | +--rw vpn-instance-profile* [profile-id] + | +--rw profile-id string + | +--rw role? identityref + | +--rw local-as? inet:as-number + | | {vpn-common:rtg-bgp}? + | +--rw (rd-choice)? + | | +--:(directly-assigned) + | | | +--rw rd? + | | | rt-types:route-distinguisher + | | +--:(directly-assigned-suffix) + | | | +--rw rd-suffix? uint16 + | | +--:(auto-assigned) + | | | +--rw rd-auto + | | | +--rw (auto-mode)? + | | | | +--:(from-pool) + | | | | | +--rw rd-pool-name? string + | | | | +--:(full-auto) + | | | | +--rw auto? empty + | | | +--ro auto-assigned-rd? + | | | rt-types:route-distinguisher + | | +--:(auto-assigned-suffix) + | | | +--rw rd-auto-suffix + | | | +--rw (auto-mode)? + | | | | +--:(from-pool) + | | | | | +--rw rd-pool-name? string + | | | | +--:(full-auto) + | | | | +--rw auto? empty + | | | +--ro auto-assigned-rd-suffix? uint16 + | | +--:(no-rd) + | | +--rw no-rd? empty + | +--rw address-family* [address-family] + | | +--rw address-family identityref + | | +--rw vpn-targets + | | | +--rw vpn-target* [id] + | | | | +--rw id uint8 + | | | | +--rw route-targets* [route-target] + | | | | | +--rw route-target + | | | | | rt-types:route-target + | | | | +--rw route-target-type + | | | | rt-types:route-target-type + | | | +--rw vpn-policies + | | | +--rw import-policy? string + | | | +--rw export-policy? string + | | +--rw maximum-routes* [protocol] + | | +--rw protocol identityref + | | +--rw maximum-routes? uint32 + | +--rw multicast {vpn-common:multicast}? + | ... + + Figure 6: Subtree Structure of VPN Instance Profiles + + The descriptions of the listed data nodes are as follows: + + 'profile-id': Used to uniquely identify a VPN instance profile. + + 'role': Indicates the role of the VPN instance profile in the VPN. + Role values are defined in [RFC9181] (e.g., 'any-to-any-role', + 'spoke-role', 'hub-role'). + + 'local-as': Indicates the Autonomous System Number (ASN) that is + configured for the VPN node. + + 'rd': As defined in [RFC9181], the following RD assignment modes are + supported: direct assignment, full automatic assignment, automatic + assignment from a given pool, and no assignment. For illustration + purposes, the following modes can be used in the deployment cases: + + 'directly-assigned': The VPN service provider (service + orchestrator) assigns RDs explicitly. This case will fit with + a brownfield scenario where some existing services need to be + updated by the VPN service provider. + + 'full-auto': The network controller auto-assigns RDs. This can + apply for the deployment of new services. + + 'no-rd': The VPN service provider (service orchestrator) + explicitly wants no RD to be assigned. This case can be used + for CE testing within the network or for troubleshooting + proposes. + + Also, the module accommodates deployments where only the Assigned + Number subfield of RDs (Section 4.2 of [RFC4364]) is assigned from + a pool while the Administrator subfield is set to, for example, + the Router ID that is assigned to a VPN node. The module supports + these modes for managing the Assigned Number subfield: explicit + assignment, auto-assignment from a pool, and full auto-assignment. + + 'address-family': Includes a set of data nodes per address family: + + 'address-family': Identifies the address family. It can be set + to 'ipv4', 'ipv6', or 'dual-stack'. + + 'vpn-targets': Specifies RT import/export rules for the VPN + service (Section 4.3 of [RFC4364]). + + 'maximum-routes': Indicates the maximum number of prefixes that + the VPN node can accept for a given routing protocol. If + 'protocol' is set to 'any', this means that the maximum value + applies to each active routing protocol. + + 'multicast': Enables multicast traffic in the VPN service. Refer to + Section 7.7. + +7.5. VPN Nodes + + The 'vpn-node' is an abstraction that represents a set of common + policies applied on a given network node (typically, a PE) and + belonging to one L3VPN service. The 'vpn-node' includes a parameter + to indicate the network node on which it is applied. In the case + that the 'ne-id' points to a specific PE, the 'vpn-node' will likely + be mapped to a VRF instance in the node. However, the model also + allows pointing to an abstract node. In this case, the network + controller will decide how to split the 'vpn-node' into VRF + instances. + + The VPN node subtree structure is shown in Figure 7. + + +--rw l3vpn-ntw + +--rw vpn-profiles + | ... + +--rw vpn-services + +--rw vpn-service* [vpn-id] + ... + +--rw vpn-nodes + +--rw vpn-node* [vpn-node-id] + +--rw vpn-node-id vpn-common:vpn-id + +--rw description? string + +--rw ne-id? string + +--rw local-as? inet:as-number + | {vpn-common:rtg-bgp}? + +--rw router-id? rt-types:router-id + +--rw active-vpn-instance-profiles + | +--rw vpn-instance-profile* [profile-id] + | +--rw profile-id leafref + | +--rw router-id* [address-family] + | | +--rw address-family identityref + | | +--rw router-id? inet:ip-address + | +--rw local-as? inet:as-number + | | {vpn-common:rtg-bgp}? + | +--rw (rd-choice)? + | | .... + | +--rw address-family* [address-family] + | | +--rw address-family identityref + | | | ... + | | +--rw vpn-targets + | | | ... + | | +--rw maximum-routes* [protocol] + | | ... + | +--rw multicast {vpn-common:multicast}? + | ... + +--rw msdp {msdp}? + | +--rw peer? inet:ipv4-address + | +--rw local-address? inet:ipv4-address + | +--rw status + | +--rw admin-status + | | +--rw status? identityref + | | +--rw last-change? yang:date-and-time + | +--ro oper-status + | +--ro status? identityref + | +--ro last-change? yang:date-and-time + +--rw groups + | +--rw group* [group-id] + | +--rw group-id string + +--rw status + | +--rw admin-status + | | +--rw status? identityref + | | +--rw last-change? yang:date-and-time + | +--ro oper-status + | +--ro status? identityref + | +--ro last-change? yang:date-and-time + +--rw vpn-network-accesses + ... + + Figure 7: VPN Node Subtree Structure + + The descriptions of the 'vpn-node' data nodes (Figure 7) are as + follows: + + 'vpn-node-id': An identifier that uniquely identifies a node that + enables a VPN network access. + + 'description': Provides a textual description of the VPN node. + + 'ne-id': Includes a unique identifier of the network element where + the VPN node is deployed. + + 'local-as': Indicates the ASN that is configured for the VPN node. + + 'router-id': Indicates a 32-bit number that is used to uniquely + identify a router within an AS. + + 'active-vpn-instance-profiles': Lists the set of active VPN instance + profiles for this VPN node. Concretely, one or more VPN instance + profiles that are defined at the VPN service level can be enabled + at the VPN node level; each of these profiles is uniquely + identified by means of 'profile-id'. The structure of 'active- + vpn-instance-profiles' is the same as the structure discussed in + Section 7.4, except that the structure of 'active-vpn-instance- + profiles' includes 'router-id' but does not include the 'role' + leaf. The value of 'router-id' indicated under 'active-vpn- + instance-profiles' takes precedence over the 'router-id' under the + 'vpn-node' for the indicated address family. For example, Router + IDs can be configured per address family. This capability can be + used, for example, to configure an IPv6 address as a Router ID + when such a capability is supported by involved routers. + + Values defined in 'active-vpn-instance-profiles' override the + values defined at the VPN service level. An example is shown in + Appendix A.3. + + 'msdp': For redundancy purposes, the Multicast Source Discovery + Protocol (MSDP) [RFC3618] may be enabled and used to share state + information about sources between multiple Rendezvous Points + (RPs). The purpose of MSDP in this context is to enhance the + robustness of the multicast service. MSDP may be configured on + non-RP routers; this is useful in a domain that does not support + multicast sources but does support multicast transit. + + 'groups': Lists the groups to which a VPN node belongs [RFC9181]. + For example, the 'group-id' is used to associate redundancy or + protection constraints with VPN nodes. + + 'status': Tracks the status of a node involved in a VPN service. + Both operational status and administrative status are maintained. + A mismatch between the administrative status vs. the operational + status can be used as a trigger to detect anomalies. + + 'vpn-network-accesses': Represents the point to which sites are + connected. + + Note that unlike the L3SM, the L3NM does not need to model the + customer site -- only the points that receive traffic from the + site (i.e., the PE side of Provider Edge to Customer Edge (PE-CE) + connections). Hence, the VPN network access contains the + connectivity information between the provider's network and the + customer premises. The VPN profiles ('vpn-profiles') have a set + of routing policies that can be applied during the service + creation. + + See Section 7.6 for more details. + +7.6. VPN Network Accesses + + The 'vpn-network-access' includes a set of data nodes that describe + the access information for the traffic that belongs to a particular + L3VPN (Figure 8). + + ... + +--rw vpn-nodes + +--rw vpn-node* [vpn-node-id] + ... + +--rw vpn-network-accesses + +--rw vpn-network-access* [id] + +--rw id vpn-common:vpn-id + +--rw interface-id? string + +--rw description? string + +--rw vpn-network-access-type? identityref + +--rw vpn-instance-profile? leafref + +--rw status + | +--rw admin-status + | | +--rw status? identityref + | | +--rw last-change? yang:date-and-time + | +--ro oper-status + | +--ro status? identityref + | +--ro last-change? yang:date-and-time + +--rw connection + | ... + +--rw ip-connection + | ... + +--rw routing-protocols + | ... + +--rw oam + | ... + +--rw security + | ... + +--rw service + ... + + Figure 8: VPN Network Access Subtree Structure + + A 'vpn-network-access' (Figure 8) includes the following data nodes: + + 'id': An identifier of the VPN network access. + + 'interface-id': Indicates the physical or logical interface on which + the VPN network access is bound. + + 'description': Includes a textual description of the VPN network + access. + + 'vpn-network-access-type': Used to select the type of network + interface to be deployed in the devices. The available defined + values are as follows: + + 'point-to-point': Represents a direct connection between the + endpoints. The controller must keep the association between a + logical or physical interface on the device with the 'id' of + the 'vpn-network-access'. + + 'multipoint': Represents a multipoint connection between the + customer site and the PEs. The controller must keep the + association between a logical or physical interface on the + device with the 'id' of the 'vpn-network-access'. + + 'irb': Represents a connection coming from an L2VPN service. An + identifier of such a service ('l2vpn-id') may be included in + the 'connection' container, as depicted in Figure 9 + (Section 7.6.1). The controller must keep the relationship + between the logical tunnels or bridges on the devices with the + 'id' of the 'vpn-network-access'. + + 'loopback': Represents the creation of a logical interface on a + device. An example that illustrates how a loopback interface + can be used in the L3NM is provided in Appendix A.2. + + 'vpn-instance-profile': Provides a pointer to an active VPN instance + profile at the VPN node level. Referencing an active VPN instance + profile implies that all associated data nodes will be inherited + by the VPN network access. However, some inherited data nodes + (e.g., multicast) can be overridden at the VPN network access + level. In such a case, adjusted values take precedence over + inherited values. + + 'status': Indicates both operational status and administrative + status of a VPN network access. + + 'connection': Represents and groups the set of Layer 2 connectivity + from where the traffic of the L3VPN in a particular VPN network + access is coming. See Section 7.6.1. + + 'ip-connection': Contains Layer 3 connectivity information on a VPN + network access (e.g., IP addressing). See Section 7.6.2. + + 'routing-protocols': Includes the CE-PE routing configuration + information. See Section 7.6.3. + + 'oam': Specifies the Operations, Administration, and Maintenance + (OAM) mechanisms used for a VPN network access. See + Section 7.6.4. + + 'security': Specifies the authentication and the encryption to be + applied for a given VPN network access. See Section 7.6.5. + + 'service': Specifies the service parameters (e.g., QoS, multicast) + to apply for a given VPN network access. See Section 7.6.6. + +7.6.1. Connection + + The 'connection' container represents the Layer 2 connectivity to the + L3VPN for a particular VPN network access. As shown in the tree + depicted in Figure 9, the 'connection' container defines protocols + and parameters to enable such connectivity at Layer 2. + + The traffic can enter the VPN with or without encapsulation (e.g., + VLAN, QinQ). The 'encapsulation' container specifies the Layer 2 + encapsulation to use (if any) and allows the configuration of the + relevant tags. + + The interface that is attached to the L3VPN is identified by the + 'interface-id' at the 'vpn-network-access' level. From a network + model perspective, it is expected that the 'interface-id' is + sufficient to identify the interface. However, specific Layer 2 sub- + interfaces may be required to be configured in some implementations/ + deployments. Such a Layer-2-specific interface can be included in + 'l2-termination-point'. + + If a Layer 2 tunnel is needed to terminate the service in the CE-PE + connection, the 'l2-tunnel-service' container is used to specify the + required parameters to set such a tunneling service (e.g., a Virtual + Private LAN Service (VPLS) or a Virtual eXtensible Local Area Network + (VXLAN)). An identity called 'l2-tunnel-type' is defined for Layer 2 + tunnel selection. The container can also identify the pseudowire + (Section 6.1 of [RFC8077]). + + As discussed in Section 7.6, 'l2vpn-id' is used to identify the L2VPN + service that is associated with an Integrated Routing and Bridging + (IRB) interface. + + To accommodate implementations that require internal bridging, a + local bridge reference can be specified in 'local-bridge-reference'. + Such a reference may be a local bridge domain. + + A site, as per [RFC4176], represents a VPN customer's location that + is connected to the service provider network via a CE-PE link, which + can access at least one VPN. The connection from the site to the + service provider network is the bearer. Every site is associated + with a list of bearers. A bearer is the Layer 2 connection with the + site. In the L3NM, it is assumed that the bearer has been allocated + by the service provider at the service orchestration stage. The + bearer is associated with a network element and a port. Hence, a + bearer is just a 'bearer-reference' to allow the association between + a service request (e.g., the L3SM) and the L3NM. + + The L3NM can be used to create a Link Aggregation Group (LAG) + interface for a given L3VPN service ('lag-interface') [IEEE802.1AX]. + Such a LAG interface can be referenced under 'interface-id' + (Section 7.6). + + ... + +--rw connection + | +--rw encapsulation + | | +--rw type? identityref + | | +--rw dot1q + | | | +--rw tag-type? identityref + | | | +--rw cvlan-id? uint16 + | | +--rw priority-tagged + | | | +--rw tag-type? identityref + | | +--rw qinq + | | +--rw tag-type? identityref + | | +--rw svlan-id uint16 + | | +--rw cvlan-id uint16 + | +--rw (l2-service)? + | | +--:(l2-tunnel-service) + | | | +--rw l2-tunnel-service + | | | +--rw type? identityref + | | | +--rw pseudowire + | | | | +--rw vcid? uint32 + | | | | +--rw far-end? union + | | | +--rw vpls + | | | | +--rw vcid? uint32 + | | | | +--rw far-end* union + | | | +--rw vxlan + | | | +--rw vni-id uint32 + | | | +--rw peer-mode? identityref + | | | +--rw peer-ip-address* inet:ip-address + | | +--:(l2vpn) + | | +--rw l2vpn-id? vpn-common:vpn-id + | +--rw l2-termination-point? string + | +--rw local-bridge-reference? string + | +--rw bearer-reference? string + | | {vpn-common:bearer-reference}? + | +--rw lag-interface {vpn-common:lag-interface}? + | +--rw lag-interface-id? string + | +--rw member-link-list + | +--rw member-link* [name] + | +--rw name string + ... + + Figure 9: Connection Subtree Structure + +7.6.2. IP Connection + + This container is used to group Layer 3 connectivity information, + particularly the IP addressing information, of a VPN network access. + The allocated address represents the PE interface address + configuration. Note that a distinct Layer 3 interface other than the + interface indicated under the 'connection' container may be needed to + terminate the Layer 3 service. The identifier of such an interface + is included in 'l3-termination-point'. For example, this data node + can be used to carry the identifier of a bridge domain interface. + + As shown in Figure 10, the 'ip-connection' container can include + IPv4, IPv6, or both if dual-stack is enabled. + + ... + +--rw vpn-network-accesses + +--rw vpn-network-access* [id] + ... + +--rw ip-connection + | +--rw l3-termination-point? string + | +--rw ipv4 {vpn-common:ipv4}? + | | ... + | +--rw ipv6 {vpn-common:ipv6}? + | ... + ... + + Figure 10: IP Connection Subtree Structure + + For both IPv4 and IPv6, the IP connection supports three IP address + assignment modes for customer addresses: provider DHCP, DHCP relay, + and static addressing. Note that for the IPv6 case, Stateless + Address Autoconfiguration (SLAAC) [RFC4862] can be used. For both + IPv4 and IPv6, 'address-allocation-type' is used to indicate the IP + address allocation mode to activate for a given VPN network access. + + When 'address-allocation-type' is set to 'provider-dhcp', DHCP + assignments can be made locally or by an external DHCP server. Such + behavior is controlled by setting 'dhcp-service-type'. + + Figure 11 shows the structure of the dynamic IPv4 address assignment + (i.e., by means of DHCP). + + ... + +--rw ip-connection + | +--rw l3-termination-point? string + | +--rw ipv4 {vpn-common:ipv4}? + | | +--rw local-address? inet:ipv4-address + | | +--rw prefix-length? uint8 + | | +--rw address-allocation-type? identityref + | | +--rw (allocation-type)? + | | +--:(provider-dhcp) + | | | +--rw dhcp-service-type? enumeration + | | | +--rw (service-type)? + | | | +--:(relay) + | | | | +--rw server-ip-address* + | | | | inet:ipv4-address + | | | +--:(server) + | | | +--rw (address-assign)? + | | | +--:(number) + | | | | +--rw number-of-dynamic-address? + | | | | uint16 + | | | +--:(explicit) + | | | +--rw customer-addresses + | | | +--rw address-pool* [pool-id] + | | | +--rw pool-id string + | | | +--rw start-address + | | | | inet:ipv4-address + | | | +--rw end-address? + | | | inet:ipv4-address + | | +--:(dhcp-relay) + | | | +--rw customer-dhcp-servers + | | | +--rw server-ip-address* inet:ipv4-address + | | +--:(static-addresses) + | | ... + ... + + Figure 11: IP Connection Subtree Structure (IPv4) + + Figure 12 shows the structure of the dynamic IPv6 address assignment + (i.e., DHCPv6 and/or SLAAC). Note that if 'address-allocation-type' + is set to 'slaac', the Prefix Information option of Router + Advertisements that will be issued for SLAAC purposes will carry the + IPv6 prefix that is determined by 'local-address' and 'prefix- + length'. For example, if 'local-address' is set to '2001:db8:0:1::1' + and 'prefix-length' is set to '64', the IPv6 prefix that will be used + is '2001:db8:0:1::/64'. + + ... + +--rw ip-connection + | +--rw l3-termination-point? string + | +--rw ipv4 {vpn-common:ipv4}? + | | ... + | +--rw ipv6 {vpn-common:ipv6}? + | +--rw local-address? inet:ipv6-address + | +--rw prefix-length? uint8 + | +--rw address-allocation-type? identityref + | +--rw (allocation-type)? + | +--:(provider-dhcp) + | | +--rw provider-dhcp + | | +--rw dhcp-service-type? + | | | enumeration + | | +--rw (service-type)? + | | +--:(relay) + | | | +--rw server-ip-address* + | | | inet:ipv6-address + | | +--:(server) + | | +--rw (address-assign)? + | | +--:(number) + | | | +--rw number-of-dynamic-address? + | | | uint16 + | | +--:(explicit) + | | +--rw customer-addresses + | | +--rw address-pool* [pool-id] + | | +--rw pool-id string + | | +--rw start-address + | | | inet:ipv6-address + | | +--rw end-address? + | | inet:ipv6-address + | +--:(dhcp-relay) + | | +--rw customer-dhcp-servers + | | +--rw server-ip-address* + | | inet:ipv6-address + | +--:(static-addresses) + | ... + + Figure 12: IP Connection Subtree Structure (IPv6) + + In the case of static addressing (Figure 13), the model supports the + assignment of several IP addresses in the same 'vpn-network-access'. + To identify which of the addresses is the primary address of a + connection, the 'primary-address' reference MUST be set with the + corresponding 'address-id'. + + ... + +--rw ip-connection + | +--rw l3-termination-point? string + | +--rw ipv4 {vpn-common:ipv4}? + | | +--rw address-allocation-type? identityref + | | +--rw (allocation-type)? + | | ... + | | +--:(static-addresses) + | | +--rw primary-address? -> ../address/address-id + | | +--rw address* [address-id] + | | +--rw address-id string + | | +--rw customer-address? inet:ipv4-address + | +--rw ipv6 {vpn-common:ipv6}? + | +--rw address-allocation-type? identityref + | +--rw (allocation-type)? + | ... + | +--:(static-addresses) + | +--rw primary-address? -> ../address/address-id + | +--rw address* [address-id] + | +--rw address-id string + | +--rw customer-address? inet:ipv6-address + ... + + Figure 13: IP Connection Subtree Structure (Static Mode) + +7.6.3. CE-PE Routing Protocols + + A VPN service provider can configure one or more routing protocols + associated with a particular 'vpn-network-access'. Such routing + protocols are enabled between the PE and the CE. Each instance is + uniquely identified to accommodate scenarios where multiple instances + of the same routing protocol have to be configured on the same link. + + The subtree of the 'routing-protocols' is shown in Figure 14. + + ... + +--rw vpn-network-accesses + +--rw vpn-network-access* [id] + ... + +--rw routing-protocols + | +--rw routing-protocol* [id] + | +--rw id string + | +--rw type? identityref + | +--rw routing-profiles* [id] + | | +--rw id leafref + | | +--rw type? identityref + | +--rw static + | | ... + | +--rw bgp + | | ... + | +--rw ospf + | | ... + | +--rw isis + | | ... + | +--rw rip + | | ... + | +--rw vrrp + | ... + +--rw security + ... + + Figure 14: Routing Subtree Structure + + Multiple routing instances can be defined, each uniquely identified + by an 'id'. The type of routing instance is indicated in 'type'. + The values of these attributes are those defined in [RFC9181] (the + 'routing-protocol-type' identity). + + Configuring multiple instances of the same routing protocol does not + automatically imply that, from a device configuration perspective, + there will be parallel instances (e.g., multiple processes) running + on the PE-CE link. It is up to each implementation (typically, + network orchestration, as shown in Figure 1) to decide on the + appropriate configuration as a function of underlying capabilities + and service provider operational guidelines. As an example, when + multiple BGP peers need to be implemented, multiple instances of BGP + must be configured as part of this model. However, from a device + configuration point of view, this could be implemented as: + + * Multiple BGP processes with a single neighbor running in each + process. + + * A single BGP process with multiple neighbors running. + + * A combination thereof. + + Routing configuration does not include low-level policies. Such + policies are handled at the device configuration level. Local + policies of a service provider (e.g., filtering) are implemented as + part of the device configuration; these are not captured in the L3NM, + but the model allows local profiles to be associated with routing + instances ('routing-profiles'). Note that these routing profiles can + be scoped to capture parameters that are globally applied to all + L3VPN services within a service provider network, while customized + L3VPN parameters are captured by means of the L3NM. The provisioning + of an L3VPN service will thus rely upon the instantiation of these + global routing profiles and the customized L3NM. + +7.6.3.1. Static Routing + + The L3NM supports the configuration of one or more IPv4/IPv6 static + routes. Since the same structure is used for both IPv4 and IPv6, + using one single container to group both static entries independently + of their address family was considered at one time, but that design + was abandoned to ease the mapping, using the structure provided in + [RFC8299]. + + The static routing subtree structure is shown in Figure 15. + + ... + +--rw routing-protocols + | +--rw routing-protocol* [id] + | ... + | +--rw static + | | +--rw cascaded-lan-prefixes + | | +--rw ipv4-lan-prefixes* + | | | [lan next-hop] + | | | {vpn-common:ipv4}? + | | | +--rw lan inet:ipv4-prefix + | | | +--rw lan-tag? string + | | | +--rw next-hop union + | | | +--rw bfd-enable? boolean + | | | +--rw metric? uint32 + | | | +--rw preference? uint32 + | | | +--rw status + | | | +--rw admin-status + | | | | +--rw status? identityref + | | | | +--rw last-change? yang:date-and-time + | | | +--ro oper-status + | | | +--ro status? identityref + | | | +--ro last-change? yang:date-and-time + | | +--rw ipv6-lan-prefixes* + | | [lan next-hop] + | | {vpn-common:ipv6}? + | | +--rw lan inet:ipv6-prefix + | | +--rw lan-tag? string + | | +--rw next-hop union + | | +--rw bfd-enable? boolean + | | +--rw metric? uint32 + | | +--rw preference? uint32 + | | +--rw status + | | +--rw admin-status + | | | +--rw status? identityref + | | | +--rw last-change? yang:date-and-time + | | +--ro oper-status + | | +--ro status? identityref + | | +--ro last-change? yang:date-and-time + ... + + Figure 15: Static Routing Subtree Structure + + As depicted in Figure 15, the following data nodes can be defined for + a given IP prefix: + + 'lan-tag': Indicates a local tag (e.g., "myfavorite-lan") that is + used to enforce local policies. + + 'next-hop': Indicates the next hop to be used for the static route. + It can be identified by an IP address, a predefined next-hop type + (e.g., 'discard' or 'local-link'), etc. + + 'bfd-enable': Indicates whether BFD is enabled or disabled for this + static route entry. + + 'metric': Indicates the metric associated with the static route + entry. This metric is used when the route is exported into an + IGP. + + 'preference': Indicates the preference associated with the static + route entry. This preference is used to select a preferred route + among routes to the same destination prefix. + + 'status': Used to convey the status of a static route entry. This + data node can also be used to control the (de)activation of + individual static route entries. + +7.6.3.2. BGP + + The L3NM allows the configuration of a BGP neighbor, including a set + of parameters that are pertinent to be tweaked at the network level + for service customization purposes. The 'bgp' container does not aim + to include every BGP parameter; a comprehensive set of parameters + belongs more to the BGP device model. + + The BGP routing subtree structure is shown in Figure 16. + + ... + +--rw routing-protocols + | +--rw routing-protocol* [id] + | ... + | +--rw bgp + | | +--rw description? string + | | +--rw local-as? inet:as-number + | | +--rw peer-as inet:as-number + | | +--rw address-family? identityref + | | +--rw local-address? union + | | +--rw neighbor* inet:ip-address + | | +--rw multihop? uint8 + | | +--rw as-override? boolean + | | +--rw allow-own-as? uint8 + | | +--rw prepend-global-as? boolean + | | +--rw send-default-route? boolean + | | +--rw site-of-origin? rt-types:route-origin + | | +--rw ipv6-site-of-origin? rt-types:ipv6-route-origin + | | +--rw redistribute-connected* [address-family] + | | | +--rw address-family identityref + | | | +--rw enable? boolean + | | +--rw bgp-max-prefix + | | | +--rw max-prefix? uint32 + | | | +--rw warning-threshold? decimal64 + | | | +--rw violate-action? enumeration + | | | +--rw restart-timer? uint32 + | | +--rw bgp-timers + | | | +--rw keepalive? uint16 + | | | +--rw hold-time? uint16 + | | +--rw authentication + | | | +--rw enable? boolean + | | | +--rw keying-material + | | | +--rw (option)? + | | | +--:(ao) + | | | | +--rw enable-ao? boolean + | | | | +--rw ao-keychain? key-chain:key-chain-ref + | | | +--:(md5) + | | | | +--rw md5-keychain? key-chain:key-chain-ref + | | | +--:(explicit) + | | | | +--rw key-id? uint32 + | | | | +--rw key? string + | | | | +--rw crypto-algorithm? identityref + | | | +--:(ipsec) + | | | +--rw sa? string + | | +--rw status + | | +--rw admin-status + | | | +--rw status? identityref + | | | +--rw last-change? yang:date-and-time + | | +--ro oper-status + | | +--ro status? identityref + | | +--ro last-change? yang:date-and-time + ... + + Figure 16: BGP Routing Subtree Structure + + The following data nodes are captured in Figure 16. It is up to the + implementation (e.g., network orchestrator) to derive the + corresponding BGP device configuration: + + 'description': Includes a description of the BGP session. + + 'local-as': Indicates a local AS Number (ASN), if a distinct ASN is + required other than the ASN configured at the VPN node level. + + 'peer-as': Conveys the customer's ASN. + + 'address-family': Indicates the address family of the peer. It can + be set to 'ipv4', 'ipv6', or 'dual-stack'. + + This address family will be used together with the 'vpn-type' to + derive the appropriate Address Family Identifiers (AFIs) / + Subsequent Address Family Identifiers (SAFIs) that will be part of + the derived device configurations (e.g., unicast IPv4 MPLS L3VPN + (AFI,SAFI = 1,128) as defined in Section 4.3.4 of [RFC4364]). + + 'local-address': Specifies an address or a reference to an interface + to use when establishing the BGP transport session. + + 'neighbor': Can indicate two neighbors (each for a given address + family) or one neighbor (if the 'address-family' attribute is set + to 'dual-stack'). A list of IP address(es) of the BGP neighbor(s) + can then be conveyed in this data node. + + 'multihop': Indicates the number of allowed IP hops between a PE and + its BGP peer. + + 'as-override': If set, this parameter indicates whether ASN override + is enabled, i.e., replacing the ASN of the customer specified in + the AS_PATH BGP attribute with the ASN identified in the 'local- + as' attribute. + + 'allow-own-as': Used in some topologies (e.g., hub-and-spoke) to + allow the provider's ASN to be included in the AS_PATH BGP + attribute received from a CE. Loops are prevented by setting + 'allow-own-as' to a maximum number of the provider's ASN + occurrences. By default, this parameter is set to '0' (that is, + reject any AS_PATH attribute that includes the provider's ASN). + + 'prepend-global-as': When distinct ASNs are configured at the VPN + node and network access levels, this parameter controls whether + the ASN provided at the VPN node level is prepended to the AS_PATH + attribute. + + 'send-default-route': Controls whether default routes can be + advertised to the peer. + + 'site-of-origin': Meant to uniquely identify the set of routes + learned from a site via a particular CE-PE connection. It is used + to prevent routing loops (Section 7 of [RFC4364]). The Site of + Origin attribute is encoded as a Route Origin Extended Community. + + 'ipv6-site-of-origin': Carries an IPv6 Address Specific BGP Extended + Community that is used to indicate the Site of Origin for VRF + information [RFC5701]. It is used to prevent routing loops. + + 'redistribute-connected': Controls whether the PE-CE link is + advertised to other PEs. + + 'bgp-max-prefix': Controls the behavior when a prefix maximum is + reached. + + 'max-prefix': Indicates the maximum number of BGP prefixes + allowed in the BGP session. If the limit is reached, the + action indicated in 'violate-action' will be followed. + + 'warning-threshold': A warning notification is triggered when + this limit is reached. + + 'violate-action': Indicates which action to execute when the + maximum number of BGP prefixes is reached. Examples of such + actions include sending a warning message, discarding extra + paths from the peer, or restarting the session. + + 'restart-timer': Indicates, in seconds, the time interval after + which the BGP session will be reestablished. + + 'bgp-timers': Two timers can be captured in this container: (1) + 'hold-time', which is the time interval that will be used for the + Hold Timer (Section 4.2 of [RFC4271]) when establishing a BGP + session and (2) 'keepalive', which is the time interval for the + KeepaliveTimer between a PE and a BGP peer (Section 4.4 of + [RFC4271]). Both timers are expressed in seconds. + + 'authentication': The module adheres to the recommendations in + Section 13.2 of [RFC4364], as it allows enabling the TCP + Authentication Option (TCP-AO) [RFC5925] and accommodates the + installed base that makes use of MD5. In addition, the module + includes a provision for using IPsec. + + This version of the L3NM assumes that parameters specific to the + TCP-AO are preconfigured as part of the key chain that is + referenced in the L3NM. No assumption is made about how such a + key chain is preconfigured. However, the structure of the key + chain should cover data nodes beyond those in [RFC8177], mainly + SendID and RecvID (Section 3.1 of [RFC5925]). + + 'status': Indicates the status of the BGP routing instance. + +7.6.3.3. OSPF + + OSPF can be configured to run as a routing protocol on the 'vpn- + network-access'. + + The OSPF routing subtree structure is shown in Figure 17. + + ... + +--rw routing-protocols + | +--rw routing-protocol* [id] + | ... + | +--rw ospf + | | +--rw address-family? identityref + | | +--rw area-id yang:dotted-quad + | | +--rw metric? uint16 + | | +--rw sham-links {vpn-common:rtg-ospf-sham-link}? + | | | +--rw sham-link* [target-site] + | | | +--rw target-site string + | | | +--rw metric? uint16 + | | +--rw max-lsa? uint32 + | | +--rw authentication + | | | +--rw enable? boolean + | | | +--rw keying-material + | | | +--rw (option)? + | | | +--:(auth-key-chain) + | | | | +--rw key-chain? + | | | | key-chain:key-chain-ref + | | | +--:(auth-key-explicit) + | | | | +--rw key-id? uint32 + | | | | +--rw key? string + | | | | +--rw crypto-algorithm? + | | | | identityref + | | | +--:(ipsec) + | | | +--rw sa? string + | | +--rw status + | | +--rw admin-status + | | | +--rw status? identityref + | | | +--rw last-change? yang:date-and-time + | | +--ro oper-status + | | +--ro status? identityref + | | +--ro last-change? yang:date-and-time + ... + + Figure 17: OSPF Routing Subtree Structure + + The following data nodes are captured in Figure 17: + + 'address-family': Indicates whether IPv4, IPv6, or both address + families are to be activated. + + When the IPv4 or dual-stack address family is requested, it is up + to the implementation (e.g., network orchestrator) to decide + whether OSPFv2 [RFC4577] or OSPFv3 [RFC6565] is used to announce + IPv4 routes. Such a decision will typically be reflected in the + device configurations that will be derived to implement the L3VPN. + + 'area-id': Indicates the OSPF Area ID. + + 'metric': Associates a metric with OSPF routes. + + 'sham-links': Used to create OSPF sham links between two VPN network + accesses sharing the same area and having a backdoor link + (Section 4.2.7 of [RFC4577] and Section 5 of [RFC6565]). + + 'max-lsa': Sets the maximum number of Link State Advertisements + (LSAs) that the OSPF instance will accept. + + 'authentication': Controls the authentication schemes to be enabled + for the OSPF instance. The following options are supported: IPsec + for OSPFv3 authentication [RFC4552], and the Authentication + Trailer for OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166]. + + 'status': Indicates the status of the OSPF routing instance. + +7.6.3.4. IS-IS + + The model allows the user to configure IS-IS [ISO10589] [RFC1195] + [RFC5308] to run on the 'vpn-network-access' interface. See + Figure 18. + + ... + +--rw routing-protocols + | +--rw routing-protocol* [id] + | ... + | +--rw isis + | | +--rw address-family? identityref + | | +--rw area-address area-address + | | +--rw level? identityref + | | +--rw metric? uint16 + | | +--rw mode? enumeration + | | +--rw authentication + | | | +--rw enable? boolean + | | | +--rw keying-material + | | | +--rw (option)? + | | | +--:(auth-key-chain) + | | | | +--rw key-chain? + | | | | key-chain:key-chain-ref + | | | +--:(auth-key-explicit) + | | | +--rw key-id? uint32 + | | | +--rw key? string + | | | +--rw crypto-algorithm? identityref + | | +--rw status + | | +--rw admin-status + | | | +--rw status? identityref + | | | +--rw last-change? yang:date-and-time + | | +--ro oper-status + | | +--ro status? identityref + | | +--ro last-change? yang:date-and-time + ... + + Figure 18: IS-IS Routing Subtree Structure + + The following IS-IS data nodes are supported: + + 'address-family': Indicates whether IPv4, IPv6, or both address + families are to be activated. + + 'area-address': Indicates the IS-IS area address. + + 'level': Indicates the IS-IS level: Level 1, Level 2, or both. + + 'metric': Associates a metric with IS-IS routes. + + 'mode': Indicates the IS-IS interface mode type. It can be set to + 'active' (that is, send or receive IS-IS protocol control packets) + or 'passive' (that is, suppress the sending of IS-IS updates + through the interface). + + 'authentication': Controls the authentication schemes to be enabled + for the IS-IS instance. Both the specification of a key chain + [RFC8177] and the direct specification of key and authentication + algorithms are supported. + + 'status': Indicates the status of the IS-IS routing instance. + +7.6.3.5. RIP + + The model allows the user to configure RIP to run on the 'vpn- + network-access' interface. See Figure 19. + + ... + +--rw routing-protocols + | +--rw routing-protocol* [id] + | ... + | +--rw rip + | | +--rw address-family? identityref + | | +--rw timers + | | | +--rw update-interval? uint16 + | | | +--rw invalid-interval? uint16 + | | | +--rw holddown-interval? uint16 + | | | +--rw flush-interval? uint16 + | | +--rw default-metric? uint8 + | | +--rw authentication + | | | +--rw enable? boolean + | | | +--rw keying-material + | | | +--rw (option)? + | | | +--:(auth-key-chain) + | | | | +--rw key-chain? + | | | | key-chain:key-chain-ref + | | | +--:(auth-key-explicit) + | | | +--rw key? string + | | | +--rw crypto-algorithm? identityref + | | +--rw status + | | +--rw admin-status + | | | +--rw status? identityref + | | | +--rw last-change? yang:date-and-time + | | +--ro oper-status + | | +--ro status? identityref + | | +--ro last-change? yang:date-and-time + ... + + Figure 19: RIP Subtree Structure + + As shown in Figure 19, the following RIP data nodes are supported: + + 'address-family': Indicates whether IPv4, IPv6, or both address + families are to be activated. This parameter is used to determine + whether RIPv2 [RFC2453], RIP Next Generation (RIPng), or both are + to be enabled [RFC2080]. + + 'timers': Indicates the following timers: + + 'update-interval': The interval at which RIP updates are sent. + + 'invalid-interval': The interval before a RIP route is declared + invalid. + + 'holddown-interval': The interval before better RIP routes are + released. + + 'flush-interval': The interval before a route is removed from the + routing table. + + These timers are expressed in seconds. + + 'default-metric': Sets the default RIP metric. + + 'authentication': Controls the authentication schemes to be enabled + for the RIP instance. + + 'status': Indicates the status of the RIP routing instance. + +7.6.3.6. VRRP + + The model allows enabling the Virtual Router Redundancy Protocol + (VRRP) on the 'vpn-network-access' interface. See Figure 20. + + ... + +--rw routing-protocols + | +--rw routing-protocol* [id] + | ... + | +--rw vrrp + | +--rw address-family* identityref + | +--rw vrrp-group? uint8 + | +--rw backup-peer? inet:ip-address + | +--rw virtual-ip-address* inet:ip-address + | +--rw priority? uint8 + | +--rw ping-reply? boolean + | +--rw status + | +--rw admin-status + | | +--rw status? identityref + | | +--rw last-change? yang:date-and-time + | +--ro oper-status + | +--ro status? identityref + | +--ro last-change? yang:date-and-time + ... + + Figure 20: VRRP Subtree Structure + + The following data nodes are supported: + + 'address-family': Indicates whether IPv4, IPv6, or both address + families are to be activated. Note that VRRP version 3 [RFC5798] + supports both IPv4 and IPv6. + + 'vrrp-group': Used to identify the VRRP group. + + 'backup-peer': Carries the IP address of the peer. + + 'virtual-ip-address': Includes virtual IP addresses for a single + VRRP group. + + 'priority': Assigns the VRRP election priority for the backup + virtual router. + + 'ping-reply': Controls whether the VRRP speaker should reply to ping + requests. + + 'status': Indicates the status of the VRRP instance. + + Note that no authentication data node is included for VRRP, as there + isn't any type of VRRP authentication at this time (see Section 9 of + [RFC5798]). + +7.6.4. OAM + + This container (Figure 21) defines the Operations, Administration, + and Maintenance (OAM) mechanisms used for a VPN network access. In + the current version of the L3NM, only BFD is supported. + + ... + +--rw oam + | +--rw bfd {vpn-common:bfd}? + | +--rw session-type? identityref + | +--rw desired-min-tx-interval? uint32 + | +--rw required-min-rx-interval? uint32 + | +--rw local-multiplier? uint8 + | +--rw holdtime? uint32 + | +--rw profile? leafref + | +--rw authentication! + | | +--rw key-chain? key-chain:key-chain-ref + | | +--rw meticulous? boolean + | +--rw status + | +--rw admin-status + | | +--rw status? identityref + | | +--rw last-change? yang:date-and-time + | +--ro oper-status + | +--ro status? identityref + | +--ro last-change? yang:date-and-time + ... + + Figure 21: IP Connection Subtree Structure (OAM) + + The following OAM data nodes can be specified: + + 'session-type': Indicates which BFD flavor is used to set up the + session (e.g., classic BFD [RFC5880], Seamless BFD [RFC7880]). By + default, it is assumed that the BFD session will follow the + behavior specified in [RFC5880]. + + 'desired-min-tx-interval': The minimum interval, in microseconds, + that a PE would like to use when transmitting BFD Control packets, + less any jitter applied. + + 'required-min-rx-interval': The minimum interval, in microseconds, + between received BFD Control packets that a PE is capable of + supporting, less any jitter applied by the sender. + + 'local-multiplier': The negotiated transmit interval, multiplied by + this value, provides the detection time for the peer. + + 'holdtime': Used to indicate the expected BFD holddown time, in + milliseconds. This value may be inherited from the service + request (see Section 6.3.2.2.2 of [RFC8299]). + + 'profile': Refers to a BFD profile (Section 7.2). Such a profile + can be set by the provider or inherited from the service request + (see Section 6.3.2.2.2 of [RFC8299]). + + 'authentication': Includes the required information to enable the + BFD authentication modes discussed in Section 6.7 of [RFC5880]. + In particular, 'meticulous' controls the activation of meticulous + mode as discussed in Sections 6.7.3 and 6.7.4 of [RFC5880]. + + 'status': Indicates the status of BFD. + +7.6.5. Security + + The 'security' container specifies the authentication and the + encryption to be applied to traffic for a given VPN network access. + As depicted in the subtree shown in Figure 22, the L3NM can be used + to directly control the encryption to be applied (e.g., Layer 2 or + Layer 3 encryption) or invoke a local encryption profile. + + ... + +--rw vpn-services + +--rw vpn-service* [vpn-id] + ... + +--rw vpn-nodes + +--rw vpn-node* [vpn-node-id] + ... + +--rw vpn-network-accesses + +--rw vpn-network-access* [id] + ... + +--rw security + | +--rw encryption {vpn-common:encryption}? + | | +--rw enabled? boolean + | | +--rw layer? enumeration + | +--rw encryption-profile + | +--rw (profile)? + | +--:(provider-profile) + | | +--rw profile-name? leafref + | +--:(customer-profile) + | +--rw customer-key-chain? + | key-chain:key-chain-ref + +--rw service + ... + + Figure 22: Security Subtree Structure + +7.6.6. Services + +7.6.6.1. Overview + + The 'service' container specifies the service parameters to apply for + a given VPN network access (Figure 23). + + ... + +--rw vpn-network-accesses + +--rw vpn-network-access* [id] + ... + +--rw service + +--rw pe-to-ce-bandwidth? uint64 {vpn-common:inbound-bw}? + +--rw ce-to-pe-bandwidth? uint64 {vpn-common:outbound-bw}? + +--rw mtu? uint32 + +--rw qos {vpn-common:qos}? + | ... + +--rw carriers-carrier + | {vpn-common:carriers-carrier}? + | +--rw signaling-type? enumeration + +--rw ntp + | +--rw broadcast? enumeration + | +--rw auth-profile + | | +--rw profile-id? string + | +--rw status + | +--rw admin-status + | | +--rw status? identityref + | | +--rw last-change? yang:date-and-time + | +--ro oper-status + | +--ro status? identityref + | +--ro last-change? yang:date-and-time + +--rw multicast {vpn-common:multicast}? + ... + + Figure 23: Services Subtree Structure + + The following data nodes are defined: + + 'pe-to-ce-bandwidth': Indicates, in bits per second (bps), the + inbound bandwidth of the connection (i.e., the download bandwidth + from the service provider to the site). + + 'ce-to-pe-bandwidth': Indicates, in bps, the outbound bandwidth of + the connection (i.e., the upload bandwidth from the site to the + service provider). + + 'mtu': Indicates the MTU at the service level. + + 'qos': Used to define a set of QoS policies to apply on a given + connection (refer to Section 7.6.6.2 for more details). + + 'carriers-carrier': Groups a set of parameters that are used when + Carriers' Carriers (CsC) is enabled, such as using BGP for + signaling purposes [RFC8277]. + + 'ntp': Time synchronization may be needed in some VPNs, such as + infrastructure and management VPNs. This container is used to + enable the NTP service [RFC5905]. + + 'multicast': Specifies the multicast mode and other data nodes, such + as the address family. Refer to Section 7.7. + +7.6.6.2. QoS + + The 'qos' container is used to define a set of QoS policies to apply + on a given connection (Figure 24). A QoS policy may be a + classification or an action policy. For example, a QoS action can be + defined to rate-limit inbound/outbound traffic of a given class of + service. + + ... + +--rw qos {vpn-common:qos}? + | +--rw qos-classification-policy + | | +--rw rule* [id] + | | +--rw id string + | | +--rw (match-type)? + | | | +--:(match-flow) + | | | | +--rw (l3)? + | | | | | +--:(ipv4) + | | | | | | ... + | | | | | +--:(ipv6) + | | | | | ... + | | | | +--rw (l4)? + | | | | +--:(tcp) + | | | | | ... + | | | | +--:(udp) + | | | | ... + | | | +--:(match-application) + | | | +--rw match-application? + | | | identityref + | | +--rw target-class-id? string + | +--rw qos-action + | | +--rw rule* [id] + | | +--rw id string + | | +--rw target-class-id? string + | | +--rw inbound-rate-limit? decimal64 + | | +--rw outbound-rate-limit? decimal64 + | +--rw qos-profile + | +--rw qos-profile* [profile] + | +--rw profile leafref + | +--rw direction? identityref + ... + + Figure 24: Overall QoS Subtree Structure + + QoS classification can be based on many criteria, such as the + following: + + Layer 3: As shown in Figure 25, classification can be based on any + IP header field or a combination thereof. Both IPv4 and IPv6 are + supported. + + +--rw qos {vpn-common:qos}? + | +--rw qos-classification-policy + | | +--rw rule* [id] + | | +--rw id string + | | +--rw (match-type)? + | | | +--:(match-flow) + | | | | +--rw (l3)? + | | | | | +--:(ipv4) + | | | | | | +--rw ipv4 + | | | | | | +--rw dscp? inet:dscp + | | | | | | +--rw ecn? uint8 + | | | | | | +--rw length? uint16 + | | | | | | +--rw ttl? uint8 + | | | | | | +--rw protocol? uint8 + | | | | | | +--rw ihl? uint8 + | | | | | | +--rw flags? bits + | | | | | | +--rw offset? uint16 + | | | | | | +--rw identification? uint16 + | | | | | | +--rw (destination-network)? + | | | | | | | +--:(destination-ipv4-network) + | | | | | | | +--rw destination-ipv4-network? + | | | | | | | inet:ipv4-prefix + | | | | | | +--rw (source-network)? + | | | | | | +--:(source-ipv4-network) + | | | | | | +--rw source-ipv4-network? + | | | | | | inet:ipv4-prefix + | | | | | +--:(ipv6) + | | | | | +--rw ipv6 + | | | | | +--rw dscp? inet:dscp + | | | | | +--rw ecn? uint8 + | | | | | +--rw length? uint16 + | | | | | +--rw ttl? uint8 + | | | | | +--rw protocol? uint8 + | | | | | +--rw (destination-network)? + | | | | | | +--:(destination-ipv6-network) + | | | | | | +--rw destination-ipv6-network? + | | | | | | inet:ipv6-prefix + | | | | | +--rw (source-network)? + | | | | | | +--:(source-ipv6-network) + | | | | | | +--rw source-ipv6-network? + | | | | | | inet:ipv6-prefix + | | | | | +--rw flow-label? + | | | | | inet:ipv6-flow-label + ... + + Figure 25: QoS Subtree Structure (L3) + + Layer 4: As discussed in [RFC9181], any Layer 4 protocol can be + indicated in the 'protocol' data node under 'l3' (Figure 25), but + only TCP- and UDP-specific match criteria are elaborated in this + version, as these protocols are widely used in the context of VPN + services. Augmentations can be considered in the future to add + other Layer-4-specific data nodes, if needed. + + TCP- or UDP-related match criteria can be specified in the L3NM, + as shown in Figure 26. + + As discussed in [RFC9181], some transport protocols use existing + protocols (e.g., TCP or UDP) as the substrate. The match criteria + for such protocols may rely upon the 'protocol' setting under + 'l3', TCP/UDP match criteria as shown in Figure 26, part of the + TCP/UDP payload, or a combination thereof. This version of the + module does not support such advanced match criteria. Future + revisions of the VPN common module or augmentations to the L3NM + may consider adding match criteria based on the transport protocol + payload (e.g., by means of a bitmask match). + + +--rw qos {vpn-common:qos}? + | +--rw qos-classification-policy + | | +--rw rule* [id] + | | +--rw id string + | | +--rw (match-type)? + | | | +--:(match-flow) + | | | | +--rw (l3)? + | | | | | ... + | | | | +--rw (l4)? + | | | | +--:(tcp) + | | | | | +--rw tcp + | | | | | +--rw sequence-number? uint32 + | | | | | +--rw acknowledgement-number? uint32 + | | | | | +--rw data-offset? uint8 + | | | | | +--rw reserved? uint8 + | | | | | +--rw flags? bits + | | | | | +--rw window-size? uint16 + | | | | | +--rw urgent-pointer? uint16 + | | | | | +--rw options? binary + | | | | | +--rw (source-port)? + | | | | | | +--:(source-port-range-or-operator) + | | | | | | +--rw source-port-range-or-operator + | | | | | | +--rw (port-range-or-operator)? + | | | | | | +--:(range) + | | | | | | | +--rw lower-port + | | | | | | | | inet:port-number + | | | | | | | +--rw upper-port + | | | | | | | inet:port-number + | | | | | | +--:(operator) + | | | | | | +--rw operator? operator + | | | | | | +--rw port + | | | | | | inet:port-number + | | | | | +--rw (destination-port)? + | | | | | +--:(destination-port-range-or-operator) + | | | | | +--rw destination-port-range-or-operator + | | | | | +--rw (port-range-or-operator)? + | | | | | +--:(range) + | | | | | | +--rw lower-port + | | | | | | | inet:port-number + | | | | | | +--rw upper-port + | | | | | | inet:port-number + | | | | | +--:(operator) + | | | | | +--rw operator? operator + | | | | | +--rw port + | | | | | inet:port-number + | | | | +--:(udp) + | | | | +--rw udp + | | | | +--rw length? uint16 + | | | | +--rw (source-port)? + | | | | | +--:(source-port-range-or-operator) + | | | | | +--rw source-port-range-or-operator + | | | | | +--rw (port-range-or-operator)? + | | | | | +--:(range) + | | | | | | +--rw lower-port + | | | | | | | inet:port-number + | | | | | | +--rw upper-port + | | | | | | inet:port-number + | | | | | +--:(operator) + | | | | | +--rw operator? operator + | | | | | +--rw port + | | | | | inet:port-number + | | | | +--rw (destination-port)? + | | | | +--:(destination-port-range-or-operator) + | | | | +--rw destination-port-range-or-operator + | | | | +--rw (port-range-or-operator)? + | | | | +--:(range) + | | | | | +--rw lower-port + | | | | | | inet:port-number + | | | | | +--rw upper-port + | | | | | inet:port-number + | | | | +--:(operator) + | | | | +--rw operator? operator + | | | | +--rw port + | | | | inet:port-number + ... + + Figure 26: QoS Subtree Structure (L4) + + Application match: Relies upon application-specific classification + (Figure 24). + +7.7. Multicast + + Multicast may be enabled for a particular VPN at the VPN node and VPN + network access levels (see Figure 27). Some data nodes (e.g., max- + groups (Figure 28)) can be controlled at various levels: VPN service, + VPN node level, or VPN network access. + + ... + +--rw vpn-services + +--rw vpn-service* [vpn-id] + ... + +--rw vpn-instance-profiles + | +--rw vpn-instance-profile* [profile-id] + | .... + | +--rw multicast {vpn-common:multicast}? + | ... + +--rw vpn-nodes + +--rw vpn-node* [vpn-node-id] + ... + +--rw active-vpn-instance-profiles + | +--rw vpn-instance-profile* [profile-id] + | ... + | +--rw multicast {vpn-common:multicast}? + | ... + +--rw vpn-network-accesses + +--rw vpn-network-access* [id] + ... + +--rw service + ... + +--rw multicast {vpn-common:multicast}? + ... + + Figure 27: Overall Multicast Subtree Structure + + Multicast-related data nodes at the VPN instance profile level have + the structure shown in Figure 28. + + ... + +--rw vpn-services + +--rw vpn-service* [vpn-id] + ... + +--rw vpn-instance-profiles + | +--rw vpn-instance-profile* [profile-id] + | .... + | +--rw multicast {vpn-common:multicast}? + | +--rw tree-flavor? identityref + | +--rw rp + | | +--rw rp-group-mappings + | | | +--rw rp-group-mapping* [id] + | | | +--rw id uint16 + | | | +--rw provider-managed + | | | | +--rw enabled? boolean + | | | | +--rw rp-redundancy? boolean + | | | | +--rw optimal-traffic-delivery? boolean + | | | | +--rw anycast + | | | | +--rw local-address? inet:ip-address + | | | | +--rw rp-set-address* inet:ip-address + | | | +--rw rp-address inet:ip-address + | | | +--rw groups + | | | +--rw group* [id] + | | | +--rw id uint16 + | | | +--rw (group-format) + | | | +--:(group-prefix) + | | | | +--rw group-address? + | | | | inet:ip-prefix + | | | +--:(startend) + | | | +--rw group-start? + | | | | inet:ip-address + | | | +--rw group-end? + | | | | inet:ip-address + | | +--rw rp-discovery + | | +--rw rp-discovery-type? identityref + | | +--rw bsr-candidates + | | +--rw bsr-candidate-address* + | | | inet:ip-address + | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? + | | +--rw static-group* [group-addr] + | | | +--rw group-addr + | | | | rt-types:ipv4-multicast-group-address + | | | +--rw source-addr? + | | | rt-types:ipv4-multicast-source-address + | | +--rw max-groups? uint32 + | | +--rw max-entries? uint32 + | | +--rw version? identityref + | +--rw mld {vpn-common:mld and vpn-common:ipv6}? + | | +--rw static-group* [group-addr] + | | | +--rw group-addr + | | | | rt-types:ipv6-multicast-group-address + | | | +--rw source-addr? + | | | rt-types:ipv6-multicast-source-address + | | +--rw max-groups? uint32 + | | +--rw max-entries? uint32 + | | +--rw version? identityref + | +--rw pim {vpn-common:pim}? + | +--rw hello-interval? + | | rt-types:timer-value-seconds16 + | +--rw dr-priority? uint32 + ... + + Figure 28: Multicast Subtree Structure (VPN Instance Profile Level) + + The model supports a single type of tree per VPN access ('tree- + flavor'): Any-Source Multicast (ASM), Source-Specific Multicast + (SSM), or bidirectional. + + When ASM is used, the model supports the configuration of Rendezvous + Points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'. + When set to 'static', RP-to-multicast-group mappings MUST be + configured as part of the 'rp-group-mappings' container. The RP MAY + be a provider node or a customer node. When the RP is a customer + node, the RP address must be configured using the 'rp-address' leaf. + + The model supports RP redundancy through the 'rp-redundancy' leaf. + How the redundancy is achieved is out of scope. + + When a particular VPN using ASM requires traffic delivery that is + more optimal (e.g., requested per the guidance in [RFC8299]), + 'optimal-traffic-delivery' can be set. When set to 'true', the + implementation must use any mechanism to provide traffic delivery + that is more optimal for the customer. For example, anycast is one + of the mechanisms for enhancing RP redundancy, providing resilience + against failures, and recovering from failures quickly. + + When configuring multicast-related parameters at the VPN node level + (Figure 29), the same structure as the structure depicted in + Figure 30 is used. When defined at the VPN node level, Internet + Group Management Protocol (IGMP) parameters [RFC1112] [RFC2236] + [RFC3376], Multicast Listener Discovery (MLD) parameters [RFC2710] + [RFC3810], and Protocol Independent Multicast (PIM) parameters + [RFC7761] are applicable to all VPN network accesses of that VPN node + unless corresponding nodes are overridden at the VPN network access + level. + + ... + +--rw vpn-nodes + +--rw vpn-node* [vpn-node-id] + ... + +--rw active-vpn-instance-profiles + | +--rw vpn-instance-profile* [profile-id] + | ... + | +--rw multicast {vpn-common:multicast}? + | +--rw tree-flavor* identityref + | +--rw rp + | | ... + | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? + | | ... + | +--rw mld {vpn-common:mld and vpn-common:ipv6}? + | | ... + | +--rw pim {vpn-common:pim}? + | ... + + Figure 29: Multicast Subtree Structure (VPN Node Level) + + Multicast-related data nodes at the VPN network access level are + shown in Figure 30. The values configured at the VPN network access + level override the values configured for the corresponding data nodes + at other levels. + + ... + +--rw vpn-network-accesses + +--rw vpn-network-access* [id] + ... + +--rw service + ... + +--rw multicast {vpn-common:multicast}? + +--rw access-type? enumeration + +--rw address-family? identityref + +--rw protocol-type? enumeration + +--rw remote-source? boolean + +--rw igmp {vpn-common:igmp}? + | +--rw static-group* [group-addr] + | | +--rw group-addr + | | rt-types:ipv4-multicast-group-address + | | +--rw source-addr? + | | rt-types:ipv4-multicast-source-address + | +--rw max-groups? uint32 + | +--rw max-entries? uint32 + | +--rw max-group-sources? uint32 + | +--rw version? identityref + | +--rw status + | +--rw admin-status + | | +--rw status? identityref + | | +--rw last-change? yang:date-and-time + | +--ro oper-status + | +--ro status? identityref + | +--ro last-change? yang:date-and-time + +--rw mld {vpn-common:mld}? + | +--rw static-group* [group-addr] + | | +--rw group-addr + | | rt-types:ipv6-multicast-group-address + | | +--rw source-addr? + | | rt-types:ipv6-multicast-source-address + | +--rw max-groups? uint32 + | +--rw max-entries? uint32 + | +--rw max-group-sources? uint32 + | +--rw version? identityref + | +--rw status + | +--rw admin-status + | | +--rw status? identityref + | | +--rw last-change? yang:date-and-time + | +--ro oper-status + | +--ro status? identityref + | +--ro last-change? yang:date-and-time + +--rw pim {vpn-common:pim}? + +--rw hello-interval? rt-types:timer-value-seconds16 + +--rw dr-priority? uint32 + +--rw status + +--rw admin-status + | +--rw status? identityref + | +--rw last-change? yang:date-and-time + +--ro oper-status + +--ro status? identityref + +--ro last-change? yang:date-and-time + + Figure 30: Multicast Subtree Structure (VPN Network Access Level) + +8. L3NM YANG Module + + This module uses types defined in [RFC6991], [RFC8343], and + [RFC9181]. It also uses groupings defined in [RFC8519], [RFC8177], + and [RFC8294]. + + <CODE BEGINS> file "ietf-l3vpn-ntw@2022-02-14.yang" + module ietf-l3vpn-ntw { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; + prefix l3nm; + + import ietf-vpn-common { + prefix vpn-common; + reference + "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 + VPNs"; + } + import ietf-inet-types { + prefix inet; + reference + "RFC 6991: Common YANG Data Types, Section 4"; + } + import ietf-yang-types { + prefix yang; + reference + "RFC 6991: Common YANG Data Types, Section 3"; + } + import ietf-key-chain { + prefix key-chain; + reference + "RFC 8177: YANG Data Model for Key Chains"; + } + import ietf-routing-types { + prefix rt-types; + reference + "RFC 8294: Common YANG Data Types for the Routing Area"; + } + import ietf-interfaces { + prefix if; + reference + "RFC 8343: A YANG Data Model for Interface Management"; + } + + organization + "IETF OPSAWG (Operations and Management Area Working Group)"; + contact + "WG Web: <https://datatracker.ietf.org/wg/opsawg/> + WG List: <mailto:opsawg@ietf.org> + + Author: Samier Barguil + <mailto:samier.barguilgiraldo.ext@telefonica.com> + Editor: Oscar Gonzalez de Dios + <mailto:oscar.gonzalezdedios@telefonica.com> + Editor: Mohamed Boucadair + <mailto:mohamed.boucadair@orange.com> + Author: Luis Angel Munoz + <mailto:luis-angel.munoz@vodafone.com> + Author: Alejandro Aguado + <mailto:alejandro.aguado_martin@nokia.com>"; + description + "This YANG module defines a generic network-oriented model + for the configuration of Layer 3 Virtual Private Networks. + + Copyright (c) 2022 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 Revised 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 9182; see the + RFC itself for full legal notices."; + + revision 2022-02-14 { + description + "Initial revision."; + reference + "RFC 9182: A YANG Network Data Model for Layer 3 VPNs"; + } + + /* Features */ + + feature msdp { + description + "This feature indicates that Multicast Source Discovery + Protocol (MSDP) capabilities are supported by the VPN."; + reference + "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; + } + + /* Identities */ + + identity address-allocation-type { + description + "Base identity for address allocation type in the + Provider Edge to Customer Edge (PE-CE) link."; + } + + identity provider-dhcp { + base address-allocation-type; + description + "The provider's network provides a DHCP service to the + customer."; + } + + identity provider-dhcp-relay { + base address-allocation-type; + description + "The provider's network provides a DHCP relay service to the + customer."; + } + + identity provider-dhcp-slaac { + if-feature "vpn-common:ipv6"; + base address-allocation-type; + description + "The provider's network provides a DHCP service to the + customer as well as IPv6 Stateless Address + Autoconfiguration (SLAAC)."; + reference + "RFC 4862: IPv6 Stateless Address Autoconfiguration"; + } + + identity static-address { + base address-allocation-type; + description + "The provider's network provides static IP addressing to the + customer."; + } + + identity slaac { + if-feature "vpn-common:ipv6"; + base address-allocation-type; + description + "The provider's network uses IPv6 SLAAC to provide + addressing to the customer."; + reference + "RFC 4862: IPv6 Stateless Address Autoconfiguration"; + } + + identity local-defined-next-hop { + description + "Base identity of local defined next hops."; + } + + identity discard { + base local-defined-next-hop; + description + "Indicates an action to discard traffic for the + corresponding destination. + For example, this can be used to black-hole traffic."; + } + + identity local-link { + base local-defined-next-hop; + description + "Treat traffic towards addresses within the specified + next-hop prefix as though they are connected to a local + link."; + } + + identity l2-tunnel-type { + description + "Base identity for Layer 2 tunnel selection under the VPN + network access."; + } + + identity pseudowire { + base l2-tunnel-type; + description + "Pseudowire tunnel termination in the VPN network access."; + } + + identity vpls { + base l2-tunnel-type; + description + "Virtual Private LAN Service (VPLS) tunnel termination in + the VPN network access."; + } + + identity vxlan { + base l2-tunnel-type; + description + "Virtual eXtensible Local Area Network (VXLAN) tunnel + termination in the VPN network access."; + } + + /* Typedefs */ + + typedef predefined-next-hop { + type identityref { + base local-defined-next-hop; + } + description + "Predefined next-hop designation for locally generated + routes."; + } + + typedef area-address { + type string { + pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; + } + description + "This type defines the area address format."; + } + + /* Groupings */ + + grouping vpn-instance-profile { + description + "Grouping for data nodes that may be factorized + among many levels of the model. The grouping can + be used to define generic profiles at the VPN service + level and then referenced at the VPN node and VPN + network access levels."; + leaf local-as { + if-feature "vpn-common:rtg-bgp"; + type inet:as-number; + description + "Provider's Autonomous System (AS) number. Used if the + customer requests BGP routing."; + } + uses vpn-common:route-distinguisher; + list address-family { + key "address-family"; + description + "Set of parameters per address family."; + leaf address-family { + type identityref { + base vpn-common:address-family; + } + description + "Indicates the address family (IPv4 and/or IPv6)."; + } + container vpn-targets { + description + "Set of route targets to match for import and export + routes to/from VRF."; + uses vpn-common:vpn-route-targets; + } + list maximum-routes { + key "protocol"; + description + "Defines the maximum number of routes for VRF."; + leaf protocol { + type identityref { + base vpn-common:routing-protocol-type; + } + description + "Indicates the routing protocol. A value of 'any' + can be used to identify a limit that will apply for + each active routing protocol."; + } + leaf maximum-routes { + type uint32; + description + "Indicates the maximum number of prefixes that VRF can + accept for this address family and protocol."; + } + } + } + container multicast { + if-feature "vpn-common:multicast"; + description + "Global multicast parameters."; + leaf tree-flavor { + type identityref { + base vpn-common:multicast-tree-type; + } + description + "Type of the multicast tree to be used."; + } + container rp { + description + "Rendezvous Point (RP) parameters."; + container rp-group-mappings { + description + "RP-to-group mapping parameters."; + list rp-group-mapping { + key "id"; + description + "List of RP-to-group mappings."; + leaf id { + type uint16; + description + "Unique identifier for the mapping."; + } + container provider-managed { + description + "Parameters for a provider-managed RP."; + leaf enabled { + type boolean; + default "false"; + description + "Set to 'true' if the RP must be a + provider-managed node. Set to 'false' if it is + a customer-managed node."; + } + leaf rp-redundancy { + type boolean; + default "false"; + description + "If set to 'true', it indicates that a + redundancy mechanism for the RP is required."; + } + leaf optimal-traffic-delivery { + type boolean; + default "false"; + description + "If set to 'true', the service provider (SP) + must ensure that the traffic uses an optimal + path. An SP may use Anycast RP or + RP-tree-to-SPT ('SPT' is 'shortest path tree') + switchover architectures."; + } + container anycast { + when "../rp-redundancy = 'true' and + ../optimal-traffic-delivery = 'true'" { + description + "Only applicable if both RP redundancy and + delivery through an optimal path are + activated."; + } + description + "PIM Anycast-RP parameters."; + leaf local-address { + type inet:ip-address; + description + "IP local address for the PIM RP. Usually + corresponds to the Router ID or the + primary address."; + } + leaf-list rp-set-address { + type inet:ip-address; + description + "Specifies the IP address of other RP routers + that share the same RP IP address."; + } + } + } + leaf rp-address { + when "../provider-managed/enabled = 'false'" { + description + "Relevant when the RP is not managed by the + provider."; + } + type inet:ip-address; + mandatory true; + description + "Defines the address of the RP. + Used if the RP is managed by the customer."; + } + container groups { + description + "Multicast groups associated with the RP."; + list group { + key "id"; + description + "List of multicast groups."; + leaf id { + type uint16; + description + "Identifier for the group."; + } + choice group-format { + mandatory true; + description + "Choice for multicast group format."; + case group-prefix { + leaf group-address { + type inet:ip-prefix; + description + "A single multicast group prefix."; + } + } + case startend { + leaf group-start { + type inet:ip-address; + description + "The first multicast group address in + the multicast group address range."; + } + leaf group-end { + type inet:ip-address; + description + "The last multicast group address in + the multicast group address range."; + } + } + } + } + } + } + } + container rp-discovery { + description + "RP discovery parameters."; + leaf rp-discovery-type { + type identityref { + base vpn-common:multicast-rp-discovery-type; + } + default "vpn-common:static-rp"; + description + "Type of RP discovery used."; + } + container bsr-candidates { + when "derived-from-or-self(../rp-discovery-type, " + + "'vpn-common:bsr-rp')" { + description + "Only applicable if the discovery type + is 'bsr-rp'."; + } + description + "Container for the customer Bootstrap Router (BSR) + candidate's addresses."; + leaf-list bsr-candidate-address { + type inet:ip-address; + description + "Specifies the address of the candidate BSR."; + } + } + } + } + container igmp { + if-feature "vpn-common:igmp and vpn-common:ipv4"; + description + "Includes IGMP-related parameters."; + list static-group { + key "group-addr"; + description + "Multicast static source/group associated with the + IGMP session."; + leaf group-addr { + type rt-types:ipv4-multicast-group-address; + description + "Multicast group IPv4 address."; + } + leaf source-addr { + type rt-types:ipv4-multicast-source-address; + description + "Multicast source IPv4 address."; + } + } + leaf max-groups { + type uint32; + description + "Indicates the maximum number of groups."; + } + leaf max-entries { + type uint32; + description + "Indicates the maximum number of IGMP entries."; + } + leaf version { + type identityref { + base vpn-common:igmp-version; + } + default "vpn-common:igmpv2"; + description + "Indicates the IGMP version."; + reference + "RFC 1112: Host Extensions for IP Multicasting + RFC 2236: Internet Group Management Protocol, + Version 2 + RFC 3376: Internet Group Management Protocol, + Version 3"; + } + } + container mld { + if-feature "vpn-common:mld and vpn-common:ipv6"; + description + "Includes MLD-related parameters."; + list static-group { + key "group-addr"; + description + "Multicast static source/group associated with the + MLD session."; + leaf group-addr { + type rt-types:ipv6-multicast-group-address; + description + "Multicast group IPv6 address."; + } + leaf source-addr { + type rt-types:ipv6-multicast-source-address; + description + "Multicast source IPv6 address."; + } + } + leaf max-groups { + type uint32; + description + "Indicates the maximum number of groups."; + } + leaf max-entries { + type uint32; + description + "Indicates the maximum number of MLD entries."; + } + leaf version { + type identityref { + base vpn-common:mld-version; + } + default "vpn-common:mldv2"; + description + "Indicates the MLD protocol version."; + reference + "RFC 2710: Multicast Listener Discovery (MLD) for IPv6 + RFC 3810: Multicast Listener Discovery Version 2 + (MLDv2) for IPv6"; + } + } + container pim { + if-feature "vpn-common:pim"; + description + "Only applies when the protocol type is 'pim'."; + leaf hello-interval { + type rt-types:timer-value-seconds16; + default "30"; + description + "Interval between PIM Hello messages. If set to + 'infinity' or 'not-set', no periodic Hello messages + are sent."; + reference + "RFC 7761: Protocol Independent Multicast - Sparse + Mode (PIM-SM): Protocol Specification + (Revised), Section 4.11 + RFC 8294: Common YANG Data Types for the Routing + Area"; + } + leaf dr-priority { + type uint32; + default "1"; + description + "Indicates the preference associated with the + Designated Router (DR) election process. A larger + value has a higher priority over a smaller value."; + reference + "RFC 7761: Protocol Independent Multicast - Sparse + Mode (PIM-SM): Protocol Specification + (Revised), Section 4.3.2"; + } + } + } + } + + /* Main Blocks */ + /* Main l3vpn-ntw */ + + container l3vpn-ntw { + description + "Main container for management of Layer 3 Virtual Private + Network (L3VPN) services."; + container vpn-profiles { + description + "Contains a set of valid VPN profiles to reference + in the VPN service."; + uses vpn-common:vpn-profile-cfg; + } + container vpn-services { + description + "Container for the VPN services."; + list vpn-service { + key "vpn-id"; + description + "List of VPN services."; + uses vpn-common:vpn-description; + leaf parent-service-id { + type vpn-common:vpn-id; + description + "Pointer to the parent service, if any. + A parent service can be an L3SM, a slice request, + a VPN+ service, etc."; + } + leaf vpn-type { + type identityref { + base vpn-common:service-type; + } + description + "Indicates the service type."; + } + leaf vpn-service-topology { + type identityref { + base vpn-common:vpn-topology; + } + default "vpn-common:any-to-any"; + description + "VPN service topology."; + } + uses vpn-common:service-status; + container vpn-instance-profiles { + description + "Container for a list of VPN instance profiles."; + list vpn-instance-profile { + key "profile-id"; + description + "List of VPN instance profiles."; + leaf profile-id { + type string; + description + "VPN instance profile identifier."; + } + leaf role { + type identityref { + base vpn-common:role; + } + default "vpn-common:any-to-any-role"; + description + "Role of the VPN node in the VPN."; + } + uses vpn-instance-profile; + } + } + container underlay-transport { + description + "Container for the underlay transport."; + uses vpn-common:underlay-transport; + } + container external-connectivity { + if-feature "vpn-common:external-connectivity"; + description + "Container for external connectivity."; + choice profile { + description + "Choice for the external connectivity profile."; + case profile { + leaf profile-name { + type leafref { + path "/l3vpn-ntw/vpn-profiles" + + "/valid-provider-identifiers" + + "/external-connectivity-identifier/id"; + } + description + "Name of the service provider's profile to be + applied at the VPN service level."; + } + } + } + } + container vpn-nodes { + description + "Container for VPN nodes."; + list vpn-node { + key "vpn-node-id"; + description + "Includes a list of VPN nodes."; + leaf vpn-node-id { + type vpn-common:vpn-id; + description + "An identifier of the VPN node."; + } + leaf description { + type string; + description + "Textual description of the VPN node."; + } + leaf ne-id { + type string; + description + "Unique identifier of the network element where + the VPN node is deployed."; + } + leaf local-as { + if-feature "vpn-common:rtg-bgp"; + type inet:as-number; + description + "Provider's AS number. Used if the customer + requests BGP routing."; + } + leaf router-id { + type rt-types:router-id; + description + "A 32-bit number in the dotted-quad format that is + used to uniquely identify a node within an AS. + This identifier is used for both IPv4 and IPv6."; + } + container active-vpn-instance-profiles { + description + "Container for active VPN instance profiles."; + list vpn-instance-profile { + key "profile-id"; + description + "Includes a list of active VPN instance + profiles."; + leaf profile-id { + type leafref { + path "/l3vpn-ntw/vpn-services/vpn-service" + + "/vpn-instance-profiles" + + "/vpn-instance-profile/profile-id"; + } + description + "Node's active VPN instance profile."; + } + list router-id { + key "address-family"; + description + "Router ID per address family."; + leaf address-family { + type identityref { + base vpn-common:address-family; + } + description + "Indicates the address family for which the + Router ID applies."; + } + leaf router-id { + type inet:ip-address; + description + "The 'router-id' information can be an IPv4 + or IPv6 address. This can be used, + for example, to configure an IPv6 address + as a Router ID when such a capability is + supported by underlay routers. In such a + case, the configured value overrides the + generic value defined at the VPN node + level."; + } + } + uses vpn-instance-profile; + } + } + container msdp { + if-feature "msdp"; + description + "Includes MSDP-related parameters."; + leaf peer { + type inet:ipv4-address; + description + "Indicates the IPv4 address of the MSDP peer."; + } + leaf local-address { + type inet:ipv4-address; + description + "Indicates the IPv4 address of the local end. + This local address must be configured on + the node."; + } + uses vpn-common:service-status; + } + uses vpn-common:vpn-components-group; + uses vpn-common:service-status; + container vpn-network-accesses { + description + "List of network accesses."; + list vpn-network-access { + key "id"; + description + "List of network accesses."; + leaf id { + type vpn-common:vpn-id; + description + "Identifier for the network access."; + } + leaf interface-id { + type string; + description + "Identifier for the physical or logical + interface. + The identification of the sub-interface + is provided at the connection level and/or + the IP connection level."; + } + leaf description { + type string; + description + "Textual description of the network access."; + } + leaf vpn-network-access-type { + type identityref { + base vpn-common:site-network-access-type; + } + default "vpn-common:point-to-point"; + description + "Describes the type of connection, e.g., + point to point."; + } + leaf vpn-instance-profile { + type leafref { + path "/l3vpn-ntw/vpn-services/vpn-service" + + "/vpn-nodes/vpn-node" + + "/active-vpn-instance-profiles" + + "/vpn-instance-profile/profile-id"; + } + description + "An identifier of an active VPN instance + profile."; + } + uses vpn-common:service-status; + container connection { + description + "Defines Layer 2 protocols and parameters that + are required to enable connectivity between + the PE and the CE."; + container encapsulation { + description + "Container for Layer 2 encapsulation."; + leaf type { + type identityref { + base vpn-common:encapsulation-type; + } + default "vpn-common:priority-tagged"; + description + "Encapsulation type. By default, the type + of the tagged interface is + 'priority-tagged'."; + } + container dot1q { + when "derived-from-or-self(../type, " + + "'vpn-common:dot1q')" { + description + "Only applies when the type of the + tagged interface is 'dot1q'."; + } + description + "Tagged interface."; + leaf tag-type { + type identityref { + base vpn-common:tag-type; + } + default "vpn-common:c-vlan"; + description + "Tag type. By default, the tag type is + 'c-vlan'."; + } + leaf cvlan-id { + type uint16 { + range "1..4094"; + } + description + "VLAN identifier."; + } + } + container priority-tagged { + when "derived-from-or-self(../type, " + + "'vpn-common:priority-tagged')" { + description + "Only applies when the type of + the tagged interface is + 'priority-tagged'."; + } + description + "Priority tagged."; + leaf tag-type { + type identityref { + base vpn-common:tag-type; + } + default "vpn-common:c-vlan"; + description + "Tag type. By default, the tag type is + 'c-vlan'."; + } + } + container qinq { + when "derived-from-or-self(../type, " + + "'vpn-common:qinq')" { + description + "Only applies when the type of the + tagged interface is 'qinq'."; + } + description + "Includes QinQ parameters."; + leaf tag-type { + type identityref { + base vpn-common:tag-type; + } + default "vpn-common:s-c-vlan"; + description + "Tag type."; + } + leaf svlan-id { + type uint16; + mandatory true; + description + "Service VLAN (S-VLAN) identifier."; + } + leaf cvlan-id { + type uint16; + mandatory true; + description + "Customer VLAN (C-VLAN) identifier."; + } + } + } + choice l2-service { + description + "The Layer 2 connectivity service can be + provided by indicating a pointer to an + L2VPN or by specifying a Layer 2 tunnel + service."; + container l2-tunnel-service { + description + "Defines a Layer 2 tunnel termination. + It is only applicable when a tunnel is + required. The supported values are + 'pseudowire', 'vpls', and 'vxlan'. Other + values may be defined, if needed."; + leaf type { + type identityref { + base l2-tunnel-type; + } + description + "Selects the tunnel termination option + for each VPN network access."; + } + container pseudowire { + when "derived-from-or-self(../type, " + + "'pseudowire')" { + description + "Only applies when the Layer 2 service + type is 'pseudowire'."; + } + description + "Includes pseudowire termination + parameters."; + leaf vcid { + type uint32; + description + "Indicates a pseudowire (PW) or + virtual circuit (VC) identifier."; + } + leaf far-end { + type union { + type uint32; + type inet:ip-address; + } + description + "Neighbor reference."; + reference + "RFC 8077: Pseudowire Setup and + Maintenance Using the Label + Distribution Protocol + (LDP), Section 6.1"; + } + } + container vpls { + when "derived-from-or-self(../type, " + + "'vpls')" { + description + "Only applies when the Layer 2 service + type is 'vpls'."; + } + description + "VPLS termination parameters."; + leaf vcid { + type uint32; + description + "VC identifier."; + } + leaf-list far-end { + type union { + type uint32; + type inet:ip-address; + } + description + "Neighbor reference."; + } + } + container vxlan { + when "derived-from-or-self(../type, " + + "'vxlan')" { + description + "Only applies when the Layer 2 service + type is 'vxlan'."; + } + description + "VXLAN termination parameters."; + leaf vni-id { + type uint32; + mandatory true; + description + "VXLAN Network Identifier (VNI)."; + } + leaf peer-mode { + type identityref { + base vpn-common:vxlan-peer-mode; + } + default "vpn-common:static-mode"; + description + "Specifies the VXLAN access mode. By + default, the peer mode is set to + 'static-mode'."; + } + leaf-list peer-ip-address { + type inet:ip-address; + description + "List of a peer's IP addresses."; + } + } + } + case l2vpn { + leaf l2vpn-id { + type vpn-common:vpn-id; + description + "Indicates the L2VPN service associated + with an Integrated Routing and Bridging + (IRB) interface."; + } + } + } + leaf l2-termination-point { + type string; + description + "Specifies a reference to a local Layer 2 + termination point, such as a Layer 2 + sub-interface."; + } + leaf local-bridge-reference { + type string; + description + "Specifies a local bridge reference to + accommodate, for example, implementations + that require internal bridging. + A reference may be a local bridge domain."; + } + leaf bearer-reference { + if-feature "vpn-common:bearer-reference"; + type string; + description + "This is an internal reference for the + service provider to identify the bearer + associated with this VPN."; + } + container lag-interface { + if-feature "vpn-common:lag-interface"; + description + "Container for configuration of Link + Aggregation Group (LAG) interface + attributes."; + leaf lag-interface-id { + type string; + description + "LAG interface identifier."; + } + container member-link-list { + description + "Container for the member link list."; + list member-link { + key "name"; + description + "Member link."; + leaf name { + type string; + description + "Member link name."; + } + } + } + } + } + container ip-connection { + description + "Defines IP connection parameters."; + leaf l3-termination-point { + type string; + description + "Specifies a reference to a local Layer 3 + termination point, such as a bridge domain + interface."; + } + container ipv4 { + if-feature "vpn-common:ipv4"; + description + "IPv4-specific parameters."; + leaf local-address { + type inet:ipv4-address; + description + "The IP address used at the provider's + interface."; + } + leaf prefix-length { + type uint8 { + range "0..32"; + } + description + "Subnet prefix length expressed in bits. + It is applied to both local and customer + addresses."; + } + leaf address-allocation-type { + type identityref { + base address-allocation-type; + } + must "not(derived-from-or-self(current(), " + + "'slaac') or " + + "derived-from-or-self(current(), " + + "'provider-dhcp-slaac'))" { + error-message "SLAAC is only applicable " + + "to IPv6."; + } + description + "Defines how addresses are allocated to + the peer site. + + If there is no value for the address + allocation type, then IPv4 addressing + is not enabled."; + } + choice allocation-type { + description + "Choice of the IPv4 address allocation."; + case provider-dhcp { + description + "Parameters related to DHCP-allocated + addresses. IP addresses are allocated + by DHCP, which is provided by the + operator."; + leaf dhcp-service-type { + type enumeration { + enum server { + description + "Local DHCP server."; + } + enum relay { + description + "Local DHCP relay. DHCP requests + are relayed to a provider's + server."; + } + } + description + "Indicates the type of DHCP service to + be enabled on this access."; + } + choice service-type { + description + "Choice based on the DHCP service + type."; + case relay { + description + "Container for a list of the + provider's DHCP servers (i.e., + 'dhcp-service-type' is set to + 'relay')."; + leaf-list server-ip-address { + type inet:ipv4-address; + description + "IPv4 addresses of the provider's + DHCP server, for use by the local + DHCP relay."; + } + } + case server { + description + "A choice for how addresses are + assigned when a local DHCP server + is enabled."; + choice address-assign { + default "number"; + description + "A choice for how IPv4 addresses + are assigned."; + case number { + leaf number-of-dynamic-address { + type uint16; + default "1"; + description + "Specifies the number of IP + addresses to be assigned to + the customer on this + access."; + } + } + case explicit { + container customer-addresses { + description + "Container for customer + addresses to be allocated + using DHCP."; + list address-pool { + key "pool-id"; + description + "Describes IP addresses to + be allocated by DHCP. + + When only 'start-address' + is present, it represents a + single address. + + When both 'start-address' + and 'end-address' are + specified, it implies a + range inclusive of both + addresses."; + leaf pool-id { + type string; + description + "A pool identifier for the + address range from + 'start-address' to + 'end-address'."; + } + leaf start-address { + type inet:ipv4-address; + mandatory true; + description + "Indicates the first + address in the pool."; + } + leaf end-address { + type inet:ipv4-address; + description + "Indicates the last + address in the pool."; + } + } + } + } + } + } + } + } + case dhcp-relay { + description + "The DHCP relay is provided by the + operator."; + container customer-dhcp-servers { + description + "Container for a list of the + customer's DHCP servers."; + leaf-list server-ip-address { + type inet:ipv4-address; + description + "IPv4 addresses of the customer's + DHCP server."; + } + } + } + case static-addresses { + description + "Lists the IPv4 addresses that are + used."; + leaf primary-address { + type leafref { + path "../address/address-id"; + } + description + "Primary address of the connection."; + } + list address { + key "address-id"; + description + "Lists the IPv4 addresses that are + used."; + leaf address-id { + type string; + description + "An identifier of the static IPv4 + address."; + } + leaf customer-address { + type inet:ipv4-address; + description + "IPv4 address of the customer + side."; + } + } + } + } + } + container ipv6 { + if-feature "vpn-common:ipv6"; + description + "IPv6-specific parameters."; + leaf local-address { + type inet:ipv6-address; + description + "IPv6 address of the provider side."; + } + leaf prefix-length { + type uint8 { + range "0..128"; + } + description + "Subnet prefix length expressed in bits. + It is applied to both local and customer + addresses."; + } + leaf address-allocation-type { + type identityref { + base address-allocation-type; + } + description + "Defines how addresses are allocated. + If there is no value for the address + allocation type, then IPv6 addressing is + disabled."; + } + choice allocation-type { + description + "A choice based on the IPv6 allocation + type."; + container provider-dhcp { + when "derived-from-or-self(../address-allo" + + "cation-type, 'provider-dhcp') or " + + "derived-from-or-self(../address-allo" + + "cation-type, 'provider-dhcp-slaac')" { + description + "Only applies when addresses are + allocated by DHCPv6 as provided by + the operator."; + } + description + "Parameters related to DHCP-allocated + addresses."; + leaf dhcp-service-type { + type enumeration { + enum server { + description + "Local DHCPv6 server."; + } + enum relay { + description + "DHCPv6 relay."; + } + } + description + "Indicates the type of the DHCPv6 + service to be enabled on this + access."; + } + choice service-type { + description + "Choice based on the DHCPv6 service + type."; + case relay { + leaf-list server-ip-address { + type inet:ipv6-address; + description + "IPv6 addresses of the provider's + DHCPv6 server."; + } + } + case server { + choice address-assign { + default "number"; + description + "Choice for how IPv6 prefixes are + assigned by the DHCPv6 server."; + case number { + leaf number-of-dynamic-address { + type uint16; + default "1"; + description + "Describes the number of IPv6 + prefixes that are allocated + to the customer on this + access."; + } + } + case explicit { + container customer-addresses { + description + "Container for customer IPv6 + addresses allocated by + DHCPv6."; + list address-pool { + key "pool-id"; + description + "Describes IPv6 addresses + allocated by DHCPv6. + + When only 'start-address' + is present, it represents a + single address. + + When both 'start-address' + and 'end-address' are + specified, it implies a + range inclusive of both + addresses."; + leaf pool-id { + type string; + description + "A pool identifier for the + address range from + 'start-address' to + 'end-address'."; + } + leaf start-address { + type inet:ipv6-address; + mandatory true; + description + "Indicates the first + address."; + } + leaf end-address { + type inet:ipv6-address; + description + "Indicates the last + address."; + } + } + } + } + } + } + } + } + case dhcp-relay { + description + "DHCPv6 relay provided by the + operator."; + container customer-dhcp-servers { + description + "Container for a list of the + customer's DHCP servers."; + leaf-list server-ip-address { + type inet:ipv6-address; + description + "Contains the IP addresses of the + customer's DHCPv6 server."; + } + } + } + case static-addresses { + description + "IPv6-specific parameters for static + allocation."; + leaf primary-address { + type leafref { + path "../address/address-id"; + } + description + "Principal address of the + connection."; + } + list address { + key "address-id"; + description + "Describes IPv6 addresses that are + used."; + leaf address-id { + type string; + description + "An identifier of an IPv6 address."; + } + leaf customer-address { + type inet:ipv6-address; + description + "An IPv6 address of the customer + side."; + } + } + } + } + } + } + container routing-protocols { + description + "Defines routing protocols."; + list routing-protocol { + key "id"; + description + "List of routing protocols used on the + CE-PE link. This list can be augmented."; + leaf id { + type string; + description + "Unique identifier for the routing + protocol."; + } + leaf type { + type identityref { + base vpn-common:routing-protocol-type; + } + description + "Type of routing protocol."; + } + list routing-profiles { + key "id"; + description + "Routing profiles."; + leaf id { + type leafref { + path "/l3vpn-ntw/vpn-profiles" + + "/valid-provider-identifiers" + + "/routing-profile-identifier/id"; + } + description + "Routing profile to be used."; + } + leaf type { + type identityref { + base vpn-common:ie-type; + } + description + "Import, export, or both."; + } + } + container static { + when "derived-from-or-self(../type, " + + "'vpn-common:static-routing')" { + description + "Only applies when the protocol is a + static routing protocol."; + } + description + "Configuration specific to static + routing."; + container cascaded-lan-prefixes { + description + "LAN prefixes from the customer."; + list ipv4-lan-prefixes { + if-feature "vpn-common:ipv4"; + key "lan next-hop"; + description + "List of LAN prefixes for the site."; + leaf lan { + type inet:ipv4-prefix; + description + "LAN prefixes."; + } + leaf lan-tag { + type string; + description + "Internal tag to be used in VPN + policies."; + } + leaf next-hop { + type union { + type inet:ip-address; + type predefined-next-hop; + } + description + "The next hop that is to be used + for the static route. This may be + specified as an IP address or a + predefined next-hop type (e.g., + 'discard' or 'local-link')."; + } + leaf bfd-enable { + if-feature "vpn-common:bfd"; + type boolean; + description + "Enables Bidirectional Forwarding + Detection (BFD)."; + } + leaf metric { + type uint32; + description + "Indicates the metric associated + with the static route."; + } + leaf preference { + type uint32; + description + "Indicates the preference associated + with the static route."; + } + uses vpn-common:service-status; + } + list ipv6-lan-prefixes { + if-feature "vpn-common:ipv6"; + key "lan next-hop"; + description + "List of LAN prefixes for the site."; + leaf lan { + type inet:ipv6-prefix; + description + "LAN prefixes."; + } + leaf lan-tag { + type string; + description + "Internal tag to be used in VPN + policies."; + } + leaf next-hop { + type union { + type inet:ip-address; + type predefined-next-hop; + } + description + "The next hop that is to be used for + the static route. This may be + specified as an IP address or a + predefined next-hop type (e.g., + 'discard' or 'local-link')."; + } + leaf bfd-enable { + if-feature "vpn-common:bfd"; + type boolean; + description + "Enables BFD."; + } + leaf metric { + type uint32; + description + "Indicates the metric associated + with the static route."; + } + leaf preference { + type uint32; + description + "Indicates the preference associated + with the static route."; + } + uses vpn-common:service-status; + } + } + } + container bgp { + when "derived-from-or-self(../type, " + + "'vpn-common:bgp-routing')" { + description + "Only applies when the protocol is + BGP."; + } + description + "Configuration specific to BGP."; + leaf description { + type string; + description + "Includes a description of the BGP + session. + + This description is meant to be used + for diagnostic purposes. The semantic + of the description is local to an + implementation."; + } + leaf local-as { + type inet:as-number; + description + "Indicates a local AS Number (ASN), if + an ASN distinct from the ASN configured + at the VPN node level is needed."; + } + leaf peer-as { + type inet:as-number; + mandatory true; + description + "Indicates the customer's ASN when + the customer requests BGP routing."; + } + leaf address-family { + type identityref { + base vpn-common:address-family; + } + description + "This node contains the address families + to be activated. 'dual-stack' means + that both IPv4 and IPv6 will be + activated."; + } + leaf local-address { + type union { + type inet:ip-address; + type if:interface-ref; + } + description + "Sets the local IP address to use for + the BGP transport session. This may be + expressed as either an IP address or a + reference to an interface."; + } + leaf-list neighbor { + type inet:ip-address; + description + "IP address(es) of the BGP neighbor. + IPv4 and IPv6 neighbors may be + indicated if two sessions will be used + for IPv4 and IPv6."; + } + leaf multihop { + type uint8; + description + "Describes the number of IP hops allowed + between a given BGP neighbor and + the PE."; + } + leaf as-override { + type boolean; + default "false"; + description + "Defines whether ASN override is + enabled, i.e., replacing the ASN of + the customer specified in the AS_PATH + attribute with the local ASN."; + } + leaf allow-own-as { + type uint8; + default "0"; + description + "If set, specifies the maximum number of + occurrences of the provider's ASN that + are permitted within the AS_PATH + before it is rejected."; + } + leaf prepend-global-as { + type boolean; + default "false"; + description + "In some situations, the ASN that is + provided at the VPN node level may be + distinct from the ASN configured at the + VPN network access level. When such + ASNs are provided, they are both + prepended to the BGP route updates + for this access. To disable that + behavior, 'prepend-global-as' + must be set to 'false'. In such a + case, the ASN that is provided at + the VPN node level is not prepended + to the BGP route updates for + this access."; + } + leaf send-default-route { + type boolean; + default "false"; + description + "Defines whether default routes can be + advertised to a peer. If set, the + default routes are advertised to a + peer."; + } + leaf site-of-origin { + when "../address-family = 'vpn-common:ipv4' " + + "or 'vpn-common:dual-stack'" { + description + "Only applies if IPv4 is activated."; + } + type rt-types:route-origin; + description + "The Site of Origin attribute is encoded + as a Route Origin Extended Community. + It is meant to uniquely identify the + set of routes learned from a site via a + particular CE-PE connection and is used + to prevent routing loops."; + reference + "RFC 4364: BGP/MPLS IP Virtual Private + Networks (VPNs), Section 7"; + } + leaf ipv6-site-of-origin { + when "../address-family = 'vpn-common:ipv6' " + + "or 'vpn-common:dual-stack'" { + description + "Only applies if IPv6 is activated."; + } + type rt-types:ipv6-route-origin; + description + "The IPv6 Site of Origin attribute is + encoded as an IPv6 Route Origin + Extended Community. It is meant to + uniquely identify the set of routes + learned from a site via VRF + information."; + reference + "RFC 5701: IPv6 Address Specific BGP + Extended Community + Attribute"; + } + list redistribute-connected { + key "address-family"; + description + "Indicates, per address family, the + policy to follow for connected + routes."; + leaf address-family { + type identityref { + base vpn-common:address-family; + } + description + "Indicates the address family."; + } + leaf enable { + type boolean; + description + "Enables the redistribution of + connected routes."; + } + } + container bgp-max-prefix { + description + "Controls the behavior when a prefix + maximum is reached."; + leaf max-prefix { + type uint32; + default "5000"; + description + "Indicates the maximum number of BGP + prefixes allowed in the BGP session. + + It allows control of how many + prefixes can be received from a + neighbor. + + If the limit is exceeded, the action + indicated in 'violate-action' will be + followed."; + reference + "RFC 4271: A Border Gateway Protocol 4 + (BGP-4), Section 8.2.2"; + } + leaf warning-threshold { + type decimal64 { + fraction-digits 5; + range "0..100"; + } + units "percent"; + default "75"; + description + "When this value is reached, a warning + notification will be triggered."; + } + leaf violate-action { + type enumeration { + enum warning { + description + "Only a warning message is sent to + the peer when the limit is + exceeded."; + } + enum discard-extra-paths { + description + "Discards extra paths when the + limit is exceeded."; + } + enum restart { + description + "The BGP session restarts after + the indicated time interval."; + } + } + description + "If the BGP neighbor 'max-prefix' + limit is reached, the action + indicated in 'violate-action' + will be followed."; + } + leaf restart-timer { + type uint32; + units "seconds"; + description + "Time interval after which the BGP + session will be reestablished."; + } + } + container bgp-timers { + description + "Includes two BGP timers that can be + customized when building a VPN service + with BGP used as the CE-PE routing + protocol."; + leaf keepalive { + type uint16 { + range "0..21845"; + } + units "seconds"; + default "30"; + description + "This timer indicates the KEEPALIVE + messages' frequency between a PE + and a BGP peer. + + If set to '0', it indicates that + KEEPALIVE messages are disabled. + + It is suggested that the maximum + time between KEEPALIVE messages be + one-third of the Hold Time + interval."; + reference + "RFC 4271: A Border Gateway Protocol 4 + (BGP-4), Section 4.4"; + } + leaf hold-time { + type uint16 { + range "0 | 3..65535"; + } + units "seconds"; + default "90"; + description + "Indicates the maximum number of + seconds that may elapse between the + receipt of successive KEEPALIVE + and/or UPDATE messages from the peer. + + The Hold Time must be either zero or + at least three seconds."; + reference + "RFC 4271: A Border Gateway Protocol 4 + (BGP-4), Section 4.2"; + } + } + container authentication { + description + "Container for BGP authentication + parameters between a PE and a CE."; + leaf enable { + type boolean; + default "false"; + description + "Enables or disables authentication."; + } + container keying-material { + when "../enable = 'true'"; + description + "Container for describing how a BGP + routing session is to be secured + between a PE and a CE."; + choice option { + description + "Choice of authentication options."; + case ao { + description + "Uses the TCP Authentication + Option (TCP-AO)."; + reference + "RFC 5925: The TCP Authentication + Option"; + leaf enable-ao { + type boolean; + description + "Enables the TCP-AO."; + } + leaf ao-keychain { + type key-chain:key-chain-ref; + description + "Reference to the TCP-AO key + chain."; + reference + "RFC 8177: YANG Data Model for + Key Chains"; + } + } + case md5 { + description + "Uses MD5 to secure the session."; + reference + "RFC 4364: BGP/MPLS IP Virtual + Private Networks + (VPNs), Section 13.2"; + leaf md5-keychain { + type key-chain:key-chain-ref; + description + "Reference to the MD5 key + chain."; + reference + "RFC 8177: YANG Data Model for + Key Chains"; + } + } + case explicit { + leaf key-id { + type uint32; + description + "Key identifier."; + } + leaf key { + type string; + description + "BGP authentication key. + This model only supports the + subset of keys that are + representable as ASCII + strings."; + } + leaf crypto-algorithm { + type identityref { + base key-chain:crypto-algorithm; + } + description + "Indicates the cryptographic + algorithm associated with the + key."; + } + } + case ipsec { + description + "Specifies a reference to an + Internet Key Exchange Protocol + (IKE) Security Association + (SA)."; + leaf sa { + type string; + description + "Indicates the + administrator-assigned name + of the SA."; + } + } + } + } + } + uses vpn-common:service-status; + } + container ospf { + when "derived-from-or-self(../type, " + + "'vpn-common:ospf-routing')" { + description + "Only applies when the protocol is + OSPF."; + } + description + "Configuration specific to OSPF."; + leaf address-family { + type identityref { + base vpn-common:address-family; + } + description + "Indicates whether IPv4, IPv6, or + both are to be activated."; + } + leaf area-id { + type yang:dotted-quad; + mandatory true; + description + "Area ID."; + reference + "RFC 4577: OSPF as the Provider/Customer + Edge Protocol for BGP/MPLS IP + Virtual Private Networks + (VPNs), Section 4.2.3 + RFC 6565: OSPFv3 as a Provider Edge to + Customer Edge (PE-CE) Routing + Protocol, Section 4.2"; + } + leaf metric { + type uint16; + default "1"; + description + "Metric of the PE-CE link. It is used + in the routing state calculation and + path selection."; + } + container sham-links { + if-feature "vpn-common:rtg-ospf-sham-link"; + description + "List of sham links."; + reference + "RFC 4577: OSPF as the Provider/Customer + Edge Protocol for BGP/MPLS IP + Virtual Private Networks + (VPNs), Section 4.2.7 + RFC 6565: OSPFv3 as a Provider Edge to + Customer Edge (PE-CE) Routing + Protocol, Section 5"; + list sham-link { + key "target-site"; + description + "Creates a sham link with another + site."; + leaf target-site { + type string; + description + "Target site for the sham link + connection. The site is referred + to by its identifier."; + } + leaf metric { + type uint16; + default "1"; + description + "Metric of the sham link. It is + used in the routing state + calculation and path selection. + The default value is set to '1'."; + reference + "RFC 4577: OSPF as the + Provider/Customer Edge + Protocol for BGP/MPLS IP + Virtual Private Networks + (VPNs), Section 4.2.7.3 + RFC 6565: OSPFv3 as a Provider Edge + to Customer Edge (PE-CE) + Routing Protocol, + Section 5.2"; + } + } + } + leaf max-lsa { + type uint32 { + range "1..4294967294"; + } + description + "Maximum number of allowed Link State + Advertisements (LSAs) that the OSPF + instance will accept."; + } + container authentication { + description + "Authentication configuration."; + leaf enable { + type boolean; + default "false"; + description + "Enables or disables authentication."; + } + container keying-material { + when "../enable = 'true'"; + description + "Container for describing how an OSPF + session is to be secured between a CE + and a PE."; + choice option { + description + "Options for OSPF authentication."; + case auth-key-chain { + leaf key-chain { + type key-chain:key-chain-ref; + description + "Name of the key chain."; + } + } + case auth-key-explicit { + leaf key-id { + type uint32; + description + "Key identifier."; + } + leaf key { + type string; + description + "OSPF authentication key. + This model only supports the + subset of keys that are + representable as ASCII + strings."; + } + leaf crypto-algorithm { + type identityref { + base key-chain:crypto-algorithm; + } + description + "Indicates the cryptographic + algorithm associated with the + key."; + } + } + case ipsec { + leaf sa { + type string; + description + "Indicates the + administrator-assigned name + of the SA."; + reference + "RFC 4552: Authentication/ + Confidentiality for + OSPFv3"; + } + } + } + } + } + uses vpn-common:service-status; + } + container isis { + when "derived-from-or-self(../type, " + + "'vpn-common:isis-routing')" { + description + "Only applies when the protocol is + IS-IS."; + } + description + "Configuration specific to IS-IS."; + leaf address-family { + type identityref { + base vpn-common:address-family; + } + description + "Indicates whether IPv4, IPv6, or both + are to be activated."; + } + leaf area-address { + type area-address; + mandatory true; + description + "Area address."; + } + leaf level { + type identityref { + base vpn-common:isis-level; + } + description + "Can be 'level-1', 'level-2', or + 'level-1-2'."; + reference + "RFC 9181: A Common YANG Data Model for + Layer 2 and Layer 3 VPNs"; + } + leaf metric { + type uint16; + default "1"; + description + "Metric of the PE-CE link. It is used + in the routing state calculation and + path selection."; + } + leaf mode { + type enumeration { + enum active { + description + "The interface sends or receives + IS-IS protocol control packets."; + } + enum passive { + description + "Suppresses the sending of IS-IS + updates through the specified + interface."; + } + } + default "active"; + description + "IS-IS interface mode type."; + } + container authentication { + description + "Authentication configuration."; + leaf enable { + type boolean; + default "false"; + description + "Enables or disables authentication."; + } + container keying-material { + when "../enable = 'true'"; + description + "Container for describing how an IS-IS + session is to be secured between a CE + and a PE."; + choice option { + description + "Options for IS-IS authentication."; + case auth-key-chain { + leaf key-chain { + type key-chain:key-chain-ref; + description + "Name of the key chain."; + } + } + case auth-key-explicit { + leaf key-id { + type uint32; + description + "Key identifier."; + } + leaf key { + type string; + description + "IS-IS authentication key. + This model only supports the + subset of keys that are + representable as ASCII + strings."; + } + leaf crypto-algorithm { + type identityref { + base key-chain:crypto-algorithm; + } + description + "Indicates the cryptographic + algorithm associated with the + key."; + } + } + } + } + } + uses vpn-common:service-status; + } + container rip { + when "derived-from-or-self(../type, " + + "'vpn-common:rip-routing')" { + description + "Only applies when the protocol is RIP. + For IPv4, the model assumes that RIP + version 2 is used."; + } + description + "Configuration specific to RIP routing."; + leaf address-family { + type identityref { + base vpn-common:address-family; + } + description + "Indicates whether IPv4, IPv6, or both + address families are to be activated."; + } + container timers { + description + "Indicates the RIP timers."; + reference + "RFC 2453: RIP Version 2"; + leaf update-interval { + type uint16 { + range "1..32767"; + } + units "seconds"; + default "30"; + description + "Indicates the RIP update time, i.e., + the amount of time for which RIP + updates are sent."; + } + leaf invalid-interval { + type uint16 { + range "1..32767"; + } + units "seconds"; + default "180"; + description + "The interval before a route is + declared invalid after no updates are + received. This value is at least + three times the value for the + 'update-interval' argument."; + } + leaf holddown-interval { + type uint16 { + range "1..32767"; + } + units "seconds"; + default "180"; + description + "Specifies the interval before better + routes are released."; + } + leaf flush-interval { + type uint16 { + range "1..32767"; + } + units "seconds"; + default "240"; + description + "Indicates the RIP flush timer, i.e., + the amount of time that must elapse + before a route is removed from the + routing table."; + } + } + leaf default-metric { + type uint8 { + range "0..16"; + } + default "1"; + description + "Sets the default metric."; + } + container authentication { + description + "Authentication configuration."; + leaf enable { + type boolean; + default "false"; + description + "Enables or disables authentication."; + } + container keying-material { + when "../enable = 'true'"; + description + "Container for describing how a RIP + session is to be secured between a CE + and a PE."; + choice option { + description + "Specifies the authentication + scheme."; + case auth-key-chain { + leaf key-chain { + type key-chain:key-chain-ref; + description + "Name of the key chain."; + } + } + case auth-key-explicit { + leaf key { + type string; + description + "RIP authentication key. + This model only supports the + subset of keys that are + representable as ASCII + strings."; + } + leaf crypto-algorithm { + type identityref { + base key-chain:crypto-algorithm; + } + description + "Indicates the cryptographic + algorithm associated with the + key."; + } + } + } + } + } + uses vpn-common:service-status; + } + container vrrp { + when "derived-from-or-self(../type, " + + "'vpn-common:vrrp-routing')" { + description + "Only applies when the protocol is the + Virtual Router Redundancy Protocol + (VRRP)."; + } + description + "Configuration specific to VRRP."; + reference + "RFC 5798: Virtual Router Redundancy + Protocol (VRRP) Version 3 for + IPv4 and IPv6"; + leaf address-family { + type identityref { + base vpn-common:address-family; + } + description + "Indicates whether IPv4, IPv6, or both + address families are to be enabled."; + } + leaf vrrp-group { + type uint8 { + range "1..255"; + } + description + "Includes the VRRP group identifier."; + } + leaf backup-peer { + type inet:ip-address; + description + "Indicates the IP address of the peer."; + } + leaf-list virtual-ip-address { + type inet:ip-address; + description + "Virtual IP addresses for a single VRRP + group."; + reference + "RFC 5798: Virtual Router Redundancy + Protocol (VRRP) Version 3 for + IPv4 and IPv6, + Sections 1.2 and 1.3"; + } + leaf priority { + type uint8 { + range "1..254"; + } + default "100"; + description + "Sets the local priority of the VRRP + speaker."; + } + leaf ping-reply { + type boolean; + default "false"; + description + "Controls whether the VRRP speaker + should reply to ping requests."; + } + uses vpn-common:service-status; + } + } + } + container oam { + description + "Defines the Operations, Administration, + and Maintenance (OAM) mechanisms used. + + BFD is set as a fault detection mechanism, + but other mechanisms can be defined in the + future."; + container bfd { + if-feature "vpn-common:bfd"; + description + "Container for BFD."; + leaf session-type { + type identityref { + base vpn-common:bfd-session-type; + } + default "vpn-common:classic-bfd"; + description + "Specifies the BFD session type."; + } + leaf desired-min-tx-interval { + type uint32; + units "microseconds"; + default "1000000"; + description + "The minimum interval between + transmissions of BFD Control packets, as + desired by the operator."; + reference + "RFC 5880: Bidirectional Forwarding + Detection (BFD), + Section 6.8.7"; + } + leaf required-min-rx-interval { + type uint32; + units "microseconds"; + default "1000000"; + description + "The minimum interval between received BFD + Control packets that the PE should + support."; + reference + "RFC 5880: Bidirectional Forwarding + Detection (BFD), + Section 6.8.7"; + } + leaf local-multiplier { + type uint8 { + range "1..255"; + } + default "3"; + description + "Specifies the detection multiplier that + is transmitted to a BFD peer. + + The detection interval for the receiving + BFD peer is calculated by multiplying the + value of the negotiated transmission + interval by the received detection + multiplier value."; + reference + "RFC 5880: Bidirectional Forwarding + Detection (BFD), + Section 6.8.7"; + } + leaf holdtime { + type uint32; + units "milliseconds"; + description + "Expected BFD holdtime. + + The customer may impose some fixed + values for the holdtime period if the + provider allows the customer to use + this function. + + If the provider doesn't allow the + customer to use this function, + fixed values will not be set."; + reference + "RFC 5880: Bidirectional Forwarding + Detection (BFD), + Section 6.8.18"; + } + leaf profile { + type leafref { + path "/l3vpn-ntw/vpn-profiles" + + "/valid-provider-identifiers" + + "/bfd-profile-identifier/id"; + } + description + "Well-known service provider profile name. + + The provider can propose some profiles + to the customer, depending on the + service level the customer wants to + achieve."; + } + container authentication { + presence "Enables BFD authentication"; + description + "Parameters for BFD authentication."; + leaf key-chain { + type key-chain:key-chain-ref; + description + "Name of the key chain."; + } + leaf meticulous { + type boolean; + description + "Enables meticulous mode."; + reference + "RFC 5880: Bidirectional Forwarding + Detection (BFD), + Section 6.7"; + } + } + uses vpn-common:service-status; + } + } + container security { + description + "Site-specific security parameters."; + container encryption { + if-feature "vpn-common:encryption"; + description + "Container for CE-PE security encryption."; + leaf enabled { + type boolean; + default "false"; + description + "If set to 'true', traffic encryption on + the connection is required. Otherwise, + it is disabled."; + } + leaf layer { + when "../enabled = 'true'" { + description + "Included only when encryption + is enabled."; + } + type enumeration { + enum layer2 { + description + "Encryption occurs at Layer 2."; + } + enum layer3 { + description + "Encryption occurs at Layer 3. + For example, IPsec may be used when + a customer requests Layer 3 + encryption."; + } + } + description + "Indicates the layer on which encryption + is applied."; + } + } + container encryption-profile { + when "../encryption/enabled = 'true'" { + description + "Indicates the layer on which encryption + is enabled."; + } + description + "Container for the encryption profile."; + choice profile { + description + "Choice for the encryption profile."; + case provider-profile { + leaf profile-name { + type leafref { + path "/l3vpn-ntw/vpn-profiles" + + "/valid-provider-identifiers" + + "/encryption-profile-identifier/id"; + } + description + "Name of the service provider's + profile to be applied."; + } + } + case customer-profile { + leaf customer-key-chain { + type key-chain:key-chain-ref; + description + "Customer-supplied key chain."; + } + } + } + } + } + container service { + description + "Service parameters of the attachment."; + leaf pe-to-ce-bandwidth { + if-feature "vpn-common:inbound-bw"; + type uint64; + units "bps"; + description + "From the customer site's perspective, the + service inbound bandwidth of the connection + or download bandwidth from the SP to the + site. Note that the L3SM uses + 'input-bandwidth' to refer to the same + concept."; + } + leaf ce-to-pe-bandwidth { + if-feature "vpn-common:outbound-bw"; + type uint64; + units "bps"; + description + "From the customer site's perspective, + the service outbound bandwidth of the + connection or upload bandwidth from + the site to the SP. Note that the L3SM + uses 'output-bandwidth' to refer to the + same concept."; + } + leaf mtu { + type uint32; + units "bytes"; + description + "MTU at the service level. If the service + is IP, it refers to the IP MTU. If + Carriers' Carriers (CsC) is enabled, the + requested MTU will refer to the MPLS + maximum labeled packet size and not to the + IP MTU."; + } + container qos { + if-feature "vpn-common:qos"; + description + "QoS configuration."; + container qos-classification-policy { + description + "Configuration of the traffic + classification policy."; + uses vpn-common:qos-classification-policy; + } + container qos-action { + description + "List of QoS action policies."; + list rule { + key "id"; + description + "List of QoS actions."; + leaf id { + type string; + description + "An identifier of the QoS action + rule."; + } + leaf target-class-id { + type string; + description + "Identification of the class of + service. This identifier is internal + to the administration."; + } + leaf inbound-rate-limit { + type decimal64 { + fraction-digits 5; + range "0..100"; + } + units "percent"; + description + "Specifies whether/how to rate-limit + the inbound traffic matching this QoS + policy. It is expressed as a percent + of the value that is indicated in + 'input-bandwidth'."; + } + leaf outbound-rate-limit { + type decimal64 { + fraction-digits 5; + range "0..100"; + } + units "percent"; + description + "Specifies whether/how to rate-limit + the outbound traffic matching this + QoS policy. It is expressed as a + percent of the value that is + indicated in 'output-bandwidth'."; + } + } + } + container qos-profile { + description + "QoS profile configuration."; + list qos-profile { + key "profile"; + description + "QoS profile. + Can be a standard profile or + a customized profile."; + leaf profile { + type leafref { + path "/l3vpn-ntw/vpn-profiles" + + "/valid-provider-identifiers" + + "/qos-profile-identifier/id"; + } + description + "QoS profile to be used."; + } + leaf direction { + type identityref { + base vpn-common:qos-profile-direction; + } + default "vpn-common:both"; + description + "The direction to which the QoS + profile is applied."; + } + } + } + } + container carriers-carrier { + if-feature "vpn-common:carriers-carrier"; + description + "This container is used when the customer + provides MPLS-based services. This is + only used in the case of CsC (i.e., a + customer builds an MPLS service using an + IP VPN to carry its traffic)."; + leaf signaling-type { + type enumeration { + enum ldp { + description + "Uses LDP as the signaling protocol + between the PE and the CE. In this + case, an IGP routing protocol must + also be configured."; + } + enum bgp { + description + "Uses BGP as the signaling protocol + between the PE and the CE. + In this case, BGP must also be + configured as the routing protocol."; + reference + "RFC 8277: Using BGP to Bind MPLS + Labels to Address + Prefixes"; + } + } + default "bgp"; + description + "MPLS signaling type."; + } + } + container ntp { + description + "Time synchronization may be needed in some + VPNs, such as infrastructure and management + VPNs. This container includes parameters + to enable the NTP service."; + reference + "RFC 5905: Network Time Protocol Version 4: + Protocol and Algorithms + Specification"; + leaf broadcast { + type enumeration { + enum client { + description + "The VPN node will listen to NTP + broadcast messages on this VPN + network access."; + } + enum server { + description + "The VPN node will behave as a + broadcast server."; + } + } + description + "Indicates the NTP broadcast mode to use + for the VPN network access."; + } + container auth-profile { + description + "Pointer to a local profile."; + leaf profile-id { + type string; + description + "A pointer to a local authentication + profile on the VPN node is provided."; + } + } + uses vpn-common:service-status; + } + container multicast { + if-feature "vpn-common:multicast"; + description + "Multicast parameters for the network + access."; + leaf access-type { + type enumeration { + enum receiver-only { + description + "The peer site only has receivers."; + } + enum source-only { + description + "The peer site only has sources."; + } + enum source-receiver { + description + "The peer site has both sources and + receivers."; + } + } + default "source-receiver"; + description + "Type of multicast site."; + } + leaf address-family { + type identityref { + base vpn-common:address-family; + } + description + "Indicates the address family."; + } + leaf protocol-type { + type enumeration { + enum host { + description + "Hosts are directly connected to the + provider network. + + Host protocols, such as IGMP or MLD, + are required."; + } + enum router { + description + "Hosts are behind a customer router. + PIM will be implemented."; + } + enum both { + description + "Some hosts are behind a customer + router, and some others are directly + connected to the provider network. + Both host and routing protocols must + be used. + + Typically, IGMP and PIM will be + implemented."; + } + } + default "both"; + description + "Multicast protocol type to be used with + the customer site."; + } + leaf remote-source { + type boolean; + default "false"; + description + "A remote multicast source is a source + that is not on the same subnet as the + VPN network access. When set to 'true', + the multicast traffic from a remote + source is accepted."; + } + container igmp { + when "../protocol-type = 'host' and " + + "../address-family = 'vpn-common:ipv4' " + + "or 'vpn-common:dual-stack'"; + if-feature "vpn-common:igmp"; + description + "Includes IGMP-related parameters."; + list static-group { + key "group-addr"; + description + "Multicast static source/group + associated with the IGMP session."; + leaf group-addr { + type rt-types:ipv4-multicast-group-address; + description + "Multicast group IPv4 address."; + } + leaf source-addr { + type + rt-types:ipv4-multicast-source-address; + description + "Multicast source IPv4 address."; + } + } + leaf max-groups { + type uint32; + description + "Indicates the maximum number of + groups."; + } + leaf max-entries { + type uint32; + description + "Indicates the maximum number of IGMP + entries."; + } + leaf max-group-sources { + type uint32; + description + "The maximum number of group sources."; + } + leaf version { + type identityref { + base vpn-common:igmp-version; + } + default "vpn-common:igmpv2"; + description + "Indicates the IGMP version."; + } + uses vpn-common:service-status; + } + container mld { + when "../protocol-type = 'host' and " + + "../address-family = 'vpn-common:ipv6' " + + "or 'vpn-common:dual-stack'"; + if-feature "vpn-common:mld"; + description + "Includes MLD-related parameters."; + list static-group { + key "group-addr"; + description + "Multicast static source/group associated + with the MLD session."; + leaf group-addr { + type rt-types:ipv6-multicast-group-address; + description + "Multicast group IPv6 address."; + } + leaf source-addr { + type + rt-types:ipv6-multicast-source-address; + description + "Multicast source IPv6 address."; + } + } + leaf max-groups { + type uint32; + description + "Indicates the maximum number of + groups."; + } + leaf max-entries { + type uint32; + description + "Indicates the maximum number of MLD + entries."; + } + leaf max-group-sources { + type uint32; + description + "The maximum number of group sources."; + } + leaf version { + type identityref { + base vpn-common:mld-version; + } + default "vpn-common:mldv2"; + description + "Indicates the MLD protocol version."; + } + uses vpn-common:service-status; + } + container pim { + when "../protocol-type = 'router'"; + if-feature "vpn-common:pim"; + description + "Only applies when the protocol type is + 'pim'."; + leaf hello-interval { + type rt-types:timer-value-seconds16; + default "30"; + description + "Interval between PIM Hello messages. + If set to 'infinity' or 'not-set', + no periodic Hello messages are sent."; + reference + "RFC 7761: Protocol Independent + Multicast - Sparse Mode + (PIM-SM): Protocol + Specification (Revised), + Section 4.11 + RFC 8294: Common YANG Data Types for + the Routing Area"; + } + leaf dr-priority { + type uint32; + default "1"; + description + "Indicates the preference associated + with the DR election process. A larger + value has a higher priority over a + smaller value."; + reference + "RFC 7761: Protocol Independent + Multicast - Sparse Mode + (PIM-SM): Protocol + Specification (Revised), + Section 4.3.2"; + } + uses vpn-common:service-status; + } + } + } + } + } + } + } + } + } + } + } + <CODE ENDS> + +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 Network Configuration Access Control Model (NACM) [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) + and delete operations to these data nodes without proper protection + or authentication can have a negative effect on network operations. + These are the subtrees and data nodes and their sensitivity/ + vulnerability in the "ietf-l3vpn-ntw" module: + + 'vpn-profiles': This container includes a set of sensitive data that + influence how the L3VPN service is delivered. For example, an + attacker who has access to these data nodes may be able to + manipulate routing policies, QoS policies, or encryption + properties. These data nodes are defined with "nacm:default-deny- + write" tagging [RFC9181]. + + 'vpn-services': An attacker who is able to access network nodes can + undertake various attacks, such as deleting a running L3VPN + service, interrupting all the traffic of a client. In addition, + an attacker may modify the attributes of a running service (e.g., + QoS, bandwidth, routing protocols, keying material), leading to + malfunctioning of the service and therefore to Service Level + Agreement (SLA) violations. In addition, an attacker could + attempt to create an L3VPN service or add a new network access. + In addition to using NACM to prevent unauthorized access, such + activity can be detected by adequately monitoring and tracking + network configuration changes. + + 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: + + 'customer-name' and 'ip-connection': An attacker can retrieve + privacy-related information, which can be used to track a + customer. Disclosing such information may be considered a + violation of the customer-provider trust relationship. + + 'keying-material': An attacker can retrieve the cryptographic keys + protecting the underlying VPN service (CE-PE routing, in + particular). These keys could be used to inject spoofed routing + advertisements. + + Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely + upon [RFC8177] for authentication purposes. Therefore, this module + inherits the security considerations discussed in Section 5 of + [RFC8177]. Also, these data nodes support supplying explicit keys as + strings in ASCII format. The use of keys in hexadecimal string + format would afford greater key entropy with the same number of key- + string octets. However, such a format is not included in this + version of the L3NM, because it is not supported by the underlying + device modules (e.g., [RFC8695]). + + As discussed in Section 7.6.3, the module supports MD5 to basically + accommodate the installed BGP base. MD5 suffers from the security + weaknesses discussed in Section 2 of [RFC6151] and Section 2.1 of + [RFC6952]. + + [RFC8633] describes best current practices to be considered in VPNs + making use of NTP. Moreover, a mechanism to provide cryptographic + security for NTP is specified in [RFC8915]. + +10. IANA Considerations + + IANA has registered the following URI in the "ns" subregistry within + the "IETF XML Registry" [RFC3688]: + + URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw + Registrant Contact: The IESG. + XML: N/A; the requested URI is an XML namespace. + + IANA has registered the following YANG module in the "YANG Module + Names" subregistry [RFC6020] within the "YANG Parameters" registry. + + Name: ietf-l3vpn-ntw + Maintained by IANA? N + Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw + Prefix: l3nm + Reference: RFC 9182 + +11. References + +11.1. Normative References + + [ISO10589] ISO, "Information technology - Telecommunications and + information exchange between systems - Intermediate System + to Intermediate System intra-domain routeing information + exchange protocol for use in conjunction with the protocol + for providing the connectionless-mode network service (ISO + 8473)", ISO/IEC 10589:2002, 2002, + <https://www.iso.org/standard/30932.html>. + + [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, + RFC 1112, DOI 10.17487/RFC1112, August 1989, + <https://www.rfc-editor.org/info/rfc1112>. + + [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and + dual environments", RFC 1195, DOI 10.17487/RFC1195, + December 1990, <https://www.rfc-editor.org/info/rfc1195>. + + [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, + DOI 10.17487/RFC2080, January 1997, + <https://www.rfc-editor.org/info/rfc2080>. + + [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>. + + [RFC2236] Fenner, W., "Internet Group Management Protocol, Version + 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, + <https://www.rfc-editor.org/info/rfc2236>. + + [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, + DOI 10.17487/RFC2453, November 1998, + <https://www.rfc-editor.org/info/rfc2453>. + + [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, + DOI 10.17487/RFC2710, October 1999, + <https://www.rfc-editor.org/info/rfc2710>. + + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version + 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, + <https://www.rfc-editor.org/info/rfc3376>. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + <https://www.rfc-editor.org/info/rfc3688>. + + [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener + Discovery Version 2 (MLDv2) for IPv6", RFC 3810, + DOI 10.17487/RFC3810, June 2004, + <https://www.rfc-editor.org/info/rfc3810>. + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + <https://www.rfc-editor.org/info/rfc4271>. + + [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>. + + [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality + for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, + <https://www.rfc-editor.org/info/rfc4552>. + + [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the + Provider/Customer Edge Protocol for BGP/MPLS IP Virtual + Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, + June 2006, <https://www.rfc-editor.org/info/rfc4577>. + + [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, + DOI 10.17487/RFC5308, October 2008, + <https://www.rfc-editor.org/info/rfc5308>. + + [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community + Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, + <https://www.rfc-editor.org/info/rfc5701>. + + [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., + Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic + Authentication", RFC 5709, DOI 10.17487/RFC5709, October + 2009, <https://www.rfc-editor.org/info/rfc5709>. + + [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) + Version 3 for IPv4 and IPv6", RFC 5798, + DOI 10.17487/RFC5798, March 2010, + <https://www.rfc-editor.org/info/rfc5798>. + + [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, + <https://www.rfc-editor.org/info/rfc5880>. + + [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, + "Network Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, + <https://www.rfc-editor.org/info/rfc5905>. + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, DOI 10.17487/RFC5925, + June 2010, <https://www.rfc-editor.org/info/rfc5925>. + + [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>. + + [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>. + + [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ + BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February + 2012, <https://www.rfc-editor.org/info/rfc6513>. + + [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP + Encodings and Procedures for Multicast in MPLS/BGP IP + VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, + <https://www.rfc-editor.org/info/rfc6514>. + + [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and + M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge + (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, + June 2012, <https://www.rfc-editor.org/info/rfc6565>. + + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + <https://www.rfc-editor.org/info/rfc6991>. + + [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting + Authentication Trailer for OSPFv3", RFC 7166, + DOI 10.17487/RFC7166, March 2014, + <https://www.rfc-editor.org/info/rfc7166>. + + [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., + "Security Extension for OSPFv2 When Using Manual Key + Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, + <https://www.rfc-editor.org/info/rfc7474>. + + [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., + Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent + Multicast - Sparse Mode (PIM-SM): Protocol Specification + (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March + 2016, <https://www.rfc-editor.org/info/rfc7761>. + + [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>. + + [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>. + + [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. + Zhang, "YANG Data Model for Key Chains", RFC 8177, + DOI 10.17487/RFC8177, June 2017, + <https://www.rfc-editor.org/info/rfc8177>. + + [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, + "Common YANG Data Types for the Routing Area", RFC 8294, + DOI 10.17487/RFC8294, December 2017, + <https://www.rfc-editor.org/info/rfc8294>. + + [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>. + + [RFC8343] Bjorklund, M., "A YANG Data Model for Interface + Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, + <https://www.rfc-editor.org/info/rfc8343>. + + [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>. + + [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG + Data Model for Layer 2 Virtual Private Network (L2VPN) + Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October + 2018, <https://www.rfc-editor.org/info/rfc8466>. + + [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, + "YANG Data Model for Network Access Control Lists (ACLs)", + RFC 8519, DOI 10.17487/RFC8519, March 2019, + <https://www.rfc-editor.org/info/rfc8519>. + + [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., + Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and + Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February + 2022, <https://www.rfc-editor.org/info/rfc9181>. + +11.2. Informative References + + [BGP-YANG] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP + YANG Model for Service Provider Networks", Work in + Progress, Internet-Draft, draft-ietf-idr-bgp-model-12, 25 + October 2021, <https://datatracker.ietf.org/doc/html/ + draft-ietf-idr-bgp-model-12>. + + [Enhanced-VPN-Framework] + Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A + Framework for Enhanced Virtual Private Network (VPN+) + Services", Work in Progress, Internet-Draft, draft-ietf- + teas-enhanced-vpn-09, 25 October 2021, + <https://datatracker.ietf.org/doc/html/draft-ietf-teas- + enhanced-vpn-09>. + + [IEEE802.1AX] + IEEE, "802.1AX-2020 - IEEE Standard for Local and + Metropolitan Area Networks--Link Aggregation", IEEE Std + 802.1AX-2020, + <https://ieeexplore.ieee.org/document/9105034>. + + [Network-Slices-Framework] + Farrel, A., Ed., Gray, E., Drake, J., Rokui, R., Homma, + S., Makhijani, K., Contreras, LM., and J. Tantsura, + "Framework for IETF Network Slices", Work in Progress, + Internet-Draft, draft-ietf-teas-ietf-network-slices-05, 25 + October 2021, <https://datatracker.ietf.org/doc/html/ + draft-ietf-teas-ietf-network-slices-05>. + + [PIM-YANG] Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, + Y., and F. Hu, "A YANG Data Model for Protocol Independent + Multicast (PIM)", Work in Progress, Internet-Draft, draft- + ietf-pim-yang-17, 19 May 2018, + <https://datatracker.ietf.org/doc/html/draft-ietf-pim- + yang-17>. + + [PYANG] "pyang", commit 524cf61, December 2021, + <https://github.com/mbj4668/pyang>. + + [QoS-YANG] Choudhary, A., Jethanandani, M., Aries, E., and I. Chen, + "A YANG Data Model for Quality of Service (QoS)", Work in + Progress, Internet-Draft, draft-ietf-rtgwg-qos-model-06, 8 + November 2021, <https://datatracker.ietf.org/doc/html/ + draft-ietf-rtgwg-qos-model-06>. + + [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source + Discovery Protocol (MSDP)", RFC 3618, + DOI 10.17487/RFC3618, October 2003, + <https://www.rfc-editor.org/info/rfc3618>. + + [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. + Moore, "Policy Quality of Service (QoS) Information + Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, + <https://www.rfc-editor.org/info/rfc3644>. + + [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual + Private Network (VPN) Terminology", RFC 4026, + DOI 10.17487/RFC4026, March 2005, + <https://www.rfc-editor.org/info/rfc4026>. + + [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 + Provider-Provisioned Virtual Private Networks (PPVPNs)", + RFC 4110, DOI 10.17487/RFC4110, July 2005, + <https://www.rfc-editor.org/info/rfc4110>. + + [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., + and A. Gonguet, "Framework for Layer 3 Virtual Private + Networks (L3VPN) Operations and Management", RFC 4176, + DOI 10.17487/RFC4176, October 2005, + <https://www.rfc-editor.org/info/rfc4176>. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + <https://www.rfc-editor.org/info/rfc4862>. + + [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco + Systems' Solution for Multicast in BGP/MPLS IP VPNs", + RFC 6037, DOI 10.17487/RFC6037, October 2010, + <https://www.rfc-editor.org/info/rfc6037>. + + [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations + for the MD5 Message-Digest and the HMAC-MD5 Algorithms", + RFC 6151, DOI 10.17487/RFC6151, March 2011, + <https://www.rfc-editor.org/info/rfc6151>. + + [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of + BGP, LDP, PCEP, and MSDP Issues According to the Keying + and Authentication for Routing Protocols (KARP) Design + Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, + <https://www.rfc-editor.org/info/rfc6952>. + + [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined + Networking: A Perspective from within a Service Provider + Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, + <https://www.rfc-editor.org/info/rfc7149>. + + [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP + Connectivity Provisioning Profile (CPP)", RFC 7297, + DOI 10.17487/RFC7297, July 2014, + <https://www.rfc-editor.org/info/rfc7297>. + + [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., + Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- + Defined Networking (SDN): Layers and Architecture + Terminology", RFC 7426, DOI 10.17487/RFC7426, January + 2015, <https://www.rfc-editor.org/info/rfc7426>. + + [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. + Pallagatti, "Seamless Bidirectional Forwarding Detection + (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, + <https://www.rfc-editor.org/info/rfc7880>. + + [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and + Maintenance Using the Label Distribution Protocol (LDP)", + STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, + <https://www.rfc-editor.org/info/rfc8077>. + + [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address + Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, + <https://www.rfc-editor.org/info/rfc8277>. + + [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>. + + [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>. + + [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., + Ananthakrishnan, H., and X. Liu, "A YANG Data Model for + Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March + 2018, <https://www.rfc-editor.org/info/rfc8345>. + + [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for + Routing Management (NMDA Version)", RFC 8349, + DOI 10.17487/RFC8349, March 2018, + <https://www.rfc-editor.org/info/rfc8349>. + + [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for + Abstraction and Control of TE Networks (ACTN)", RFC 8453, + DOI 10.17487/RFC8453, August 2018, + <https://www.rfc-editor.org/info/rfc8453>. + + [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., + Vinapamula, S., and Q. Wu, "A YANG Module for Network + Address Translation (NAT) and Network Prefix Translation + (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, + <https://www.rfc-editor.org/info/rfc8512>. + + [RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time + Protocol Best Current Practices", BCP 223, RFC 8633, + DOI 10.17487/RFC8633, July 2019, + <https://www.rfc-editor.org/info/rfc8633>. + + [RFC8695] Liu, X., Sarda, P., and V. Choudhary, "A YANG Data Model + for the Routing Information Protocol (RIP)", RFC 8695, + DOI 10.17487/RFC8695, February 2020, + <https://www.rfc-editor.org/info/rfc8695>. + + [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, + "Handling Long Lines in Content of Internet-Drafts and + RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, + <https://www.rfc-editor.org/info/rfc8792>. + + [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. + Sundblad, "Network Time Security for the Network Time + Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, + <https://www.rfc-editor.org/info/rfc8915>. + + [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and + L. Geng, "A Framework for Automating Service and Network + Management with YANG", RFC 8969, DOI 10.17487/RFC8969, + January 2021, <https://www.rfc-editor.org/info/rfc8969>. + + [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and + A. Sajassi, "IP Prefix Advertisement in Ethernet VPN + (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, + <https://www.rfc-editor.org/info/rfc9136>. + + [YANG-Composed-VPN] + Even, R., Wu, B., Wu, Q., and Y. Cheng, "YANG Data Model + for Composed VPN Service Delivery", Work in Progress, + Internet-Draft, draft-evenwu-opsawg-yang-composed-vpn-03, + 8 March 2019, <https://datatracker.ietf.org/doc/html/ + draft-evenwu-opsawg-yang-composed-vpn-03>. + + [YANG-SAPs] + Gonzalez de Dios, O., Barguil, S., Wu, Q., Boucadair, M., + and V. Lopez, "A Network YANG Model for Service Attachment + Points", Work in Progress, Internet-Draft, draft-ietf- + opsawg-sap-00, 25 January 2022, + <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg- + sap-00>. + +Appendix A. L3VPN Examples + +A.1. 4G VPN Provisioning Example + + L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise + services, mainly because several traffic discrimination policies can + be applied within the network to deliver to the mobile customers a + service that meets the SLA requirements. + + Typically, and as shown in Figure 31, an eNodeB (CE) is directly + connected to the access routers of the mobile backhaul and their + logical interfaces (one or many, according to the service type) are + configured in a VPN that transports the packets to the mobile core + platforms. In this example, a 'vpn-node' is created with two 'vpn- + network-accesses'. + + +-------------+ +------------------+ + | | | PE | + | | | 198.51.100.1 | + | eNodeB |>--------/------->|........... | + | | vlan 1 | | | + | |>--------/------->|...... | | + | | vlan 2 | | | | + | | Direct | +-------------+ | + +-------------+ Routing | | vpn-node-id | | + | | 44 | | + | +-------------+ | + | | + +------------------+ + + Figure 31: Mobile Backhaul Example + + To create an L3VPN service using the L3NM, the following steps can be + followed. + + First, create the 4G VPN service (Figure 32). + + POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services + Host: example.com + Content-Type: application/yang-data+json + + { + "ietf-l3vpn-ntw:vpn-services": { + "vpn-service": [ + { + "vpn-id": "4G", + "vpn-description": "VPN to deploy 4G services", + "customer-name": "mycustomer", + "vpn-service-topology": "custom", + "vpn-instance-profiles": { + "vpn-instance-profile": [ + { + "profile-id": "simple-profile", + "local-as": 65550, + "rd": "0:65550:1", + "address-family": [ + { + "address-family": "ietf-vpn-common:dual-stack", + "vpn-targets": { + "vpn-target": [ + { + "id": 1, + "route-targets": [ + { + "route-target": "0:65550:1" + } + ], + "route-target-type": "both" + } + ] + } + } + ] + } + ] + } + } + ] + } + } + + Figure 32: Create VPN Service + + Second, create a VPN node, as depicted in Figure 33. In this type of + service, the VPN node is equivalent to VRF configured in the physical + device ('ne-id'=198.51.100.1). NOTE: '\' line wrapping in Figures 33 + and 34 is implemented per [RFC8792]. + + POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ + vpn-services/vpn-service=4G + Host: example.com + Content-Type: application/yang-data+json + + { + "ietf-l3vpn-ntw:vpn-nodes": { + "vpn-node": [ + { + "vpn-node-id": "44", + "ne-id": "198.51.100.1", + "active-vpn-instance-profiles": { + "vpn-instance-profile": [ + { + "profile-id": "simple-profile" + } + ] + } + } + ] + } + } + + Figure 33: Create VPN Node + + Finally, two VPN network accesses are created using the same physical + port ('interface-id'=1/1/1). Each 'vpn-network-access' has a + particular VLAN interface (1,2): "SYNC" and "DATA" (Figure 34). + These interfaces differentiate the traffic between them. + + POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ + vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 + content-type: application/yang-data+json + + { + "ietf-l3vpn-ntw:vpn-network-accesses": { + "vpn-network-access": [ + { + "id": "1/1/1.1", + "interface-id": "1/1/1", + "description": "Interface SYNC to eNODE-B", + "vpn-network-access-type": "ietf-vpn-common:point-to-point", + "vpn-instance-profile": "simple-profile", + "status": { + "admin-status": { + "status": "ietf-vpn-common:admin-up" + } + }, + "connection": { + "encapsulation": { + "type": "ietf-vpn-common:dot1q", + "dot1q": { + "cvlan-id": 1 + } + } + }, + "ip-connection": { + "ipv4": { + "local-address": "192.0.2.1", + "prefix-length": 30, + "address-allocation-type": "static-address", + "static-addresses": { + "primary-address": "1", + "address": [ + { + "address-id": "1", + "customer-address": "192.0.2.2" + } + ] + } + }, + "ipv6": { + "local-address": "2001:db8::1", + "prefix-length": 64, + "address-allocation-type": "static-address", + "primary-address": "1", + "address": [ + { + "address-id": "1", + "customer-address": "2001:db8::2" + } + ] + } + }, + "routing-protocols": { + "routing-protocol": [ + { + "id": "1", + "type": "ietf-vpn-common:direct" + } + ] + } + }, + { + "id": "1/1/1.2", + "interface-id": "1/1/1", + "description": "Interface DATA to eNODE-B", + "vpn-network-access-type": "ietf-vpn-common:point-to-point", + "vpn-instance-profile": "simple-profile", + "status": { + "admin-status": { + "status": "ietf-vpn-common:admin-up" + } + }, + "connection": { + "encapsulation": { + "type": "ietf-vpn-common:dot1q", + "dot1q": { + "cvlan-id": 2 + } + } + }, + "ip-connection": { + "ipv4": { + "local-address": "192.0.2.1", + "prefix-length": 30, + "address-allocation-type": "static-address", + "static-addresses": { + "primary-address": "1", + "address": [ + { + "address-id": "1", + "customer-address": "192.0.2.2" + } + ] + } + }, + "ipv6": { + "local-address": "2001:db8::1", + "prefix-length": 64, + "address-allocation-type": "static-address", + "primary-address": "1", + "address": [ + { + "address-id": "1", + "customer-address": "2001:db8::2" + } + ] + } + }, + "routing-protocols": { + "routing-protocol": [ + { + "id": "1", + "type": "ietf-vpn-common:direct" + } + ] + } + } + ] + } + } + + Figure 34: Create VPN Network Access + +A.2. Loopback Interface + + An example of a loopback interface is depicted in Figure 35. + + { + "ietf-l3vpn-ntw:vpn-network-accesses": { + "vpn-network-access": [ + { + "id": "vpn-access-loopback", + "interface-id": "Loopback1", + "description": "An example of a loopback interface.", + "vpn-network-access-type": "ietf-vpn-common:loopback", + "status": { + "admin-status": { + "status": "ietf-vpn-common:admin-up" + } + }, + "ip-connection": { + "ipv6": { + "local-address": "2001:db8::4", + "prefix-length": 128 + } + } + } + ] + } + } + + Figure 35: VPN Network Access with a Loopback Interface (Message + Body) + +A.3. Overriding VPN Instance Profile Parameters + + Figure 36 shows a simplified example to illustrate how some + information that is provided at the VPN service level (particularly + as part of the 'vpn-instance-profiles') can be overridden by + information configured at the VPN node level. In this example, PE3 + and PE4 inherit the 'vpn-instance-profiles' parameters that are + specified at the VPN service level, but PE1 and PE2 are provided with + "maximum-routes" values at the VPN node level that override the + values that are specified at the VPN service level. + + { + "ietf-l3vpn-ntw:vpn-services": { + "vpn-service": [ + { + "vpn-id": "override-example", + "vpn-service-topology": "ietf-vpn-common:hub-spoke", + "vpn-instance-profiles": { + "vpn-instance-profile": [ + { + "profile-id": "HUB", + "role": "ietf-vpn-common:hub-role", + "local-as": 64510, + "rd-suffix": 1001, + "address-family": [ + { + "address-family": "ietf-vpn-common:dual-stack", + "maximum-routes": [ + { + "protocol": "ietf-vpn-common:any", + "maximum-routes": 100 + } + ] + } + ] + }, + { + "profile-id": "SPOKE", + "role": "ietf-vpn-common:spoke-role", + "local-as": 64510, + "address-family": [ + { + "address-family": "ietf-vpn-common:dual-stack", + "maximum-routes": [ + { + "protocol": "ietf-vpn-common:any", + "maximum-routes": 1000 + } + ] + } + ] + } + ] + }, + "vpn-nodes": { + "vpn-node": [ + { + "vpn-node-id": "PE1", + "ne-id": "pe1", + "router-id": "198.51.100.1", + "active-vpn-instance-profiles": { + "vpn-instance-profile": [ + { + "profile-id": "HUB", + "rd": "1:198.51.100.1:1001", + "address-family": [ + { + "address-family": + "ietf-vpn-common:dual-stack", + "maximum-routes": [ + { + "protocol": "ietf-vpn-common:any", + "maximum-routes": 10 + } + ] + } + ] + } + ] + } + }, + { + "vpn-node-id": "PE2", + "ne-id": "pe2", + "router-id": "198.51.100.2", + "active-vpn-instance-profiles": { + "vpn-instance-profile": [ + { + "profile-id": "SPOKE", + "address-family": [ + { + "address-family": + "ietf-vpn-common:dual-stack", + "maximum-routes": [ + { + "protocol": "ietf-vpn-common:any", + "maximum-routes": 100 + } + ] + } + ] + } + ] + } + }, + { + "vpn-node-id": "PE3", + "ne-id": "pe3", + "router-id": "198.51.100.3", + "active-vpn-instance-profiles": { + "vpn-instance-profile": [ + { + "profile-id": "SPOKE" + } + ] + } + }, + { + "vpn-node-id": "PE4", + "ne-id": "pe4", + "router-id": "198.51.100.4", + "active-vpn-instance-profiles": { + "vpn-instance-profile": [ + { + "profile-id": "SPOKE" + } + ] + } + } + ] + } + } + ] + } + } + + Figure 36: VPN Instance Profile Example (Message Body) + +A.4. Multicast VPN Provisioning Example + + IPTV is mainly distributed through multicast over the LANs. In the + following example, PIM - Sparse Mode (PIM-SM) is enabled and + functional between the PE and the CE. The PE receives multicast + traffic from a CE that is directly connected to the multicast source. + The signaling between the PE and the CE is achieved using BGP. Also, + the RP is statically configured for a multicast group. + + +-----------+ +------+ +------+ +-----------+ + | Multicast |---| CE |--/--| PE |----| Backbone | + | source | +------+ +------+ | IP/MPLS | + +-----------+ +-----------+ + + Figure 37: Multicast L3VPN Service Example + + Figure 38 illustrates how to configure a multicast L3VPN service + using the L3NM. + + First, the multicast service is created together with a generic VPN + instance profile (see the excerpt of the request message body shown + in Figure 38). + + { + "ietf-l3vpn-ntw:vpn-services": { + "vpn-service": [ + { + "vpn-id": "Multicast-IPTV", + "vpn-description": "Multicast IPTV VPN service", + "customer-name": "a-name", + "vpn-service-topology": "ietf-vpn-common:hub-spoke", + "vpn-instance-profiles": { + "vpn-instance-profile": [ + { + "profile-id": "multicast", + "role": "ietf-vpn-common:hub-role", + "local-as": 65536, + "multicast": { + "rp": { + "rp-group-mappings": { + "rp-group-mapping": [ + { + "id": 1, + "rp-address": "203.0.113.17", + "groups": { + "group": [ + { + "id": 1, + "group-address": "239.130.0.0/15" + } + ] + } + } + ] + }, + "rp-discovery": { + "rp-discovery-type": "ietf-vpn-common:static-rp" + } + } + } + } + ] + } + } + ] + } + } + + Figure 38: Create Multicast VPN Service (Excerpt of the Message + Request Body) + + Then, the VPN nodes are created (see the excerpt of the request + message body shown in Figure 39). In this example, the VPN node will + represent VRF configured in the physical device. + + { + "ietf-l3vpn-ntw:vpn-node": [ + { + "vpn-node-id": "500003105", + "description": "VRF-IPTV-MULTICAST", + "ne-id": "198.51.100.10", + "router-id": "198.51.100.10", + "active-vpn-instance-profiles": { + "vpn-instance-profile": [ + { + "profile-id": "multicast", + "rd": "65536:31050202" + } + ] + } + } + ] + } + + Figure 39: Create Multicast VPN Node (Excerpt of the Message + Request Body) + + Finally, create the VPN network access with multicast enabled (see + the excerpt of the request message body shown in Figure 40). + + { + "ietf-l3vpn-ntw:vpn-network-access": { + "id": "1/1/1", + "description": "Connected-to-source", + "vpn-network-access-type": "ietf-vpn-common:point-to-point", + "vpn-instance-profile": "multicast", + "status": { + "admin-status": { + "status": "ietf-vpn-common:admin-up" + }, + "ip-connection": { + "ipv4": { + "local-address": "203.0.113.1", + "prefix-length": 30, + "address-allocation-type": "static-address", + "static-addresses": { + "primary-address": "1", + "address": [ + { + "address-id": "1", + "customer-address": "203.0.113.2" + } + ] + } + } + }, + "routing-protocols": { + "routing-protocol": [ + { + "id": "1", + "type": "ietf-vpn-common:bgp-routing", + "bgp": { + "description": "Connected to CE", + "peer-as": "65537", + "address-family": "ietf-vpn-common:ipv4", + "neighbor": "203.0.113.2" + } + } + ] + }, + "service": { + "pe-to-ce-bandwidth": "100000000", + "ce-to-pe-bandwidth": "100000000", + "mtu": 1500, + "multicast": { + "access-type": "source-only", + "address-family": "ietf-vpn-common:ipv4", + "protocol-type": "router", + "pim": { + "hello-interval": 30, + "status": { + "admin-status": { + "status": "ietf-vpn-common:admin-up" + } + } + } + } + } + } + } + } + + Figure 40: Create VPN Network Access (Excerpt of the Message + Request Body) + +Acknowledgements + + During the discussions of this work, helpful comments, suggestions, + and reviews were received from (listed alphabetically) Raul Arco, + Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque + Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Greg + Mirsky, and Tom Petch. Many thanks to them. Thanks to Philip + Eardley for the review of an early draft version of the document. + + Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski + contributed to early draft versions of this document. Many thanks to + Robert Wilton for the AD review. Thanks to Andrew Malis for the + routing directorate review, Rifaat Shekh-Yusef for the security + directorate review, Qin Wu for the opsdir review, and Pete Resnick + for the genart directorate review. Thanks to Michael Scharf for the + discussion on the TCP-AO. Thanks to Martin Duke, Lars Eggert, + Zaheduzzaman Sarker, Roman Danyliw, Erik Kline, Benjamin Kaduk, + Francesca Palombini, and Éric Vyncke for the IESG review. + + This work was supported in part by the European Commission-funded + H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020 + Secured autonomic traffic management for a Tera of SDN flows + (Teraflow) project (G.A. 101015857). + +Contributors + + Victor Lopez + Nokia + Madrid + Spain + + Email: victor.lopez@nokia.com + + + Qin Wu + Huawei + + Email: bill.wu@huawei.com + + + Manuel Lopez + Vodafone + Spain + + Email: manuel-julian.lopez@vodafone.com + + + Lucia Oliva Ballega + Telefonica + + Email: lucia.olivaballega.ext@telefonica.com + + + Erez Segev + Ribbon Communications + + Email: erez.segev@rbbn.com + + + Paul Sherratt + Gamma Telecom + + Email: paul.sherratt@gamma.co.uk + + +Authors' Addresses + + Samier Barguil + Telefonica + Madrid + Spain + + Email: samier.barguilgiraldo.ext@telefonica.com + + + Oscar Gonzalez de Dios (editor) + Telefonica + Madrid + Spain + + Email: oscar.gonzalezdedios@telefonica.com + + + Mohamed Boucadair (editor) + Orange + 35000 Rennes + France + + Email: mohamed.boucadair@orange.com + + + Luis Angel Munoz + Vodafone + Spain + + Email: luis-angel.munoz@vodafone.com + + + Alejandro Aguado + Nokia + Madrid + Spain + + Email: alejandro.aguado_martin@nokia.com |