]> Huawei Technologies

italo.busi@huawei.com

Futurewei Inc.

aihuaguo.ietf@gmail.com

Alef Edge

xufeng.liu.ietf@gmail.com

Cisco Systems, Inc.

tsaad.net@gmail.com

Cisco Systems, Inc.

rgandhi@cisco.com

TEAS Working Group This document defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. It is based on and augments existing YANG models that describe network and traffic engineering packet network topologies. This document also defines a collection of common YANG data types and groupings specific to MPLS-TE. These common types and groupings are intended to be imported by modules that model MPLS-TE technology-specific configuration and state capabilities. The YANG models defined in this document can also be used for MPLS Transport Profile (MPLS-TP) network topologies.

Introduction This document defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. It is based on and augments existing YANG models that describe network and traffic engineering packet network topologies. This document also defines a collection of common YANG data types and groupings specific to MPLS-TE. These common types and groupings are intended to be imported by modules that model MPLS-TE technology-specific configuration and state capabilities, such as the MPLS-TE topology model, defined in this document, and the MPLS-TE tunnel model, defined in . MPLS Transport Profile (MPLS-TP) is a profile of the MPLS protocol that is used in packet switched transport networks and operated in a similar manner to other existing transport technologies (e.g., OTN), as described in . The YANG models defined in this document can also be used for MPLS-TP network topologies. The YANG models defined in this document conform to the Network Management Datastore Architecture defined in .

Tree Diagram A simplified graphical representation of the data model is used in of this this document. The meaning of the symbols in these diagrams is defined in .

Prefixes in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in . Prefix YANG Module Reference rt-types ietf-routing-types mpls-te-types ietf-mpls-te-types RFC XXXX nw ietf-network nt ietf-network-topology tet ietf-te-topology tet-pkt ietf-te-topology-packet [RFCYYYY] tet-mpls ietf-te-mpls-topology RFC XXXX RFC Editor Note: Please replace XXXX with the RFC number assigned to the RFC once this draft becomes an RFC. Please replace YYYY with the RFC numbers assigned to . Please remove this note.

MPLS-TE Types Overview The module ietf-mpls-te-types contains the following YANG types and groupings which can be used by other MPLS-TE YANG models: load-balancing-type:

• This identity defines the types of load-balancing algorithms used on a bundled MPLS-TE link.

te-mpls-label-hop:

• This grouping is used for augmentation of the TE label for MPLS-TE paths.

MPLS-TE Topology Model Overview The MPLS-TE technology-specific topology model augments the ietf-te- topology-packet YANG module, defined in , which in turn augments the generic ietf-te-topology YANG module, defined in , as shown in .

Given the guidance for augmentation in , the following technology-specific augmentations need are provided: A network-type to indicate that the TE topology is an MPLS-TE topology, as follow:

TE Label augmentations as described in . Note: TE bandwidth augmentations for paths, LSPs, and links are provided by the ietf-te-topology-packet module, defined in .

TE Label Augmentations In MPLS-TE, label allocation is done by the network element. Information about the availability of label values does not need to be provided to the controller. Moreover, MPLS-TE tunnels are currently mainly only established within a single domain. Therefore this document does not define any MPLS-TE technology-specific augmentations, of the TE Topology model specific to the TE label because no TE label-related attributes are instantiated for MPLS-TE Topologies. Furthermore, because the primary use cases are for single domain MPLS-TE tunnels, this document does not define objects that facilitate the setup of multi-domain MPLS-TE tunnels. It is an item for future study to understand how a management system would coordinate YANG configuration of a tunnel that crosses a domain boundary, and it is expected that that would be defined in a separate document.

MPLS-TP Topology Multiprotocol Label Switching - Transport Profile (MPLS-TP) is a profile of the MPLS protocol that is used in packet switched transport networks and operated in a similar manner to other existing transport technologies (e.g., OTN), as described in . Therefore, the YANG models defined in this document can also be applied to MPLS-TP network topologies. However, as described in , MPLS-TP networks support bidirectional LSPs and require no equal cost multipath (ECMP) and no previous hop popping (PHP). When reporting the topology for an MPLS-TP network, additional information is required to indicate whether the network components (links and nodes) support these MPLS-TP characteristics. It is worth noting that is already capable of modeling TE topologies supporting either unidirectional or bidirectional LSPs: all bidirectional TE links can support bidirectional LSPs, and all links can support unidirectional LSPs. Further, it is always possible to associate two unidirectional LSPs to compose a bidirecitonal service as long as they belong to the same tunnel. When setting up bidirectional LSPs (e.g., MPLS-TP LSPs) only bidirectional TE Links are selected by path computation. In order to allow reporting that ECMP is not affecting forwarding the packets of a given LSP, the model defined in this documents provides the load-balancing-type attribute which reports whether a link aggregation group (LAG) or TE Bundled Link performs load-balancing, and if so, whether it is on a per-flow or per-top-label basis:

When setting up LSPs which require the non-use of ECMP (e.g., MPLS-TP LSPs) only links that are not part of a LAG or TE Bundle, or that perform per-top-label load balancing are selected by path computation. It is assumed that almost all the MPLS-TE nodes are capable of supporting Ultimate Hop Popping (UHP) (i.e., they do not require the previous node on the path to perform PHP). However, if some interfaces are not able to support UHP, they can report it in the MPLS-TE topology:

When setting up LSPs which require the non-use of PHP (e.g., MPLS-TP LSPs) only the destination node interfaces (link termination points - LTPs) that are capable of supporting UHP are selected by path computation.

YANG model for common MPLS-TE Types

WG List: Editor: Italo Busi Editor: Aihua Guo Editor: Xufeng Liu Editor: Tarek Saad Editor: Rakesh Gandhi "; description "This module defines a collection of common YANG data type and grouping definitions specific to MPLS-TE. Copyright (c) 2023 IETF Trust and the persons identified as authors of the code. All rights reserved. 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 Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 2023-10-13 { description "Initial Version"; reference "RFC XXXX: A YANG Data Model for MPLS-TE Topology"; } // RFC Editor: replace XXXX with the actual RFC number assigned // to the RFC once this draft // becomes an RFC, update date information and remove this note. /* * Typedefs */ typedef load-balancing-type { type enumeration { enum per-flow { description "The load-balancing algorithm ensures that packets characterized as the same flow (e.g. based on IP 5-tuple) that egress on a LAG or a bundled TE link are forwarded on the same component link. Packets for different flows within the same LSP can be forwarded on different component links."; } enum per-top-label { description "The load-balancing algorithm ensures incoming MPLS packets with the same top MPLS label and that egress on on a LAG or bundled TE link are forwarded on the same component link. Packets for different flows within the same LSP are forwarded on the same component link."; } } description "The type of load balancing used on bundled links."; } // typedef load-balancing-type /* * Groupings */ grouping te-mpls-label-hop { description "MPLS-TE Label Hop."; leaf mpls-label { type rt-types:mpls-label; description "MPLS Label."; } } // grouping te-mpls-label-hop } ]]>

YANG Model for MPLS-TE Topology

YANG Tree shows the tree diagram of the YANG model defined in module ietf-te-mpls-topology.yang.

YANG Code

WG List: Editor: Italo Busi Editor: Aihua Guo Editor: Xufeng Liu Editor: Tarek Saad Editor: Rakesh Gandhi "; description "This module defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. This module defines MPLS-TE technology-specific augmentations to the generic Packet TE topology module (ietf-te-topology-packet). Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. 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 Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 2023-10-13 { description "Initial Version"; reference "RFC XXXX: A YANG Data Model for MPLS-TE Topology"; } // RFC Editor: replace XXXX with the actual RFC number assigned // to the RFC once this draft // becomes an RFC, update date information and remove this note. /* * Augmentations */ augment "/nw:networks/nw:network/nw:network-types/" + "tet:te-topology/tet-pkt:packet" { description "Augment network types to include MPLS-TE Topology Type"; container mpls-topology { presence "Indicates an MPLS-TE Topology Type."; description "Its presence indicates an MPLS-TE Topology"; } } augment "/nw:networks/nw:network/nt:link/tet:te" { when "../../nw:network-types/tet:te-topology/" + "tet-pkt:packet/tet-mpls:mpls-topology" { description "Augment MPLS-TE Topology."; } description "Augment TE Link."; leaf load-balancing-type { type mpls-te-types:load-balancing-type; default 'per-flow'; description "Indicates the type of load-balancing (per-flow or per-LSP) performed by the bundled TE Link. This leaf is not present when the TE Link is not bundled."; } // leaf load-balancing-type } augment "/nw:networks/nw:network/nw:node/nt:termination-point/" + "tet:te" { when "../../../nw:network-types/tet:te-topology/" + "tet-pkt:packet/tet-mpls:mpls-topology" { description "Augment MPLS-TE Topology."; } description "Augment LTP."; leaf uhp-incapable { type empty; config false; description "When present, indicates that the LTP is not capable to support Ultimate Hop Popping (UHP)."; } // leaf uhp-incapable } } ]]>

Security Considerations The configuration, state, and action data defined in this document are designed to be accessed via a management protocol with a secure transport layer, such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory- to-implement secure transport is TLS . The NETCONF access control model provides the means to restrict access for particular NETCONF users to a preconfigured subset of all available NETCONF protocol operations and content. The ietf-mpls-te-types model presented in this document defines common types intended to be used as imports by other YANG models. Those other models are responsible for considering the security of the objects they define using those imports. Writers of those other models should consider the vulnerabilities created by exposing information about link characteristics and behaviors (such as how packets may be steered onto parallel links), and should be aware of the risks of enabling configuration of which labels are used on hops within an LSP. The ietf-te-mpls-topology model presented in this document defines technology-specific objects to describe an MPLS-TE topology. It is intended as an aumentation of the te-topology model and so the core security considerations for that model also apply. In addition, this model defines objects that could expose information about the network behavior or which, if modified by an attacker could disrupt the delivery of services in the network. The leaf objects defined in ietf-te-mpls-topology are read-only so the risk is from unauthorized access to the information, or from misrepresenting the information reported from the network elements. The objects are: "tet:te-topology/tet-pkt:packet": Unauthorized read access to this simply indicates that the network topology is MPLS-TE packet-capable: that information is not very valuable to an attacker. Modification of this information might cause a path computation element to incorrectly presume that a network is capable or incapable of supporting MPLS-TE services. "tet-pkt:packet/tet-mpls:mpls-topology/load-balancing-type": Unauthorized read access to this indicates the mechanism used by a nework node to share traffic across members of a LAG or bundled MPLS-TE link. Such knowledge might help an attacker predict which component link is carrying specific traffic making a physical attack slightly easier. Modification of this information might cause a path computation element to incorrectly presume that a link is suitable or unsuitable for use to provide an MPLS-TP service. "tet-pkt:packet/tet-mpls:mpls-topology/uhp-incapable": Unauthorized read access to this will give an attacker knowledge about whether PHP is being applied on the final hop of all LSPs to a particular node on the associated link: that information is of little use to an attacker except it may help them to parse an inflight packet. Modification of this information would cause a path computation element to incorrectly consider the associated link as suitable or unsuitable for inclusion in the path of an MPLS-TP service.

IANA Considerations This document requests IANA to register the following URIs in the "ns" subregistry within the "IETF XML Registry" . Following the format in , the following registrations are requested.

This document requests IANA to register the following YANG modules in the "IANA Module Names" . Following the format in , the following registrations are requested:

RFC Editor: Please replace XXXX with the RFC number assigned to this document.

Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area. This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. Alef Edge Individual Juniper Networks Cisco Systems Inc Ciena Telefonica This document defines a YANG data model for layer 3 traffic engineering topologies. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Cisco Systems Inc Cisco Systems Inc IBM Corporation Juniper Networks Individual This document defines a YANG data model for the configuration and management of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs) and interfaces. The model augments the TE generic YANG model for MPLS packet dataplane technology. This model covers data for configuration, operational state, remote procedural calls, and event notifications. This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

Acknowledgments We thank Loa Andersson for providing useful suggestions for this draft. This document was prepared using kramdown. Previous versions of this document was prepared using 2-Word-v2.0.template.dot.

Contributors Huawei Technologies

zhenghaomian@huawei.com

Juniper Networks

vbeeram@juniper.net

Individual

i_bryskin@yahoo.com

Old Dog Consulting

adrian@olddog.co.uk