]> Telefonica

oscar.gonzalezdedios@telefonica.com

Nokia

samier.barguil_giraldo@nokia.com

Network Models L3NM L2NM 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 The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Service and Network YANG data models such as the Layer 3 Network Model (L3NM) and the Layer 2 Network Model (L2NM) 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. documents the automation framework. documents Intent-based networking from IRTF perspective, with specific problems which are addressable today after the first deployments have been done.

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 when, and only when, they appear in all capitals, as shown here.

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:

• 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.
• documents a data model that describes the deployment of various types of L2VPN, including VPWS and BGP based L2VPN, such as EVPNs.

Observations and new requirements

Enhancements to LxSM and LxNM Implementations of LxNM models in controllers required new functionalities which were not covered in and to deploy the missing functions in the Operator services. This section compiles the functions that were reported by those implementations.

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:
    • BGP Peer group creation
    • BGP Redistribution rules
  • Missing pointer to ACL (also present in Github issue #3).
    • ACL pointer to attach forwarding filter
• SRv6 support for L3VPN (Github issue #15): SRv6-based BGP services including L3VPN, whose procedures are defined in
• 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 ) using the L3NM framework (Github issue #25).

L2NM Enhancements

• EVPN Remote and Local eth-tag (Github issue #6)
• Explicitly assign a RD at node level (Github issue #7)
  • In the model, a RD must be always assigned via profile at service level. It is useful to be able to set a explicit RD directly at node level overriding the value of the profile. This way, a common profile can be used for all the services for use cases where only RD changes per node.
• Add support for Flexible Cross-Connect (FXC) Service () (Github issue #8)
• Add explanatory text for EVPN multihoming using LAG (Github issue #9)
• support for vlan-lists/vlan-ranges (Github issue #10)
  • When defining a Layer 2 service, sometimes multiple VLANs are mapped into a given service. It would be good to support this in the L2NM encapsulation stanza. Examples are as follows:
    • Typically used in single-tagged scenarios: vlan-id-list [ 200 210-219 222 234 240-249 ];
    • Dual-tagged scenario, with s-vlan=430 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)
• Performance monitoring
  • ITU-T Y.1731 performance monitoring in Ethernet based networks . L2NM itself doesn't natively include OAM specifics.
• Add EVI identifier to differentiate it from VPN-ID. Each EVI maps to a specific EVPN service (e.g., a Layer 2 VPN bridging a particular VLAN across the EVPN fabric) (Github issue #24).

New Functionalities Required to Fully Support Connectivity Services The realization of advanced connectivity services requires, in addition to the configurations expressed in LxNM models: * Definition of Access Control lists and prefix Sets: + Connectivity services often include mechanisms to filter forwarding packets. The LxNM models allow to include a 'forwarding-profile-identifier'. A forwarding profile refers to the policies that apply to the forwarding of packets conveyed within a VPN. Such policies may consist, for example, of applying Access Control Lists (ACLs). However, currently there is not an ACL network service model (even though a device level ACL model exists) that allows to manipulate such ACLs and sets when creating the service. + ACLs and Prefix sets can be reused among services. Thus, they need to be handled at a network level, regardless of the actual service using them. * Definition of routing policies, including community sets, as path sets, etc: + Advanced connectivity services require the creation of complex policies. The LxNM models allows to indicate which policy (or policies) should be used. However, LxNM does not include the definition of policies. There are a set a device models which could be used as a base for the network model. * Pre and post checks before and after deploying a service in the network. * Preparation of the interface. Prior to the application of the entire configuration profile.

Status of the Intended Network Service The Network Service Yang models represent an intent of the realization of service. A controller, after an instance of the network service yang intent has been created, will derive the necessary device level configurations and apply them to the necessary devices. However, the implementations reported a set of open issues which are related to the status. Those issues are not solved today and are left to implementation choices and solutions.

• Is the Service running on the Network? (Github issue #5)
  • How can the northbound system be assured with 100% certainty that a configuration has been successfully installed on the network device?
  • What mechanisms or feedback loops exist to confirm successful configuration deployment beyond simple acknowledgment?
  • How can the system can handle transient errors or partial configuration applications from the model perspective?
  • 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)
  • Understanding the interrelationships between the operational status of VPN services, VPN nodes, and VPN network access is 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, IETF 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. Moreover, real-time monitoring and correlation of status information can provide insights into the health and performance of VPN services.

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)

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open-source software projects, vendors, and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG modules. The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432). This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] This document describes a new 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. This new service is referred to as the EVPN-VPWS Flexible Cross-Connect (FXC) service. This document specifies a solution based on extensions to EVPN-VPWS (RFC 8214), which in turn is based on extensions to EVPN (RFC 7432). Therefore, a thorough understanding of RFCs 7432 and 8214 are prerequisites for this document.

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.