--- 1/draft-ietf-opsawg-l3sm-l3nm-13.txt 2021-09-28 02:13:05.228280999 -0700 +++ 2/draft-ietf-opsawg-l3sm-l3nm-14.txt 2021-09-28 02:13:05.428283440 -0700 @@ -1,24 +1,24 @@ OPSAWG S. Barguil Internet-Draft O. Gonzalez de Dios, Ed. Intended status: Standards Track Telefonica -Expires: 31 March 2022 M. Boucadair, Ed. +Expires: 1 April 2022 M. Boucadair, Ed. Orange L. Munoz Vodafone A. Aguado Nokia - 27 September 2021 + 28 September 2021 A Layer 3 VPN Network YANG Model - draft-ietf-opsawg-l3sm-l3nm-13 + draft-ietf-opsawg-l3sm-l3nm-14 Abstract As a complement to the Layer 3 Virtual Private Network Service YANG data Model (L3SM), used for communication between customers and service providers, 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. @@ -51,21 +51,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 31 March 2022. + This Internet-Draft will expire on 1 April 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 carefully, as they describe your rights @@ -1224,40 +1224,40 @@ request (e.g., L3SM) and L3NM. The L3NM can be used to create a 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 {vpn-common:dot1q}? + | | +--rw dot1q | | | +--rw tag-type? identityref | | | +--rw cvlan-id? uint16 | | +--rw priority-tagged | | | +--rw tag-type? identityref - | | +--rw qinq {vpn-common:qinq}? + | | +--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 {vpn-common:vxlan}? + | | | +--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}? @@ -1443,29 +1443,29 @@ ... +--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 {vpn-common:rtg-bgp}? + | +--rw bgp | | ... - | +--rw ospf {vpn-common:rtg-ospf}? + | +--rw ospf | | ... - | +--rw isis {vpn-common:rtg-isis}? + | +--rw isis | | ... - | +--rw rip {vpn-common:rtg-rip}? + | +--rw rip | | ... - | +--rw vrrp {vpn-common:rtg-vrrp}? + | +--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 [I-D.ietf-opsawg-vpn-common] ('routing-protocol-type' identity). @@ -1585,21 +1585,21 @@ for 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 following data nodes are captured in ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... - | +--rw bgp {vpn-common:rtg-bgp}? + | +--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 @@ -1743,21 +1743,21 @@ 7.6.3.3. OSPF OSPF can be configured to run as a routing protocol on the 'vpn- network-access'. ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... - | +--rw ospf {vpn-common:rtg-ospf}? + | +--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 | | | | vpn-common:vpn-id | | | +--rw metric? uint16 | | +--rw max-lsa? uint32 | | +--rw authentication @@ -1817,21 +1817,21 @@ 7.6.3.4. IS-IS The model (Figure 18) allows the user to configure IS-IS [ISO10589][RFC1195][RFC5308] to run on the 'vpn-network-access' interface. ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... - | +--rw isis {vpn-common:rtg-isis}? + | +--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) @@ -1877,21 +1877,21 @@ 7.6.3.5. RIP The model (As shown in Figure 19) allows the user to configure RIP to run on the 'vpn-network-access' interface. ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... - | +--rw rip {vpn-common:rtg-rip}? + | +--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 neighbor* inet:ip-address | | +--rw default-metric? uint8 | | +--rw authentication | | | +--rw enable? boolean @@ -1942,21 +1942,21 @@ 7.6.3.6. VRRP The model (The following data nodes are supported:Figure 20) allows enabling VRRP on the 'vpn-network-access' interface. ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... - | +--rw vrrp {vpn-common:rtg-vrrp}? + | +--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 @@ -2552,21 +2552,21 @@ +--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] and [RFC8343]. It also uses groupings defined in [RFC8519], [RFC8177], and [RFC8294]. - file "ietf-l3vpn-ntw@2021-09-10.yang" + file "ietf-l3vpn-ntw@2021-09-28.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"; } @@ -2622,21 +2622,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-09-10 { + revision 2021-09-28 { description "Initial revision."; reference "RFC XXXX: A Layer 3 VPN Network YANG Model"; } /* Features */ feature msdp { description @@ -3347,21 +3347,20 @@ "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'."; } - if-feature "vpn-common: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'."; @@ -3393,21 +3393,20 @@ '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."; } - if-feature "vpn-common:qinq"; description "Includes QinQ parameters."; leaf tag-type { type identityref { base vpn-common:tag-type; } default "vpn-common:s-c-vlan"; description "Tag type. By default, the tag type is 'c-s-vlan'."; @@ -3496,21 +3495,20 @@ "Neighbor reference."; } } container vxlan { when "derived-from-or-self(../type, " + "'vxlan')" { description "Only applies when the type of the layer 2 service type is VXLAN."; } - if-feature "vpn-common:vxlan"; description "VXLAN termination parameters."; leaf vni-id { type uint32; mandatory true; description "VXLAN Network Identifier (VNI)."; } leaf peer-mode { type identityref { @@ -4105,28 +4100,28 @@ } 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 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. This description is meant to be used for diagnosis purposes. The semantic of the description is local to an @@ -4443,54 +4437,57 @@ } case explicit { leaf key-id { type uint32; description "Key Identifier."; } leaf key { type string; description - "BGP authentication key in ASCII - format."; + "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 IKE Security Association (SA)."; leaf sa { type string; description - "Indicates the name of the SA."; + "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 protocol is OSPF."; } - if-feature "vpn-common:rtg-ospf"; description "OSPF-specific configuration."; leaf address-family { type identityref { base vpn-common:address-family; } description "Indicates whether IPv4, IPv6, or both are to be activated."; } @@ -4592,55 +4589,57 @@ } case auth-key-explicit { leaf key-id { type uint32; description "Key identifier."; } leaf key { type string; description - "OSPF authentication key in ASCII - format."; + "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 name of the SA."; + "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 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; } description "Indicates whether IPv4, IPv6, or both are to be activated."; @@ -4711,22 +4710,24 @@ } case auth-key-explicit { leaf key-id { type uint32; description "Key Identifier."; } leaf key { type string; description - "IS-IS authentication key in ASCII - format."; + "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."; } } @@ -4727,30 +4728,30 @@ } 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."; } - if-feature "vpn-common:rtg-rip"; 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."; } @@ -4837,22 +4837,24 @@ leaf key-chain { type key-chain:key-chain-ref; description "key-chain name."; } } case auth-key-explicit { leaf key { type string; description - "RIP authentication key in ASCII - format."; + "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."; } } @@ -4860,21 +4862,20 @@ } } uses vpn-common:service-status; } container vrrp { when "derived-from-or-self(../type, " + "'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 { type identityref { base vpn-common:address-family; } description @@ -5065,23 +5066,23 @@ 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 encryption profile."; choice profile { description @@ -5499,31 +5500,31 @@ 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; } - } } } } } } } } } } + } 9. Security Considerations The YANG module specified in this document defines 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 @@ -6650,21 +6651,21 @@ 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 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 + contributed to an early version of the individual submission. 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, and Qin Wu for the opsdir review. Thanks to Michael Scharf for the discussion on TCP-AO. Thanks to Martin Duke, Lars Eagert, Zaheduzzaman Sarker, Roman Danyliw, Erik Kline, and Benjamin Kaduk 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