RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs
- S. Barguil,
- O. Gonzalez de Dios, Ed.,
- M. Boucadair, Ed.,
- Q. Wu
Abstract
This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
The IETF has specified YANG modules for VPN services, e.g., the Layer 3 VPN Service Model (L3SM) [RFC8299] or the Layer 2 VPN Service Model (L2SM) [RFC8466]. Other relevant YANG data models are the Layer 3 VPN Network Model (L3NM) [RFC9182] and the Layer 2 VPN Network Model (L2NM) [L2NM-YANG]. There are common data nodes and structures that are present in all of these models or at least a subset of them.¶
This document defines a common YANG module that is meant to be reused
by various VPN-related modules such as the L3NM [RFC9182] and the L2NM [L2NM-YANG]: "ietf
The "ietf
2. Terminology
The terminology for describing YANG modules is defined in [RFC7950].¶
The meanings of the symbols in tree diagrams are defined in [RFC8340].¶
The reader may refer to [RFC4026] and [RFC4176] for VPN-related terms.¶
This document inherits many terms from [RFC8299] and [RFC8466] (e.g., Enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), Massive Machine Type Communications (mMTC)).¶
3. Description of the VPN Common YANG Module
The "ietf
- Encapsulation features, such as the following:
-
- Multicast [RFC6513].
- Routing features, such as the following:
-
Also, the module defines a set of identities, including the following:¶
- 'service-type':
-
Used to identify the VPN service type. Examples of supported service types are as follows:¶
- 'vpn
-signaling -type' : -
Used to identify the signaling mode used for a given service type. Examples of supported VPN signaling types are as follows:¶
The module covers both IPv4 [RFC0791] and IPv6
[RFC8200] identities. It also includes
multicast
The reader should refer to Section 4 for the full list of supported identities (identities related to address families, VPN topologies, network access types, operational and administrative status, site or node role, VPN service constraints, routing protocols, route import and export policies, bandwidth, Quality of Service (QoS), etc.).¶
The "ietf
The descriptions of the common groupings are provided below:¶
- 'vpn
-description' : - A YANG grouping that provides common administrative VPN information such as an identifier, a name, a textual description, and a customer name.¶
- 'vpn
-profile -cfg' : -
A YANG grouping that defines a set of valid profiles (encryption, routing, forwarding, etc.) that can be bound to a Layer 2/3 VPN. This document does not make any assumptions about the structure of such profiles but allows "gluing" a VPN service with other parameters that can be required locally to provide value-added features to requesting customers.¶
For example, a service provider may provide external connectivity to a VPN customer (e.g., to a private or public cloud, Internet). Such a service may involve tweaking both filtering and NAT rules (e.g., binding a Virtual Routing and Forwarding (VRF) interface with a NAT instance as discussed in Section 2.10 of [RFC8512]). These value-added features may be bound to all, or a subset of, network accesses. Some of these value-added features may be implemented in nodes other than Provider Edges (PEs) (e.g., a P node or even a dedicated node that hosts the NAT function).¶
Elaborating on the structure of these profiles is beyond the scope of this document.¶
- 'oper
-status -timestamp' : - A YANG grouping that defines the operational status updates of a VPN service or component.¶
- 'service
-status' : - A YANG grouping that defines the administrative and operational status of a component. The grouping can be applied to the whole service or an endpoint.¶
- 'underlay
-transport' : -
A YANG grouping that defines the type of the underlay transport for a VPN service or how that underlay is set.¶
The underlay transport can be expressed as an abstract transport instance (e.g., an identifier of a VPN+ instance [Enhanced
-VPN ], a virtual network identifier [ACTN-VN-YANG] [RFC8453], or a network slice name [Network-Framework -Slices ]) or as an ordered list of the actual protocols to be enabled in the network.¶-Framework The module supports a rich set of protocol identifiers that can be used, for example, to refer to an underlay transport. Examples of supported protocols are as follows:¶
- 'vpn
-route -targets' : - A YANG grouping that defines Route Target (RT) import/export rules used in a BGP-enabled VPN. This grouping can be used for both L3VPNs [RFC4364] and L2VPNs [RFC4664]. Note that this is modeled as a list to ease the reuse of this grouping in modules where an RT identifier is needed (e.g., associating an operator with RTs).¶
- 'route
-distinguisher' : -
A YANG grouping that defines Route Distinguishers (RDs).¶
As depicted in Figure 2, the module supports the following RD assignment modes: direct assignment, full automatic assignment, automatic assignment from a given pool, and no assignment.¶
Also, the module accommodates deployments where only the Assigned Number subfield of RDs (Section 4.2 of [RFC4364]) is assigned from a pool while the Administrator subfield is set to, for example, the Router ID that is assigned to a VPN node. The module supports three modes for managing the Assigned Number subfield: explicit assignment, automatic assignment from a given pool, and full automatic assignment.¶
- 'vpn
-components -group' : - A YANG grouping that is used to group VPN nodes, VPN network accesses, or sites. For example, diversity or redundancy constraints can be applied on a per-group basis.¶
- 'placement
-constraints' : - A YANG grouping that is used to define the placement constraints of a VPN node, VPN network access, or site.¶
- 'ports':
-
A YANG grouping that defines ranges of source and destination port numbers and operators. The subtree of this grouping is depicted in Figure 3.¶
- 'qos
-classification -policy' : -
A YANG grouping that defines a set of QoS classification policies based on various Layer 3/4 and application match criteria. The subtree of this grouping is depicted in Figure 4.¶
The QoS match criteria reuse groupings that are defined in the packet fields module "ietf
-packet -fields" (Section 4.2 of [RFC8519]).¶ Any Layer 4 protocol can be indicated in the 'protocol' data node under 'l3', but only TCP- and UDP-specific match criteria are elaborated on in this version, as these protocols are widely used in the context of VPN services. Future revisions can be considered to add other Layer
-4 -specific parameters (e.g., the Stream Control Transmission Protocol [RFC4960]), if needed.¶ Some transport protocols use existing protocols (e.g., TCP or UDP) as the substrate. The match criteria for such protocols may rely upon the 'protocol' under 'l3', TCP/UDP match criteria as shown in Figure 4, part of the TCP/UDP payload, or a combination thereof. This version of the module does not support such advanced match criteria. Future revisions of the module may consider adding match criteria based on the transport protocol payload (e.g., by means of a bitmask match).¶
4. Layer 2/3 VPN Common Module
This module uses types defined in [RFC6991], [RFC8294], and [RFC8519]. It also uses the extension defined in [RFC8341].¶
5. Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040].
The lowest NETCONF layer is the secure transport layer, and the
mandatory
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
The "ietf
Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For example,
reusing some of these groupings will expose privacy-related information
(e.g., 'customer
6. IANA Considerations
IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -vpn -common¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
IANA has registered the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry.¶
7. References
7.1. Normative References
- [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC4364]
-
Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10
.17487 , , <https:///RFC4364 www >..rfc -editor .org /info /rfc4364 - [RFC6020]
-
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10
.17487 , , <https:///RFC6020 www >..rfc -editor .org /info /rfc6020 - [RFC6241]
-
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10
.17487 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC6242]
-
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10
.17487 , , <https:///RFC6242 www >..rfc -editor .org /info /rfc6242 - [RFC6991]
-
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10
.17487 , , <https:///RFC6991 www >..rfc -editor .org /info /rfc6991 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 www >..rfc -editor .org /info /rfc7950 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 www >..rfc -editor .org /info /rfc8040 - [RFC8294]
-
Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10
.17487 , , <https:///RFC8294 www >..rfc -editor .org /info /rfc8294 - [RFC8341]
-
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10
.17487 , , <https:///RFC8341 www >..rfc -editor .org /info /rfc8341 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446 - [RFC8519]
-
Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10
.17487 , , <https:///RFC8519 www >..rfc -editor .org /info /rfc8519
7.2. Informative References
- [ACTN-VN-YANG]
-
Lee, Y., Ed., Dhody, D., Ed., Ceccarelli, D., Bryskin, I., and B. Yoon, "A YANG Data Model for VN Operation", Work in Progress, Internet-Draft, draft
-ietf , , <https://-teas -actn -vn -yang -13 datatracker >..ietf .org /doc /html /draft -ietf -teas -actn -vn -yang -13 - [Enhanced
-VPN -Framework] -
Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Network (VPN+) Services", Work in Progress, Internet-Draft, draft
-ietf , , <https://-teas -enhanced -vpn -09 datatracker >..ietf .org /doc /html /draft -ietf -teas -enhanced -vpn -09 - [IEEE802.1ad]
-
IEEE, "IEEE Standard for Local and Metropolitan Area Networks
---Virtual Bridged Local Area Networks , <https://---Amendment 4: Provider Bridges" standards >..ieee .org /standard /802 _1ad -2005 .html - [IEEE802.1AX]
-
IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation", <https://
standards >..ieee .org /standard /802 _1AX -2020 .html - [IEEE802.1Q]
-
IEEE, "IEEE Standard for Local and Metropolitan Area Networks
--Bridges and Bridged Networks" , <https://standards >..ieee .org /standard /802 _1Q -2018 .html - [ISO10589]
-
ISO, "Information technology - Telecommunicati
ons and information exchange between systems - Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless , International Standard 10589:2002, Second Edition, , <https://-mode network service (ISO 8473)" www >..iso .org /standard /30932 .html - [L2NM-YANG]
-
Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., and L. Munoz, "A Layer 2 VPN Network YANG Model", Work in Progress, Internet-Draft, draft
-ietf , , <https://-opsawg -l2nm -12 datatracker >..ietf .org /doc /html /draft -ietf -opsawg -l2nm -12 - [Network
-Slices -Framework] -
Farrel, A., Ed., Gray, E., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, LM., and J. Tantsura, "Framework for IETF Network Slices", Work in Progress, Internet-Draft, draft
-ietf , , <https://-teas -ietf -network -slices -05 datatracker >..ietf .org /doc /html /draft -ietf -teas -ietf -network -slices -05 - [RFC0791]
-
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10
.17487 , , <https:///RFC0791 www >..rfc -editor .org /info /rfc791 - [RFC1112]
-
Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10
.17487 , , <https:///RFC1112 www >..rfc -editor .org /info /rfc1112 - [RFC1701]
-
Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, DOI 10
.17487 , , <https:///RFC1701 www >..rfc -editor .org /info /rfc1701 - [RFC1702]
-
Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, DOI 10
.17487 , , <https:///RFC1702 www >..rfc -editor .org /info /rfc1702 - [RFC2003]
-
Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10
.17487 , , <https:///RFC2003 www >..rfc -editor .org /info /rfc2003 - [RFC2080]
-
Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, DOI 10
.17487 , , <https:///RFC2080 www >..rfc -editor .org /info /rfc2080 - [RFC2236]
-
Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, DOI 10
.17487 , , <https:///RFC2236 www >..rfc -editor .org /info /rfc2236 - [RFC2453]
-
Malkin, G., "RIP Version 2", STD 56, RFC 2453, DOI 10
.17487 , , <https:///RFC2453 www >..rfc -editor .org /info /rfc2453 - [RFC2473]
-
Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10
.17487 , , <https:///RFC2473 www >..rfc -editor .org /info /rfc2473 - [RFC2710]
-
Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10
.17487 , , <https:///RFC2710 www >..rfc -editor .org /info /rfc2710 - [RFC3209]
-
Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10
.17487 , , <https:///RFC3209 www >..rfc -editor .org /info /rfc3209 - [RFC3376]
-
Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10
.17487 , , <https:///RFC3376 www >..rfc -editor .org /info /rfc3376 - [RFC3810]
-
Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10
.17487 , , <https:///RFC3810 www >..rfc -editor .org /info /rfc3810 - [RFC3931]
-
Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, DOI 10
.17487 , , <https:///RFC3931 www >..rfc -editor .org /info /rfc3931 - [RFC4026]
-
Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10
.17487 , , <https:///RFC4026 www >..rfc -editor .org /info /rfc4026 - [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 , , <https:///RFC4176 www >..rfc -editor .org /info /rfc4176 - [RFC4271]
-
Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10
.17487 , , <https:///RFC4271 www >..rfc -editor .org /info /rfc4271 - [RFC4577]
-
Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider
/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)" , RFC 4577, DOI 10.17487 , , <https:///RFC4577 www >..rfc -editor .org /info /rfc4577 - [RFC4664]
-
Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10
.17487 , , <https:///RFC4664 www >..rfc -editor .org /info /rfc4664 - [RFC4761]
-
Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10
.17487 , , <https:///RFC4761 www >..rfc -editor .org /info /rfc4761 - [RFC4762]
-
Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10
.17487 , , <https:///RFC4762 www >..rfc -editor .org /info /rfc4762 - [RFC4960]
-
Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10
.17487 , , <https:///RFC4960 www >..rfc -editor .org /info /rfc4960 - [RFC5036]
-
Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10
.17487 , , <https:///RFC5036 www >..rfc -editor .org /info /rfc5036 - [RFC5798]
-
Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, DOI 10
.17487 , , <https:///RFC5798 www >..rfc -editor .org /info /rfc5798 - [RFC5880]
-
Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10
.17487 , , <https:///RFC5880 www >..rfc -editor .org /info /rfc5880 - [RFC6513]
-
Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10
.17487 , , <https:///RFC6513 www >..rfc -editor .org /info /rfc6513 - [RFC6565]
-
Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol", RFC 6565, DOI 10
.17487 , , <https:///RFC6565 www >..rfc -editor .org /info /rfc6565 - [RFC6624]
-
Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10
.17487 , , <https:///RFC6624 www >..rfc -editor .org /info /rfc6624 - [RFC7348]
-
Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10
.17487 , , <https:///RFC7348 www >..rfc -editor .org /info /rfc7348 - [RFC7432]
-
Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10
.17487 , , <https:///RFC7432 www >..rfc -editor .org /info /rfc7432 - [RFC7510]
-
Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10
.17487 , , <https:///RFC7510 www >..rfc -editor .org /info /rfc7510 - [RFC7623]
-
Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10
.17487 , , <https:///RFC7623 www >..rfc -editor .org /info /rfc7623 - [RFC7676]
-
Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10
.17487 , , <https:///RFC7676 www >..rfc -editor .org /info /rfc7676 - [RFC7761]
-
Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10
.17487 , , <https:///RFC7761 www >..rfc -editor .org /info /rfc7761 - [RFC7880]
-
Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10
.17487 , , <https:///RFC7880 www >..rfc -editor .org /info /rfc7880 - [RFC8200]
-
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10
.17487 , , <https:///RFC8200 www >..rfc -editor .org /info /rfc8200 - [RFC8214]
-
Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10
.17487 , , <https:///RFC8214 www >..rfc -editor .org /info /rfc8214 - [RFC8277]
-
Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10
.17487 , , <https:///RFC8277 www >..rfc -editor .org /info /rfc8277 - [RFC8299]
-
Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10
.17487 , , <https:///RFC8299 www >..rfc -editor .org /info /rfc8299 - [RFC8340]
-
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10
.17487 , , <https:///RFC8340 www >..rfc -editor .org /info /rfc8340 - [RFC8365]
-
Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10
.17487 , , <https:///RFC8365 www >..rfc -editor .org /info /rfc8365 - [RFC8453]
-
Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10
.17487 , , <https:///RFC8453 www >..rfc -editor .org /info /rfc8453 - [RFC8466]
-
Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10
.17487 , , <https:///RFC8466 www >..rfc -editor .org /info /rfc8466 - [RFC8512]
-
Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, "A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)", RFC 8512, DOI 10
.17487 , , <https:///RFC8512 www >..rfc -editor .org /info /rfc8512 - [RFC8660]
-
Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10
.17487 , , <https:///RFC8660 www >..rfc -editor .org /info /rfc8660 - [RFC8663]
-
Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, DOI 10
.17487 , , <https:///RFC8663 www >..rfc -editor .org /info /rfc8663 - [RFC8754]
-
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10
.17487 , , <https:///RFC8754 www >..rfc -editor .org /info /rfc8754 - [RFC8926]
-
Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., "Geneve: Generic Network Virtualization Encapsulation", RFC 8926, DOI 10
.17487 , , <https:///RFC8926 www >..rfc -editor .org /info /rfc8926 - [RFC9182]
-
Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model for Layer 3 VPNs", RFC 9182, DOI 10
.17487 , , <https:///RFC9182 www >..rfc -editor .org /info /rfc9182
Appendix A. Example of Common Data Nodes in Early L2NM/L3NM Designs
In order to avoid duplication of data nodes and to ease passing data among layers (i.e., from the service layer to the network layer and vice versa), early versions of the L3NM reused many of the data nodes that are defined in the L3SM. Nevertheless, that approach was abandoned because that design was interpreted as if the deployment of the L3NM depends on the L3SM, while this is not required. For example, a service provider may decide to use the L3NM to build its L3VPN services without exposing the L3SM to customers.¶
Likewise, early versions of the L2NM reused many of the data nodes that are defined in both the L2SM and the L3NM. An example of L3NM groupings reused in the L2NM is shown in Figure 5. Such reuse of data nodes was interpreted as if the deployment of the L2NM requires support for the L3NM, which is not required.¶
Acknowledgements
During the discussions of this work, helpful comments and reviews were received from (listed alphabetically) Alejandro Aguado, Raul Arco, Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Tom Petch, Erez Segev, and Paul Sherratt. Many thanks to them.¶
This work is partially supported by the European Commission under Horizon 2020 Secured autonomic traffic management for a Tera of SDN flows (Teraflow) project (grant agreement number 101015857).¶
Many thanks to Radek Krejci for the YANG Doctors review, Wesley Eddy for the tsvart review, Ron Bonica and Victoria Pritchard for the RtgDir review, Joel Halpern for the genart review, Tim Wicinski for the opsdir review, and Suresh Krishnan for the intdir review.¶
Special thanks to Robert Wilton for the AD review.¶
Thanks to Roman Danyliw, Lars Eggert, Warren Kumari, Erik Kline, Zaheduzzaman Sarker, Benjamin Kaduk, and Éric Vyncke for the IESG review.¶