--- 1/draft-ietf-opsawg-l3sm-l3nm-09.txt 2021-07-15 07:14:37.698855774 -0700 +++ 2/draft-ietf-opsawg-l3sm-l3nm-10.txt 2021-07-15 07:14:37.986862958 -0700 @@ -1,24 +1,24 @@ OPSAWG S. Barguil Internet-Draft O. Gonzalez de Dios, Ed. Intended status: Standards Track Telefonica -Expires: November 20, 2021 M. Boucadair, Ed. +Expires: January 14, 2022 M. Boucadair, Ed. Orange L. Munoz Vodafone A. Aguado Nokia - May 19, 2021 + July 13, 2021 A Layer 3 VPN Network YANG Model - draft-ietf-opsawg-l3sm-l3nm-09 + draft-ietf-opsawg-l3sm-l3nm-10 Abstract This document defines an L3VPN Network YANG Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network @@ -49,21 +49,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 20, 2021. + This Internet-Draft will expire on January 14, 2022. Copyright Notice Copyright (c) 2021 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 @@ -92,43 +92,43 @@ 7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 20 7.6. VPN Network Access . . . . . . . . . . . . . . . . . . . 23 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 26 7.6.2. IP Connection . . . . . . . . . . . . . . . . . . . . 27 7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 31 7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 44 7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 45 7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 51 8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 55 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 116 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 118 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 118 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 118 - 11.2. Informative References . . . . . . . . . . . . . . . . . 122 - Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 126 - A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 126 - A.2. Loopback Interface . . . . . . . . . . . . . . . . . . . 131 - A.3. Multicast VPN Provisioning Example . . . . . . . . . . . 131 - Appendix B. Implementation Status . . . . . . . . . . . . . . . 136 - B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 136 - B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 136 - B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 136 - B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 136 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 137 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 137 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 115 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 117 + 11.2. Informative References . . . . . . . . . . . . . . . . . 121 + Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 125 + A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 125 + A.2. Loopback Interface . . . . . . . . . . . . . . . . . . . 130 + A.3. Multicast VPN Provisioning Example . . . . . . . . . . . 130 + Appendix B. Implementation Status . . . . . . . . . . . . . . . 135 + B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 135 + B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 135 + B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 135 + B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 135 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 136 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 137 1. Introduction [RFC8299] defines a Layer 3 Virtual Private Network Service YANG data Model (L3SM) that can be used for communication between customers and - network operators. Such model is focused on describing the customer + network operators. 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 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 for more network-centric @@ -142,42 +142,42 @@ 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 points the YANG module described in [RFC8299]. Nevertheless, the L3NM is not defined as an augment to L3SM because a specific structure is required to meet network- oriented L3 needs. - Some of the information captured in the L3SM can be passed by the - orchestrator in the L3NM (e.g., customer) or be used to feed some of - the L3NM attributes (e.g., actual forwarding policies). Some of the - information captured in L3SM may be maintained locally within the + 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 correspondence between a customer view and its network instantiation. Likewise, - some of the information captured and exposed using the L3NM can feed - the service layer (e.g., capabilities) to drive VPN service order + 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 + The L3NM does not attempt to address all deployment cases, especially those where the 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 an end- to-end VPN connectivity are addressed by complementary YANG modules, e.g., [I-D.evenwu-opsawg-yang-composed-vpn]. - L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as + The L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as described in [RFC6037][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 @@ -209,21 +209,21 @@ contains information of 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 YANG module can be consumed 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 - of the Customer Edge (CE) - Provider Edge (PE) attachment + for the Customer Edge (CE) - Provider Edge (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. @@ -319,21 +319,21 @@ +---------------+ | Customer | +-------+-------+ Customer Service Model | e.g., l3vpn-svc | +-------+-------+ | Service | | Orchestration | +-------+-------+ - Network Model | + Service Delivery Model | l3vpn-ntw | +-------+-------+ | Network | | Orchestration | +-------+-------+ Network Configuration Model | +-----------+-----------+ | | +--------+------+ +--------+------+ | Domain | | Domain | @@ -488,22 +488,22 @@ This section provides a non-exhaustive list of examples to 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, and therefore, L3NM can be useful to automate 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) [RFC7149][RFC7426] layer and little manual - intervention will be still required. + Defined Networking (SDN) [RFC7149][RFC7426] layer, but some manual + intervention will still be required. A common function that is supported by VPNs is the addition or removal of customer sites. 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 which span across administratively separated domains (i.e., that are under the @@ -612,21 +612,21 @@ 'qos-profile-identifier': A Quality of Service (QoS) profile refers to as 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 [RFC5880] policies 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, at applying Access + 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. +--rw l3vpn-ntw +--rw vpn-profiles | +--rw valid-provider-identifiers | +--rw external-connectivity-identifier* [id] @@ -645,42 +645,42 @@ +--rw vpn-services ... Figure 4: VPN Profiles Subtree Structure 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 'vpn-id' is only - meaningful locally within the network controller. The subtree of the - 'vpn-services' is shown in Figure 5. + 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-updated? yang:date-and-time + | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref - | +--ro last-updated? yang:date-and-time + | +--ro last-change? yang:date-and-time +--rw vpn-instance-profiles | ... +--rw underlay-transport | +-- (type)? | +--:(abstract) | | +-- transport-instance-id? string | +--:(protocol) | +-- protocol* identityref +--rw external-connectivity | {external-connectivity} @@ -729,22 +729,22 @@ of import and export profiles (Section 4.3.5 of [RFC4364]). 'status': Is used to track the service status of a given VPN service. Both operational and administrative status are maintained together with a timestamp. For example, a service can be created, but not put into effect. Administrative and operational status can be used as a trigger to detect service anomalies. For example, a service that is declared at the service layer as being active but still inactive at the - network layer is an indication that network provision actions are - needed to align the observed service status with the expected + 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 @@ -914,23 +914,23 @@ '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 belong 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 into a VRF in the node. However, the model also allows to - point to an abstract node. In this case, the network controller will - decide how to split the 'vpn-node' into VRFs. + mapped into a VRF 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 VRFs. +--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 @@ -957,34 +957,34 @@ | | +--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-updated? yang:date-and-time + | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref - | +--ro last-updated? yang:date-and-time + | +--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-updated? yang:date-and-time + | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref - | +--ro last-updated? yang:date-and-time + | +--ro last-change? yang:date-and-time +--rw vpn-network-accesses ... Figure 7: VPN Node Subtree Structure In reference to the subtree shown in Figure 7, the description of VPN node data nodes is as follows: 'vpn-node-id': Is an identifier that uniquely identifies a node that enables a VPN network access. @@ -999,24 +999,24 @@ 'router-id': Indicates a 32-bit number that is used to uniquely identify a router within an Autonomous System. '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 one discussed in - Section 7.4 with the exception of 'router-id'. Indeed, 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 capability is supported by involved routers. + Section 7.4 except 'router-id'. Indeed, 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 + capability is supported by involved routers. Values defined in 'active-vpn-instance-profiles' overrides the ones defined in the VPN service level. 'msdp': For redundancy purposes, Multicast Source Discovery Protocol (MSDP) [RFC3618] may be enabled and used to share the state about sources between multiple rendez-vous 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, which is useful in a domain that does not support multicast sources, but @@ -1028,21 +1028,21 @@ nodes. 'status': Tracks the status of a node involved in a VPN service. Both operational 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 in L3SM, the L3NM does not need to model the + Note that, unlike in the L3SM, the L3NM does not need to model the customer site, only the points where the traffic from the site are received (i.e., the PE side of 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 Access @@ -1051,101 +1051,100 @@ 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 port-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-updated? yang:date-and-time + | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref - | +--ro last-updated? yang:date-and-time + | +--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 In reference to the subtree depicted in Figure 8, a 'vpn-network- access' includes the following data nodes: 'id': Is an identifier of the VPN network access. - 'port-id': Indicates the port on which the VPN network access is - bound. + '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': Is used to select the type of network interface to be deployed in the devices. The available defined values are: '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 broadcast 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 service ('l2vpn-id') may be included in the 'connection' container as depicted in Figure 9. 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 to illustrate 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 of the inherited data - nodes (e.g., multicast) can be refined at the VPN network access - level. In such case, refined values take precedence over - inherited ones. + by the VPN network access. However, some inherited data nodes + (e.g., multicast) can be refined at the VPN network access level. + In such case, refined values take precedence over inherited ones. 'status': Indicates both operational 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 of a VPN network access (e.g., IP addressing). See Section 7.6.2. - 'routing-protocols': Includes the CE-PE rouing configuration + '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) @@ -1157,32 +1156,33 @@ 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 to configure the relevant tags. The interface that is attached to the L3VPN is identified by the - 'port-id' at the 'vpn-network-access' level. From a network model - perspective, it is expected that the 'port-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'. + '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 tunneling service (e.g., VPLS, VXLAN). An identity, called 'l2-tunnel-type', is defined for layer 2 - tunnel selection. + tunnel selection. The container can also identify the pseudowire + (Section 5.2 of [RFC4447]). As discussed in Section 7.6, 'l2vpn-id' is used to identify the L2VPN service that is associated with an 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 @@ -1217,48 +1217,48 @@ | | | | +--rw far-end? union | | | +--rw vpls | | | | +--rw vcid? uint32 | | | | +--rw far-end* union | | | +--rw vxlan {vpn-common: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? vpn-common:vpn-id - | +--rw local-bridge-reference? vpn-common:vpn-id + | +--rw l2-termination-point? string + | +--rw local-bridge-reference? string | +--rw bearer-reference? string {vpn-common:bearer-reference}? ... 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 than the one - indicated under the 'connection' container may be needed to terminate - the layer 3 service. The identifier of such interface is included in - 'l3-termination-point'. For example, this data node can be used to - carry the identifier of a bridge domain Interface. + configuration. Note that a distinct layer 3 interface other than the + one indicated under the 'connection' container may be needed to + terminate the layer 3 service. The identifier of such 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? vpn-common:vpn-id + | +--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, @@ -1269,21 +1269,21 @@ When 'address-allocation-type' is set to 'provider-dhcp', DHCP assignments can be made locally or by an external DHCP server. Such as 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? vpn-common:vpn-id + | +--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* @@ -1314,21 +1314,21 @@ (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? vpn-common:vpn-id + | +--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)? | | +--rw provider-dhcp | | +--rw dhcp-service-type? enumeration | | +--rw (service-type)? @@ -1358,21 +1358,21 @@ Figure 12: IP Connection Subtree Structure (IPv6) In the case of the 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? vpn-common:vpn-id + | +--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}? @@ -1385,21 +1385,21 @@ | +--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 - protocol is enabled between the PE and the CE. Each instance is + 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 @@ -1420,22 +1420,22 @@ | +--rw rip {vpn-common:rtg-rip}? | | ... | +--rw vrrp {vpn-common:rtg-vrrp}? | ... +--rw security ... Figure 14: Routing Subtree Structure Multiple routing instances can be defined; each uniquely identified - by an 'id'. The type of a routing instance is indicated in 'type'. - The values of this attributes are those defined in + by an 'id'. The type of routing instance is indicated in 'type'. + The values of these attributes are those defined in [I-D.ietf-opsawg-vpn-common] ('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 to decide about 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, @@ -1443,24 +1443,24 @@ as: o Multiple BGP processes with a single neighbor running in each process. o A single BGP process with multiple neighbors running. o A combination thereof. Routing configuration does not include low-level policies. Such - policies are handed at the device configuration level. Local - policies of a service provider (e.g., filtering) will be implemented - as part of the device configuration; these are not captured in the - L3NM, but the model allows to associate local profiles with routing + 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'). The L3NM supports the configuration of one or more IPv4/IPv6 static routes. Since the same structure is used for both IPv4 and IPv6, it was considered to have one single container to group both static entries independently of their address family, but that design was abandoned to ease the mapping with the structure in [RFC8299]. As depicted in Figure 15, the following data nodes can be defined for a given IP prefix: @@ -1495,63 +1495,63 @@ | | | {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-updated? yang:date-and-time + | | | | +--rw last-change? yang:date-and-time | | | +--ro oper-status | | | +--ro status? identityref - | | | +--ro last-updated? yang:date-and-time + | | | +--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-updated? yang:date-and-time + | | | +--rw last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref - | | +--ro last-updated? yang:date-and-time + | | +--ro last-change? yang:date-and-time ... Figure 15: Static Routing Subtree Structure In addition, the L3NM supports the following CE-PE routing protocols: - BGP: The L3NM allows to configure a BGP neighbor, including a set - for parameters that are pertinent to be tweaked at the network - level for service customization purposes. + BGP: The L3NM allows the configuration of a BGP neighbor, including + a set for parameters that are pertinent to be tweaked at the + network level for service customization purposes. This container does not aim to include every BGP parameter; a comprehensive set of parameters belongs more to the BGP device model. The following data nodes are captured in Figure 16. It is up to the implementation to derive the corresponding BGP device configuration: 'description': Includes a description of the BGP session. 'local-autonomous-system': Indicates a local AS Number (ASN) if a - distinct ASN than the one configured at the VPN node level is - needed. + distinct ASN is required, other than the one configured at the + VPN node level. 'peer-autonomous-system': Conveys the customer's ASN. 'address-family': Indicates the address-family of the peer. It can be set to IPv4, IPv6, or dual-stack. '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- @@ -1592,40 +1592,40 @@ Extended 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 such limit is reached, the + allowed in the BGP session. If the limit is reached, the action indicated in 'action-violate' 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 are: send a warning message, discard extra paths from the peer, or restart the session. 'bgp-timers': Two timers can be captured in this container: (1) 'hold-time' which is the time interval that will be used for the HoldTimer (Section 4.2 of [RFC4271]) when establishing a BGP session. (2) 'keepalive' which is the time interval for the KeepAlive timer between a PE and a BGP peer (Section 4.4 of [RFC4271]). - 'security': The module adheres to the recommendations in - Section 13.2 of [RFC4364] as it allows to enable TCP-AO + 'authentication': The module adheres to the recommendations in + Section 13.2 of [RFC4364] as it allows enabling TCP-AO [RFC5925] and accommodates the installed base that makes use of MD5. In addition, the module includes a provision for the use of IPsec. 'status': Indicates the status of the BGP routing instance. ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... @@ -1647,42 +1647,42 @@ | | | +--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-interval? uint16 | | +--rw bgp-timers | | | +--rw keepalive? uint16 | | | +--rw hold-time? uint16 - | | +--rw security + | | +--rw authentication | | | +--rw enable? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(tcp-ao) | | | | +--rw enable-tcp-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-updated? yang:date-and-time + | | | +--rw last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref - | | +--ro last-updated? yang:date-and-time + | | +--ro last-change? yang:date-and-time ... Figure 16: BGP Routing Subtree Structure OSPF: OSPF can be configured to run as a routing protocol on the 'vpn-network-access'. The following data nodes are captured in Figure 17: 'address-family': Indicates whether IPv4, IPv6, or both address families are to be activated. @@ -1695,57 +1695,58 @@ 'metric': Associates a metric with OSPF routes. 'sham-links': Is 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 LSAs that the OSPF instance will accept. - 'security': Controls the authentication schemes to be enabled for - the OSPF instance. The following options are supported: IPsec - for OSPFv3 authentication [RFC4552], authentication trailer for - OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166]. + 'authentication': Controls the authentication schemes to be + enabled for the OSPF instance. The following options are + supported: IPsec for OSPFv3 authentication [RFC4552], + authentication trailer for OSPFv2 [RFC5709] [RFC7474] and + OSPFv3 [RFC7166]. 'status': Indicates the status of the OSPF routing instance. ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... | +--rw ospf {vpn-common:rtg-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 | | | | vpn-common:vpn-id | | | +--rw metric? uint16 | | +--rw max-lsa? uint32 - | | +--rw security + | | +--rw authentication | | | +--rw enable? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(md5) | | | | +--rw md5-keychain? | | | | kc:key-chain-ref | | | +--:(ipsec) | | | +--rw sa? string | | +--rw status | | +--rw admin-status | | | +--rw status? identityref - | | | +--rw last-updated? yang:date-and-time + | | | +--rw last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref - | | +--ro last-updated? yang:date-and-time + | | +--ro last-change? yang:date-and-time ... Figure 17: OPSF Routing Subtree Structure IS-IS: The model (Figure 18) allows the user to configure IS-IS [ISO10589][RFC1195][RFC5308] to run on the 'vpn-network-access' interface. The following IS-IS data nodes are supported: 'address-family': Indicates whether IPv4, IPv6, or both address families are to be activated. @@ -1754,55 +1755,55 @@ '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). - 'security': 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': 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 algorithm are supported. 'status': Indicates the status of the OSPF routing instance. ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... | +--rw isis {vpn-common:rtg-isis}? | | +--rw address-family? identityref | | +--rw area-address area-address | | +--rw level? identityref | | +--rw metric? uint16 | | +--rw mode? enumeration - | | +--rw security + | | +--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-updated? yang:date-and-time + | | | +--rw last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref - | | +--ro last-updated? yang:date-and-time + | | +--ro last-change? yang:date-and-time ... Figure 18: IS-IS Routing Subtree Structure RIP: The model allows the user to configure RIP to run on the 'vpn- network-access' interface. 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 @@ -1818,60 +1819,60 @@ declared invalid. 'holddown-interval': Is the interval before better RIP routes are released. 'flush-interval': Is the interval before a route is removed from the routing table. 'default-metric': Sets the default RIP metric. - 'security': Controls the authentication schemes to be enabled for - the RIP instance. + 'authentication': Controls the authentication schemes to be + enabled for the RIP instance. 'status': Indicates the status of the RIP routing instance. ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... | +--rw rip {vpn-common:rtg-rip}? | | +--rw address-family? identityref | | +--rw timers | | | +--rw update-interval? uint16 | | | +--rw invalid-interval? uint16 | | | +--rw holddown-interval? uint16 | | | +--rw flush-interval? uint16 | | +--rw neighbor* inet:ip-address | | +--rw default-metric? uint8 - | | +--rw security + | | +--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-updated? yang:date-and-time + | | | +--rw last-change? yang:date-and-time | | +--ro oper-status | | +--ro status? identityref - | | +--ro last-updated? yang:date-and-time + | | +--ro last-change? yang:date-and-time ... Figure 19: RIP Subtree Structure - VRRP: The model (Figure 20) allows to enable VRRP on the 'vpn- + VRRP: The model (Figure 20) allows enabling VRRP on the 'vpn- network-access' interface. 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': Is used to identify the VRRP group. 'backup-peer': Carries the IP address of the peer. @@ -1879,42 +1880,42 @@ '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 ping requests can be replied to. 'status': Indicates the status of the VRRP instance. - Note that no security data node is included for VRRP as there - isn't currently any type of VRRP authentication (see Section 9 of - [RFC5798]). + Note that no authentication data node is included for VRRP as + there isn't currently any type of VRRP authentication (see + Section 9 of [RFC5798]). ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... | +--rw vrrp {vpn-common:rtg-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-updated? yang:date-and-time + | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref - | +--ro last-updated? yang:date-and-time + | +--ro last-change? yang:date-and-time ... Figure 20: VRRP Subtree Structure 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. The current data nodes can be specified: @@ -1926,48 +1927,49 @@ 'required-min-rx-interval': Is the minimum interval, in microseconds, between received BFD Control packets that a PE is capable of supporting, less any jitter applied by the sender. 'detection-multiplier': The negotiated transmit interval, multiplied by this value, provides the detection time for the PE. 'holdtime': Is used to indicate the expected BFD holddown time. The value can be set by the customer or selected from a profile. - 'security': Includes the required information to enable the BFD - authentication modes discussed in Section 6.7 of [RFC5880]. In - particular 'meticulous' controls the activation of the meticulous - mode discussed in Sections 6.7.3 and 6.7.4 of [RFC5880]. + '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 the + meticulous mode discussed in Sections 6.7.3 and 6.7.4 of + [RFC5880]. 'status': Indicates the status of BFD. ... +--rw oam | +--rw bfd {vpn-common:bfd}? | +--rw desired-min-tx-interval? uint32 | +--rw required-min-rx-interval? uint32 | +--rw detection-multiplier? uint8 | +--rw (holdtime)? | | +--:(fixed) | | | +--rw fixed-value? uint32 | | +--:(profile) | | | +--rw profile-name? leafref | +--rw authentication! | | +--rw key-chain? key-chain:key-chain-ref | | +--rw meticulous? boolean | +--rw status | +--rw admin-status | | +--rw status? identityref - | | +--rw last-updated? yang:date-and-time + | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref - | +--ro last-updated? yang:date-and-time + | +--ro last-change? yang:date-and-time ... Figure 21: IP Connection Subtree Structure (OAM) 7.6.5. Security The 'security' container specifies the authentication and the encryption to be applied for a given VPN network access traffic. As depicted in the subtree shown in Figure 22, the L3NM can be used to directly control the encryption to put in place (e.g., Layer 2 or @@ -2002,50 +2004,51 @@ 7.6.6. Services 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 input-bandwidth? uint64 {vpn-common:input-bw}? - +--rw output-bandwidth? uint64 {vpn-common:output-bw}? + +--rw inbound-bandwidth? uint64 {vpn-common:inbound-bw}? + +--rw outbound-bandwidth? uint64 {vpn-common:outbound-bw}? +--rw mtu? uint16 +--rw qos {vpn-common:qos}? | ... - +--rw carrierscarrier - | {vpn-common:carrierscarrier}? - | +--rw signalling-type? enumeration + +--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-updated? yang:date-and-time + | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref - | +--ro last-updated? yang:date-and-time + | +--ro last-change? yang:date-and-time +--rw multicast {vpn-common:multicast}? ... Figure 23: Services Subtree Structure The following data nodes are defined: - 'input-bandwidth': Indicates the inbound bandwidth of the connection - (i.e., download bandwidth from the service provider to the site). + 'inbound-bandwidth': Indicates the inbound bandwidth of the + connection (i.e., download bandwidth from the service provider to + the site). - 'output-bandwidth': Indicates the outbound bandwidth of the + 'outbound-bandwidth': Indicates the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider). 'mtu': Indicates the MTU at the service level. 'qos': 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. @@ -2139,21 +2142,21 @@ Figure 25: QoS Subtree Structure (L3) Layer 4: As discussed in [I-D.ietf-opsawg-vpn-common], 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 crietria can be specified in the L3NM + TCP or UDP-related match criteria can be specified in the L3NM as shown in Figure 26. +--rw qos {vpn-common:qos}? | +--rw qos-classification-policy | | +--rw rule* [id] | | +--rw id string | | +--rw (match-type)? | | | +--:(match-flow) | | | | +--rw (l3)? | | | | | ... @@ -2223,22 +2226,23 @@ | | | | +--rw operator? operator | | | | +--rw port | | | | inet:port-number ... Figure 26: QoS Subtree Structure (L4) Application match: Relies upon application-specific classification. - 'carrierscarrier': Groups a set of parameters that are used when CsC - is enabled such the use of BGP for signalling purposes [RFC8277]. + 'carrierscarrier': Groups a set of parameters that are used when + Carriers' Carriers (CsC) is enabled such the use of 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.7. Multicast @@ -2410,60 +2414,60 @@ | | 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-updated? yang:date-and-time + | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref - | +--ro last-updated? yang:date-and-time + | +--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-updated? yang:date-and-time + | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref - | +--ro last-updated? yang:date-and-time + | +--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-updated? yang:date-and-time + | +--rw last-change? yang:date-and-time +--ro oper-status +--ro status? identityref - +--ro last-updated? yang:date-and-time + +--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] and [RFC8343]. It also uses groupings defined in [RFC8519], [RFC8177], and [RFC8294]. - file "ietf-l3vpn-ntw@2021-05-18.yang" + file "ietf-l3vpn-ntw@2021-07-12.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 UUUU: A Layer 2/3 VPN Common YANG Model"; } @@ -2487,21 +2491,21 @@ 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 OPSA (Operations and Management Area) Working Group "; + "IETF OPSAWG (Operations and Management Area Working Group)"; contact "WG Web: WG List: Author: Samier Barguil Editor: Oscar Gonzalez de Dios Editor: Mohamed Boucadair @@ -2519,21 +2523,21 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2021-05-18 { + revision 2021-07-12 { description "Initial revision."; reference "RFC XXXX: A Layer 3 VPN Network YANG Model"; } /* Features */ feature msdp { description @@ -2570,53 +2574,37 @@ 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-to-customer addressing is static."; + "The Provider's network provides static IP addressing to the + customer."; } identity slaac { if-feature "vpn-common:ipv6"; base address-allocation-type; description - "Use IPv6 SLAAC."; + "The Provider's network uses IPv6 SLAAC to provide addressing + to the customer."; reference "RFC 4862: IPv6 Stateless Address Autoconfiguration"; } - identity bearer-inf-type { - description - "Identity for the bearer interface type."; - } - - identity port-id { - base bearer-inf-type; - description - "Identity for the priority-tagged interface."; - } - - identity lag-id { - base bearer-inf-type; - description - "Identity for the lag-tagged interface."; - } - identity local-defined-next-hop { description - "Defines a base identity type of local defined - next-hops."; + "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 blackhole traffic."; } @@ -2677,72 +2665,72 @@ 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 called at the VPN node and VPN network access levels."; leaf local-autonomous-system { if-feature "vpn-common:rtg-bgp"; type inet:as-number; description - "Provider's Autonomous System (AS) number in case the + "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 per-address family parameters."; leaf address-family { type identityref { base vpn-common:address-family; } description - "Indicates the address family (IPv4 or IPv6)."; + "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 maximum routes for the VRF."; + "Defines the maximum number of routes for the VRF."; leaf protocol { type identityref { base vpn-common:routing-protocol-type; } description "Indicates the routing protocol. 'any' value can be used to identify a limit that will apply for each active routing protocol."; } leaf maximum-routes { type uint32; description - "Indicates the maximum prefixes that the VRF can - accept for this address family and protocol."; + "Indicates the maximum number of prefixes that the + VRF can accept for this address family and protocol."; } } } container multicast { if-feature "vpn-common:multicast"; description "Global multicast parameters."; leaf-list tree-flavor { type identityref { base vpn-common:multicast-tree-type; } description - "Type of the tree to be used."; + "Type of tree to be used."; } container rp { description "Rendezvous Point (RP) parameters."; container rp-group-mappings { description "RP-to-group mappings parameters."; list rp-group-mapping { key "id"; description @@ -2916,64 +2904,64 @@ type uint32; description "Indicates the maximum IGMP entries."; } leaf version { type identityref { base vpn-common:igmp-version; } default "vpn-common:igmpv2"; description - "Version of the IGMP."; + "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 to the - MLD session"; + "Multicast static source/group associated with the + MLD session."; leaf group-addr { type rt-types:ipv6-multicast-group-address; description "Multicast group IPv6 addresss."; } leaf source-addr { type rt-types:ipv6-multicast-source-address; description "Multicast source IPv6 addresss."; } } leaf max-groups { type uint32; description - "Indicates the maximum groups."; + "Indicates the maximum number of groups."; } leaf max-entries { type uint32; description - "Indicates the maximum MLD entries."; + "Indicates the maximum number of MLD entries."; } leaf version { type identityref { base vpn-common:mld-version; } default "vpn-common:mldv2"; description - "Version of the MLD protocol."; + "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 protocol type is PIM."; @@ -3012,21 +3000,21 @@ description "Main container for L3VPN services management."; 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 - "Top-level container for the VPN services."; + "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+ @@ -3206,24 +3191,28 @@ "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 port-id { - type vpn-common:vpn-id; + leaf interface-id { + type string; description - "Identifier for the interface."; + "Identifier for the physical or logical + interface. + The identification of the sub-interface + is provided at the connection and/or IP + connection levels."; } 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; } @@ -3273,21 +3261,23 @@ 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; + 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'."; @@ -3311,37 +3301,36 @@ "Only applies when the type of the tagged interface is QinQ."; } if-feature "vpn-common:qinq"; description "Includes QinQ parameters."; leaf tag-type { type identityref { base vpn-common:tag-type; } - default "vpn-common:c-s-vlan"; + default "vpn-common:s-c-vlan"; description "Tag type. By default, the tag type is 'c-s-vlan'."; } leaf svlan-id { type uint16; mandatory true; description - "SVLAN identifier."; + "S-VLAN identifier."; } leaf cvlan-id { type uint16; mandatory true; description - "CVLAN identifier."; - + "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 @@ -3366,29 +3355,33 @@ description "Indicates a PW or VC identifier."; } leaf far-end { type union { type uint32; type inet:ip-address; } description "Neighbor reference."; + reference + "RFC 4447: Pseudowire Setup and Maintenance + Using the Label Distribution Protocol + (LDP), Section 5.2"; } } container vpls { description "VPLS termination parameters."; leaf vcid { type uint32; description - "VCID identifier."; + "VC Identifier."; } leaf-list far-end { type union { type uint32; type inet:ip-address; } description "Neighbor reference."; } } @@ -3422,135 +3415,128 @@ 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 vpn-common:vpn-id; + 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 vpn-common:vpn-id; + 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 ip-connection { description "Defines IP connection parameters."; leaf l3-termination-point { - type vpn-common:vpn-id; + 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 - "This address is used at the provider side."; + "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."; + 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 { - when "derived-from-or-self(./address-" - + "allocation-type, 'provider-dhcp')" { - description - "Only applies when addresses are allocated - by DHCP that is operated by the provider."; - } description "DHCP allocated addresses related - parameters."; + parameters. IP addresses are allocated + by DHCP that is operated by the provider"; 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 the DHCP service to + "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 { - when "./dhcp-service-type = 'relay'"; description "Container for list of provider's DHCP - servers."; + 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 to use by the local DHCP relay."; } } case server { - when "./dhcp-service-type = 'server'"; description "A choice about how addresses are assigned when a local DHCP server is enabled."; choice address-assign { default "number"; description "Choice for how IPv4 addresses are assigned."; case number { leaf number-of-dynamic-address { @@ -3567,23 +3553,23 @@ 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 or only - end-address is present, it - represents a single address. + 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- @@ -3581,71 +3567,58 @@ 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 { - when "derived-from-or-self(./address-allocation" - + "-type, 'provider-dhcp-relay')" { - description - "Only applies when the provider is required - to implement a DHCP relay function that - will relay DHCP requests to a customer's - DHCP server."; - } description "DHCP relay is provided by the operator."; container customer-dhcp-servers { description "Container for a list of 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 { - when "derived-from-or-self(./address-allocation" - + "-type, 'static-address')" { - description - "Only applies when address allocation - type is static."; - } 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 { @@ -3724,37 +3697,28 @@ } } 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 provider-dhcp-servers { - when "./dhcp-service-type = 'relay'"; - description - "Case where a local DHCPv6 relay is - enabled. This list is used if and only - if a DHCP relay is enabled."; leaf-list server-ip-address { type inet:ipv6-address; description "IPv6 addresses of the provider's DHCPv6 server."; } } case server { - when "./dhcp-service-type = 'server'"; - description - "Case where a local DHCPv6 server is - enabled."; choice address-assign { default "number"; description "Choice about how IPv6 prefixes are assigned by the DHCPv6 server."; case number { leaf number-of-dynamic-address { type uint16; default "1"; description @@ -3767,37 +3731,38 @@ 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 or only - end-address is present, it - represents a single address. + 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 "Pool identifier for the address range from identified by start- address and 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."; } } } @@ -3796,35 +3761,27 @@ } leaf end-address { type inet:ipv6-address; description "Indicates the last address."; } } } } } + } } } case dhcp-relay { - when "derived-from-or-self(./address-allo" - + "cation-type, 'provider-dhcp-relay')" { - description - "Only applies when the provider is required - to implement DHCP relay function that will - relay DHCPv6 requests to a customer's DHCP - server."; - } description "DHCPv6 relay provided by the operator."; - container customer-dhcp-servers { description "Container for a list of customer DHCP servers."; leaf-list server-ip-address { type inet:ipv6-address; description "Contains the IP addresses of the customer DHCPv6 server."; } @@ -3824,26 +3781,20 @@ servers."; leaf-list server-ip-address { type inet:ipv6-address; description "Contains the IP addresses of the customer DHCPv6 server."; } } } case static-addresses { - when "derived-from-or-self(./address-allocation" - + "-type, 'static-address')" { - description - "Only applies when protocol allocation type - is static."; - } description "IPv6-specific parameters for static allocation."; leaf primary-address { type leafref { path "../address/address-id"; } description "Principal address of the connection"; } @@ -3902,21 +3853,21 @@ 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')" { + + "'vpn-common:static-routing')" { description "Only applies when protocol is static."; } 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"; @@ -3935,22 +3886,22 @@ 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, an interface, - or a pre-defined next-hop type (e.g., + specified as an IP address or a + pre-defined 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; @@ -3983,23 +3934,22 @@ 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, an interface, or a - pre-defined next-hop type (e.g., - discard or local-link)."; + an IP address or a pre-defined 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 @@ -4004,57 +3954,58 @@ 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')" { + + "'vpn-common:bgp-routing')" { description "Only applies when protocol is BGP."; } if-feature "vpn-common:rtg-bgp"; description "BGP-specific configuration."; leaf description { type string; description "Includes a description of the BGP session. - Such description is meant to be used for + This description is meant to be used for diagnosis purposes. The semantic of the description is local to an implementation."; } leaf local-autonomous-system { type inet:as-number; description "Indicates a local AS Number (ASN) if a distinct ASN than the one configured at the VPN node level is needed."; } leaf peer-autonomous-system { type inet:as-number; mandatory true; description - "Indicates the customer's ASN in - case the customer requests BGP routing."; + "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."; } @@ -4101,25 +4052,29 @@ 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 one configured at the - VPN network access level. When set to - 'true', this parameter prevents that - the ASN provided at the VPN node - level is also prepended to the BGP - route updates for this access."; + 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, the 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 default-route { type boolean; default "false"; description "Defines whether default routes can be advertised to its peer. If set, the default routes are advertised to its peer."; } @@ -4179,21 +4134,21 @@ 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 to control how many prefixes + 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 { @@ -4215,21 +4170,22 @@ the peer when the limit is exceeded."; } enum discard-extra-paths { description "Discards extra paths when the limit is exceeded."; } enum restart { description - "Restarts after a time interval."; + "The BGP session restarts after + a time interval."; } } description "BGP neighbor max-prefix violate action"; } leaf restart-interval { type uint16; units "minutes"; description @@ -4276,24 +4233,24 @@ 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 security { + container authentication { description - "Container for BGP security parameters - between a PE and a CE."; + "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 @@ -4367,21 +4325,21 @@ "Indicates the name of the SA."; } } } } } uses vpn-common:service-status; } container ospf { when "derived-from-or-self(../type, " - + "'vpn-common:ospf')" { + + "'vpn-common:ospf-routing')" { description "Only applies when protocol is OSPF."; } if-feature "vpn-common:rtg-ospf"; description "OSPF-specific configuration."; leaf address-family { type identityref { base vpn-common:address-family; } @@ -4422,21 +4379,21 @@ 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 vpn-common:vpn-id; + type string; description "Target site for the sham link connection. The site is referred to by its ID."; } leaf metric { type uint16; default "1"; description "Metric of the sham link. It is used in the routing state calculation and path @@ -4453,21 +4410,21 @@ } } } leaf max-lsa { type uint32 { range "1..4294967294"; } description "Maximum number of allowed LSAs OSPF."; } - container security { + container authentication { description "Authentication configuration."; leaf enable { type boolean; default "false"; description "Enables or disables authentication."; } container keying-material { when "../enable = 'true'"; @@ -4516,21 +4473,21 @@ OSPFv3"; } } } } } uses vpn-common:service-status; } container isis { when "derived-from-or-self(../type, " - + "'vpn-common:isis')" { + + "'vpn-common:isis-routing')" { description "Only applies when protocol is IS-IS."; } if-feature "vpn-common:rtg-isis"; description "IS-IS specific configuration."; leaf address-family { type identityref { base vpn-common:address-family; } @@ -4570,21 +4527,21 @@ description "Suppresses the sending of IS-IS updates through the specified interface."; } } default "active"; description "IS-IS interface mode type."; } - container security { + container authentication { description "Authentication configuration."; leaf enable { type boolean; default "false"; description "Enables or disables authentication."; } container keying-material { when "../enable = 'true'"; @@ -4622,21 +4579,21 @@ associated with the key."; } } } } } uses vpn-common:service-status; } container rip { when "derived-from-or-self(../type, " - + "'vpn-common:rip')" { + + "'vpn-common:rip-routing')" { description "Only applies when the protocol is RIP. For IPv4, the model assumes that RIP version 2 is used."; } if-feature "vpn-common:rtg-rip"; description "Configuration specific to RIP routing."; leaf address-family { type identityref { @@ -4699,21 +4656,21 @@ } } leaf default-metric { type uint8 { range "0..16"; } default "1"; description "Sets the default metric."; } - container security { + container authentication { description "Authentication configuration."; leaf enable { type boolean; default "false"; description "Enables or disables authentication."; } container keying-material { when "../enable = 'true'"; @@ -4746,21 +4703,21 @@ associated with the key."; } } } } } uses vpn-common:service-status; } container vrrp { when "derived-from-or-self(../type, " - + "'vpn-common:vrrp')" { + + "'vpn-common:vrrp-routing')" { description "Only applies when protocol is VRRP."; } if-feature "vpn-common:rtg-vrrp"; description "Configuration specific to VRRP."; reference "RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6"; leaf address-family { @@ -4816,34 +4773,35 @@ "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 desired-min-tx-interval { type uint32; - units microseconds; - default 1000000; + units "microseconds"; + default "1000000"; description "The minimum interval between transmission of BFD control packets that the operator desires."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.8.7"; } leaf required-min-rx-interval { type uint32; - units microseconds; + units "microseconds"; 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 detection-multiplier { type uint8 { range "1..max"; @@ -4863,22 +4821,22 @@ "Choice for holdtime flavor."; case fixed { leaf fixed-value { type uint32; units "msec"; description "Expected BFD holdtime. The customer may impose some fixed values for the holdtime period if the - provider allows the customer use this - function. + provider allows the customer use of + this function. If the provider doesn't allow the customer to use this function, the fixed-value will not be set."; } } case profile { description "Well-known SP profile."; leaf profile-name { @@ -4923,22 +4881,22 @@ "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 true, traffic encryption on the - connection is required. It is - disabled, otherwise."; + connection is required. Otherwise, it + is disabled."; } leaf layer { when "../enabled = 'true'" { description "Indicates the layer on which encryption is enabled."; } type enumeration { enum layer2 { description @@ -4986,48 +4944,53 @@ description "Customer-supplied key chain."; } } } } } container service { description "Service parameters of the attachment."; - leaf input-bandwidth { - if-feature "vpn-common:input-bw"; + leaf inbound-bandwidth { + if-feature "vpn-common:inbound-bw"; type uint64; units "bps"; description "From the customer site's perspective, the - service input bandwidth of the connection + service inbound bandwidth of the connection or download bandwidth from the SP to - the site."; + the site. Note that the L3SM uses 'input- + -bandwidth' to refer to the same concept."; } - leaf output-bandwidth { - if-feature "vpn-common:output-bw"; + leaf outbound-bandwidth { + if-feature "vpn-common:outbound-bw"; type uint64; units "bps"; description "From the customer site's perspective, - the service output bandwidth of the + the service oubtound bandwidth of the connection or upload bandwidth from - the site to the SP."; + the site to the SP. Note that the L3SM uses + 'output-bandwidth' to refer to the same + concept."; + } leaf mtu { type uint16; units "bytes"; description "MTU at service level. If the service is IP, - it refers to the IP MTU. If CsC is enabled, - the requested MTU will refer - to the MPLS MTU and not to the IP MTU."; + it refers to the IP MTU. If Carriers' + Carriers (CsC) is enabled, the requested MTU + will refer to the MPLS MTU 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; @@ -5101,52 +5063,51 @@ base vpn-common:qos-profile-direction; } default "vpn-common:both"; description "The direction to which the QoS profile is applied."; } } } } - container carrierscarrier { - if-feature "vpn-common:carrierscarrier"; + 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 MPLSservice using an IP VPN to carry its traffic)."; - - leaf signalling-type { + leaf signaling-type { type enumeration { enum ldp { description - "Use LDP as the signalling protocol + "Use LDP as the signaling protocol between the PE and the CE. In this case, an IGP routing protocol must - also be activated."; + also be configured."; } enum bgp { description - "Use BGP as the signalling protocol + "Use 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 signalling type."; + "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 NTP service."; reference "RFC 5905: Network Time Protocol Version 4: @@ -5416,24 +5378,25 @@ These are the subtrees and data nodes and their sensitivity/ vulnerability in the "ietf-l3vpn-ntw" module: o 'vpn-service': 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), leading to malfunctioning of the service and therefore to SLA violations. In addition, an attacker could attempt to create an L3VPN service or adding a new - network access. Such activity can be detected by adequately - monitoring and tracking network configuration changes. + network access. In addition to using NACM to prevent authorized + 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 + Some readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: o '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 as a violation of the customer-provider trust relationship. @@ -5736,20 +5699,26 @@ Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, DOI 10.17487/RFC4110, July 2005, . [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, . + [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and + G. Heron, "Pseudowire Setup and Maintenance Using the + Label Distribution Protocol (LDP)", RFC 4447, + DOI 10.17487/RFC4447, April 2006, + . + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [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, . @@ -5926,34 +5895,34 @@ ] } } ] } } Figure 33: Create VPN Node Finally, two VPN network accesses are created using the same physical - port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular - VLAN (1,2) to differentiate the traffic between: Sync and data - (Figure 34). + port ('interface-id'=1/1/1). Each 'vpn-network-access' has a + particular VLAN (1,2) to differentiate the traffic between: Sync and + data (Figure 34). 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", - "port-id": "1/1/1", + "interface-id": "1/1/1", "description": "Interface SYNC to eNODE-B", "vpn-network-access-type": "vpn-common:point-to-point", "vpn-instance-profile": "simple-profile", "status": { "admin-status": { "status": "vpn-common:admin-state-up" } }, "connection": { "encapsulation": { @@ -5974,42 +5943,42 @@ { "address-id": "1", "customer-address": "192.0.2.2" } ] } }, "ipv6": { "local-address": "2001:db8::1", "prefix-length": 64, - "address-allocation-type": "ietf-l3vpn-ntw:static-address", + "address-allocation-type": "static-address", "primary-address": "1", "address": [ { "address-id": "1", "customer-address": "2001:db8::2" } ] } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "vpn-common:direct" } ] } }, { "id": "1/1/1.2", - "port-id": "1/1/1", + "interface-id": "1/1/1", "description": "Interface DATA to eNODE-B", "vpn-network-access-type": "vpn-common:point-to-point", "vpn-instance-profile": "simple-profile", "status": { "admin-status": { "status": "vpn-common:admin-state-up" } }, "connection": { "encapsulation": { @@ -6030,21 +5999,21 @@ { "address-id": "1", "customer-address": "192.0.2.2" } ] } }, "ipv6": { "local-address": "2001:db8::1", "prefix-length": 64, - "address-allocation-type": "ietf-l3vpn-ntw:static-address", + "address-allocation-type": "static-address", "primary-address": "1", "address": [ { "address-id": "1", "customer-address": "2001:db8::2" } ] } }, "routing-protocols": { @@ -6064,21 +6033,21 @@ A.2. Loopback Interface An example of loopback interface is depicted in Figure 35. { "ietf-l3vpn-ntw:vpn-network-accesses": { "vpn-network-access": [ { "id": "vpn-access-loopback", - "port-id": "Loopback1", + "interface-id": "Loopback1", "description": "An example of loopback interface.", "vpn-network-access-type": "vpn-common:loopback", "status": { "admin-status": { "status": "vpn-common:admin-state-up" } }, "ip-connection": { "ipv6": { "local-address": "2001:db8::4", @@ -6102,21 +6071,21 @@ and CE is achieved using BGP. Also, RP is statically configured for a multicast group. +-----------+ +------+ +------+ +-----------+ | Multicast |---| CE |--/--| PE |----| Backbone | | source | +------+ +------+ | IP/MPLS | +-----------+ +-----------+ Figure 36: Multicast L3VPN Service Example - An example is provided below to ilustrate how to configure a + An example is provided below to illustrate 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 37) { "ietf-l3vpn-ntw:vpn-services": { "vpn-service": [ { "vpn-id": "Multicast-IPTV", @@ -6215,33 +6184,33 @@ "customer-address": "203.0.113.2" } ] } } }, "routing-protocols": { "routing-protocol": [ { "id": "1", - "type": "vpn-common:bgp", + "type": "vpn-common:bgp-routing", "bgp": { "description": "Connected to CE", "peer-autonomous-system": "65537", "address-family": "vpn-common:ipv4", "neighbor": "203.0.113.2" } } ] }, "service": { - "input-bandwidth": "100000000", - "output-bandwidth": "100000000", + "inbound-bandwidth": "100000000", + "outbound-bandwidth": "100000000", "mtu": 1500, "multicast": { "access-type": "source-only", "address-family": "vpn-common:ipv4", "protocol-type": "router", "pim": { "hello-interval": 30, "status": { "admin-status": { "status": "vpn-common:admin-state-up" @@ -6307,20 +6276,22 @@ 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, and Tom Petch. Many thanks to them. Thanks to Philip Eardly for the review of an early version of the document. Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski contributed to early version of the individual submission. + Many thanks to Robert Wilton for the AD 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 Telefonica Email: victor.lopezalvarez@telefonica.com