Network Working Group O. G. D. Dios Internet-Draft Telefonica Intended status: Informational S. Barguil Expires: 7 January 2027 Nokia 6 July 2026 An Update of Service and Network YANG Data Models draft-bg-onions-update-network-service-models-01 Abstract Service & Network data models have been implemented in recent years to facilitate the deployment of connectivity services such as Layer 2 and Layer 3 VPN services in provider networks. This document reports the findings from the implementations, including missing functionalities, configuration blocks aligment against recent network models published, operational issues/limitatations and enhancements. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://oscargdd.github.io/lxnm-bis/draft-bg-onions-update-network- service-models.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-bg-onions-update- network-service-models/. Discussion of this document takes place on the ONSEN Working Group mailing list (mailto:onions@ietf.orge.com). Source for this draft and an issue tracker can be found at https://github.com/oscargdd/lxnm-bis. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Conventions and Definitions 3. Service and Network YANG Data Models in the IETF 4. Observations and new requirements 4.1. Enhancements to LxSM and LxNM 4.1.1. L3NM Enhancements 4.1.2. ## L2NM Enhancements 4.2. New Functionalities Required to Fully Support Connectivity Services 4.3. Status of the Intended Network Service 4.4. Summary 5. Security Considerations 6. IANA Considerations 7. References 7.1. Normative References 7.2. Informative References Acknowledgments Authors' Addresses 1. Introduction Service and Network YANG data models [RFC8199][RFC8309] such as the Layer 3 Network Model (L3NM) [RFC9182] and the Layer 2 Network Model (L2NM) [RFC9291] have been implemented to automate the deployment of VPN services by providers. This document reports the findings from the implementations, deriving the functionalities required to update the Service and Network YANG data models. [RFC8969] documents the automation framework. [RFC9315] documents Intent-based networking from IRTF perspective, with specific problems which are addressable today after the first deployments have been done. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Service and Network YANG Data Models in the IETF Several IETF Working Groups have developed YANG modules in order to foster the provisioning and, more generally, the deployment of services. These modules focus on how the network operator intents to manage a network through protocols and devices to deliver a service. The intended configuration at the device level is derived from network YANG data models. The customer service YANG data models abstract the service for upper layers. The intended network service configuration is derived from the the service model. A set of these models is listed here: * [RFC9182] As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, L3NM is a Network Model (L3NM) that can be used for the provisioning of BGP based Layer 3 Virtual Private Network (L3VPN) services within a service provider network. * [RFC9291] documents a data model that describes the deployment of various types of L2VPN, including VPWS and BGP based L2VPN, such as EVPNs. 4. Observations and new requirements 4.1. Enhancements to LxSM and LxNM Implementations of LxNM models in controllers required new functionalities which were not covered in [RFC9182] and [RFC9291] to deploy the missing functions in the Operator services. This section compiles the functions that were reported by those implementations. 4.1.1. L3NM Enhancements * BFD parametrization of static routes (Github issue #1): - The L3NM Yang data model allows to manage static routes in a VPN. That is, for a particular VPN service, new Pv4 and IPv6 static routes can be added, modified or deleted. The data model allows to specify whether BFD is desired in the static route. Whenever a controller derives the device configuration of the static route it will need to decide a particular BFD configuration, typically from a pre-defined template. Operators required, for different services, to customize the main BFD parameters to allow, for example, faster detection for critical services. The new requirement is the ability to specify BFD intended configuration in the IPv4 and IPv6 static routes, including a required-min-rx-interval and multiplier. * Management of VLAN 0 in tagged interfaces (Github issue #2): LxNM Yang models have a range defined for cvlan between 1 and 4094. VLAN 0 should also be supported and is used in deployments. * Missing BGP intended configuration blocks (in relation to Attachment Circuits) (Github issue #3). - There are a set of BGP configuration blocks required to manage BGP based services which are present now in the AC-Model but not in the L3NM: o BGP Peer group creation o BGP Redistribution rules - Missing pointer to ACL (also present in Github issue #3). o ACL pointer to attach forwarding filter * SRv6 support for L3VPN (Github issue #15): SRv6-based BGP services including L3VPN, whose procedures are defined in [RFC9252] * Improving Multicast Support: - For L3VPN with multicast, one implementation has reported that Cisco MVPN augmentation were added to include various profiles ( ipmsi and spmsi ) . There is no YANG module from IETF as of today that supports full MVPN/SPMSI/IPMSI under L3NM directly. Standardized profiles are required to be added. * Extend guidance of how the network models can be used to/and operationalize Inter-AS VPN options (A, B, and C as defined in [RFC4364]) using the L3NM framework (Github issue #25). 4.1.2. ## L2NM Enhancements * *EVPN remote and local eth-tag (GitHub issue #6)* - The current L2NM does not provide a way to express distinct local and remote eth-tag values per AC under the BGP-EVPN configuration. * *Explicit assignment of an RD at node level (GitHub issue #7)* - In the current model, a Route Distinguisher (RD) must always be assigned via a profile at the service level. It is useful to be able to set an explicit RD directly at the node level, overriding the value of the profile. This allows a common profile to be used across all services for use cases where only the RD changes per node. * *Support for Flexible Cross-Connect (FXC) services ([RFC9744]) (GitHub issue #8)* - The L2NM should be enhanced with the support of EVPN Virtual Private Wire Service (VPWS) service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments (ESs) and physical interfaces into a single EVPN-VPWS service tunnel and still providing Single-Active and All-Active multi-homing. * *Explanatory text for EVPN multihoming using LAG (GitHub issue #9)* - The L2NM allows a lag-interface-id to be configured per VPN network access, but does not currently document how this identifier is used to associate the LAG members across PEs that belong to the same multihoming group. * *Support for VLAN lists and VLAN ranges (GitHub issue #10)* - When defining a Layer 2 service, multiple VLANs are sometimes mapped into a single service. The L2NM encapsulation stanza should support this. Examples include: o Single-tagged scenarios: vlan-id-list [ 200 210-219 222 234 240-249 ] o Dual-tagged scenarios with an S-VLAN and a list of C-VLANs: vlan-tags outer 430 inner-list [ 200 210-219 222 234 240-249 ] * *SRv6 support for L2VPN (GitHub issue #15)* - Segment Routing over IPv6 (SRv6) extends BGP-based L2VPN services with IPv6-native data plane semantics, as defined in[RFC9252]. Operators deploying SRv6-based L2VPN services require the L2NM to express SRv6-specific configuration that is not currently supported by [RFC9291]. Two specific gaps have been identified: o SRv6 locator preferences. When multiple SRv6 locators are available on a PE, operators need a way to indicate which locator (or ordered list of locators) should be used for a given L2VPN service. This allows traffic from different services to be steered onto distinct locators -- for example, to differentiate by topology, slice, or administrative domain. o Address-family-based SRv6 selection. SRv6 behavior may need to be configured independently per address family(e.g., for services that carry both IPv4 and IPv6 payloads). The model should allow the SRv6 configuration to be expressed per address family rather than as a single service-wide setting. * *Performance monitoring* - ITU-T Y.1731 defines performance monitoring for Ethernet-based networks. L2NM [RFC9291] does not natively include OAM specifics, and standardized support is required. * *EVI identifier to differentiate from VPN-ID (GitHub issue #24)* - Each EVI maps to a specific EVPN service (e.g., a Layer 2 VPN bridging a particular VLAN across the EVPN fabric). An explicit EVI identifier should be added to the model to distinguish it from the VPN-ID. 4.2. New Functionalities Required to Fully Support Connectivity Services The realization of advanced connectivity services requires, in addition to the configurations expressed in the LxNM models, the following capabilities: * *Definition of Access Control Lists and Prefix Sets:* - Connectivity services often include mechanisms to filter forwarded packets. The LxNM models allow a service to reference a forwarding-profile-identifier, which refers to the policies that apply to the forwarding of packets conveyed within a VPN. Such policies may consist, for example, of applying Access Control Lists (ACLs). However, there is currently no ACL network service model -- although a device- level ACL model exists -- that allows ACLs and prefix sets to be manipulated when creating the service. - ACLs and prefix sets can be reused across services. Therefore, they need to be managed at the network level, independently of the specific service using them. * *Definition of routing policies, including community sets and AS- path sets:* - Advanced connectivity services require the definition of complex routing policies. The LxNM models allow the operator to indicate which policy (or policies) should be applied, but do not include the definition of those policies. A set of device-level models exists that could be used as a basis for a corresponding network-level model. * *Pre- and post-deployment checks:* - Mechanisms to perform validation checks before and after deploying a service in the network. For example, e.g., reachability, capacity, or configuration consistency. * *Interface preparation:* - Mechanisms to prepare an interface prior to the application of the full service configuration profile. For exampleÑ enabling the interface, setting MTU, or default VLAN configuration. 4.3. Status of the Intended Network Service Status of the Intended Network Service The Network Service YANG models represent the _intent_ for the realization of a service. After an instance of a network service YANG intent has been created, a controller derives the necessary device-level configurations and applies them to the relevant devices. However, implementations have reported a set of open issues related to the status of the intended service. These issues are not addressed today and are left to implementation choices. * *Is the service running on the network? (GitHub issue #5)* - How can the northbound system be assured, with full certainty, that a configuration has been successfully installed on the network device? - What mechanisms or feedback loops exist to confirm successful configuration deployment beyond a simple acknowledgement? - How can the model represent and handle transient errors or partial configuration applications? - Are there specific operational attributes that can be used to reflect the real-time status of the configuration? - Does the network element provide any operational state parameters or notifications that indicate whether the configuration is active, pending, or has failed? - If a configuration is manually removed via CLI at the network device, is there a mechanism to reflect this change northbound? * *Operational status clarification (GitHub issue #4)* - The interrelationships between the operational status of VPN services, VPN nodes, and VPN network access points represent another significant operational gap. - The status of a VPN service may depend on the status of the underlying VPN nodes and the network access provided to the VPN. - To address this gap, the L3NM should establish clear dependencies and correlations between the various operational statuses. - This could involve defining specific criteria for determining the overall status of a VPN service based on the status of its constituent VPN nodes and network access components. - In addition, real-time monitoring and correlation of status information can provide insights into the health and performance of VPN services. 4.4. Summary * L3NM and L2NM need to be updated to cover new technologies (such as SRv6), incomplete support (such as multicast) and enhancements. * New network YANG data models (such as ACLs and routing policies) 5. Security Considerations TODO Security 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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/RFC9182, February 2022, . [RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, S., and L. Munoz, "A YANG Network Data Model for Layer 2 VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022, . 7.2. Informative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, . [RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, . [RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022, . [RFC9744] Sajassi, A., Ed., Brissette, P., Uttaro, J., Drake, J., Boutros, S., and J. Rabadan, "EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC) Service", RFC 9744, DOI 10.17487/RFC9744, March 2025, . Acknowledgments This documents is based on the issues compiled in Github lxnm repository. The authors would like to acknowledge the issues raised by Julian Lucek, Xiao Min, Daniele Ceccarelli and Sujay Murthy. Authors' Addresses Oscar Gonzalez de Dios Telefonica Email: oscar.gonzalezdedios@telefonica.com Samier Barguil Nokia Email: samier.barguil_giraldo@nokia.com