]> Huawei

italo.busi@huawei.com

Futurewei Technologies

aihuaguo.ietf@gmail.com

Alef Edge

xufeng.liu.ietf@gmail.com

Cisco Systems Inc.

tsaad.net@gmail.com

Individual

i_bryskin@yahoo.com

TEAS Working Group This document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776.

Introduction YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols such as the Network Configuration Protocol (NETCONF) . The YANG language supports a small set of built-in data types and provides mechanisms to derive other types from the built-in types. This document introduces a collection of common data types derived from the built-in YANG data types. The derived types and groupings are designed to be the common types applicable for modeling Traffic Engineering (TE) features in model(s) defined outside of this document. This document adds few additional common data types, identities, and groupings to both the "ietf-te-types" and the "ietf-te-packet-types" YANG models and obsoletes . For further details, see the revision statements of the YANG modules in Sections X and Y or the summary in Appendix A. CHANGE NOTE: These definitions have been developed in , and and are quite mature: and in particular are in WG Last Call and some definitions have been moved to this document as part of WG LC comments resolution. RFC Editor: remove the CHANGE NOTE above and this note

Requirements Notation 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.

Terminology The terminology for describing YANG data models is found 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 yang ietf-yang-types inet ietf-inet-types rt-types ietf-routing-types te-types ietf-te-types RFCXXXX te-packet-types ietf-te-packet-types RFCXXXX RFC Editor: Please replace XXXX with the RFC number assigned to this document.

Acronyms and Abbreviations GMPLS:

• Generalized Multiprotocol Label Switching

LSP:

• Label Switched Path

LSR:

• Label Switching Router

LER:

• Label Edge Router

MPLS:

• Multiprotocol Label Switching

RSVP:

• Resource Reservation Protocol

TE:

• Traffic Engineering

DS-TE:

• Differentiated Services Traffic Engineering

SRLG:

• Shared Risk Link Group

NBMA:

• Non-Broadcast Multi-Access

APS:

• Automatic Protection Switching

SD:

• Signal Degrade

SF:

• Signal Fail

WTR:

• Wait-to-Restore

PM:

• Performance Metrics

Overview This document defines two YANG modules for common TE types: "ietf-te-types" for TE generic types and "ietf-te-packet-types" for packet-specific types. Other technology-specific TE types are outside the scope of this document.

TE Types Module Contents The "ietf-te-types" module () contains common TE types that are independent and agnostic of any specific technology or control-plane instance. The "ietf-te-types" module contains the following YANG reusable types and groupings: te-bandwidth:

• A YANG grouping that defines the generic TE bandwidth. The modeling structure allows augmentation for each technology. For unspecified technologies, the string-encoded "te-bandwidth" type is used.

te-label:

• A YANG grouping that defines the generic TE label. The modeling structure allows augmentation for each technology. For unspecified technologies, "rt-types:generalized-label" is used.

performance-metrics-attributes:

• A YANG grouping that defines one-way and two-way measured Performance Metrics (PM) and indications of anomalies on link(s) or the path as defined in , , and .

performance-metrics-throttle-container:

• A YANG grouping that defines configurable thresholds for advertisement suppression and measurement intervals.

te-ds-class:

• A type representing the Differentiated Services (DS) Class-Type of traffic as defined in .

te-label-direction:

• An enumerated type for specifying the forward or reverse direction of a label.

te-hop-type:

• An enumerated type for specifying that a hop is loose or strict.

te-global-id:

• A type representing the identifier that uniquely identifies an operator, which can be either a provider or a client. The definition of this type is taken from and . This attribute type is used solely to provide a globally unique context for TE topologies.

te-node-id:

• A type representing the identifier for a node in a TE topology. The identifier is represented as 4 octets in dotted-quad notation. This attribute MAY be mapped to the Router Address TLV described in Section 2.4.1 of , the TE Router ID described in Section 3 of , the Traffic Engineering Router ID TLV described in Section 4.3 of , or the TE Router ID TLV described in Section 3.2.1 of . The reachability of such a TE node MAY be achieved by a mechanism such as that described in Section 6.2 of .

te-topology-id:

• A type representing the identifier for a topology. It is optional to have one or more prefixes at the beginning, separated by colons. The prefixes can be "network-types" as defined in the "ietf-network" module in , to help the user better understand the topology before further inquiry is made.

te-tp-id:

• A type representing the identifier of a TE interface Link Termination Point (LTP) on a specific TE node where the TE link connects. This attribute is mapped to a local or remote link identifier .

te-path-disjointness:

• A type representing the different resource disjointness options for a TE tunnel path as defined in .

admin-groups:

• A union type for a TE link's classic or extended administrative groups as defined in , , and .

srlg:

• A type representing the Shared Risk Link Group (SRLG) as defined in and .

te-metric:

• A type representing the TE metric as defined in .

te-recovery-status:

• An enumerated type for the different statuses of a recovery action as defined in and .

path-attribute-flags:

• A base YANG identity for supported LSP path flags as defined in , , , , , , , , , , , , , , , and .

link-protection-type:

• A base YANG identity for supported link protection types as defined in and .

restoration-scheme-type:

• A base YANG identity for supported LSP restoration schemes as defined in .

protection-external-commands:

• A base YANG identity for supported protection-related external commands used for troubleshooting purposes, as defined in and .

CHANGE NOTE: The description and reference of the identity action-exercise, which applies only to APS and it is not defined in RFC4427, has been updated to reference ITU-T G.808.1. RFC Editor: remove the CHANGE NOTE above and this note association-type:

• A base YANG identity for supported LSP association types as defined in , , , and .

CHANGE NOTE: The association-type-diversity identity, defined in has been added to the association-type base identity. RFC Editor: remove the CHANGE NOTE above and this note objective-function-type:

• A base YANG identity for supported path objective functions as defined in .

CHANGE NOTE: The objective-function-type identity has been redefined to be used only for path objective functions and a new svec-objective-function-type identity has been added for the Synchronization VECtor (SVEC) objective functions. Therefore the of-minimize-agg-bandwidth-consumption, of-minimize-load-most-loaded-link and of-minimize-cost-path-set identities, defined in and derived from the objective-function-type identity, have been obsoleted because not applicable to paths but to Synchronization VECtor (SVEC) objects. RFC Editor: remove the CHANGE NOTE above and this note te-tunnel-type:

• A base YANG identity for supported TE tunnel types as defined in and .

lsp-encoding-types:

• A base YANG identity for supported LSP encoding types as defined in .

lsp-protection-type:

• A base YANG identity for supported LSP protection types as defined in and .

switching-capabilities:

• A base YANG identity for supported interface switching capabilities as defined in .

resource-affinities-type:

• A base YANG identity for supported attribute filters associated with a tunnel that must be satisfied for a link to be acceptable as defined in and .

CHANGE NOTE: The description of the path-metric-type has been updated RFC Editor: remove the CHANGE NOTE above and this note path-metric-type:

• A base YANG identity for supported path metric types as defined in , , , and .

• The unit of the path metric value is interpreted in the context of the path metric type. The derived identities SHOULD describe the unit and maximum value of the path metric types they define.

• For example, the bound of the 'path-metric-loss', defined in 'ietf-te-packet-types', is defined in multiples of the basic unit 0.000003% as described in and .

explicit-route-hop:

• A YANG grouping that defines supported explicit routes as defined in and .

te-link-access-type:

• An enumerated type for the different TE link access types as defined in .

CHANGE NOTE: The module "ietf-te-types" has been updated to add the following YANG identities, types and groupings. RFC Editor: remove the CHANGE NOTE above and this note lsp-provisioning-error-reason:

• A base YANG identity for reporting LSP provisioning error reasons. No standard LPS provisioning error reasons are defined in this document.

path-computation-error-reason:

• A base YANG identity for reporting path computation error reasons as defined in .

protocol-origin-type:

• A base YANG identity for the type of protocol origin as defined in .

svec-objective-function-type:

• A base YANG identity for supported SVEC objective functions as defined in and .

svec-metric-type:

• A base YANG identity for supported SVEC objective functions as defined in .

encoding-and-switching-type:

• This is a common grouping to define the LSP encoding and switching types.

CHANGE NOTE: The tunnel-admin-state-auto YANG identity, derived from the tunnel-admin-status-type base YANG identity has also been added. No description is provided, since no description for the tunnel-admin-status-type base YANG identity has been provided in RFC8776. CHANGE NOTE: The lsp-restoration-restore-none YANG identity, derived from the lsp-restoration-type base YANG identity has also been added. No description is provided, since no description for the lsp-restoration-type base YANG identity has been provided in RFC8776. RFC Editor: remove the two CHANGE NOTEs above and this note

Path Computation Errors The "ietf-te-types" module contains the YANG reusable identities for reporting path computation error reasons as defined in , , , , , and . It also defines the following additional YANG reusable identities for reporting also the following path computation error reasons: path-computation-error-no-topology:

• A YANG identity for reporting path computation error when there is no topology with the provided topology identifier.

Protocol Origin The "ietf-te-types" module contains the YANG reusable identities for the type of protocol origin as defined in and . It also defines the following additional YANG reusable identities for the type of protocol origin: protocol-origin-api:

• A YANG identity to be used when the type of protocol origin is an Application Programmable Interface (API).

Packet TE Types Module Contents The "ietf-te-packet-types" module () covers the common types and groupings that are specific to packet technology. The "ietf-te-packet-types" module contains the following YANG reusable types and groupings: backup-protection-type:

• A base YANG identity for supported protection types that a backup or bypass tunnel can provide as defined in .

te-class-type:

• A type that represents the Diffserv-TE Class-Type as defined in .

bc-type:

• A type that represents Diffserv-TE Bandwidth Constraints (BCs) as defined in .

bc-model-type:

• A base YANG identity for supported Diffserv-TE Bandwidth Constraints Models as defined in , , and .

te-bandwidth-requested-type:

• An enumerated type for the different options to request bandwidth for a specific tunnel.

performance-metrics-attributes-packet:

• A YANG grouping that contains the generic performance metrics and additional packet-specific metrics.

CHANGE NOTE: The module "ietf-te-packet-types" has been updated to add the following YANG identities and groupings. RFC Editor: remove the CHANGE NOTE above and this note bandwidth-profile-type:

• A base YANG identity for various bandwidth profiles specified in , , and that may be used to limit bandwidth utilization of packet flows (e.g., MPLS-TE LSPs).

te-packet-path-bandwidth

• A YANG grouping that defines the path bandwidth information and could be used in any Packet TE model (e.g., MPLS-TE topology model) for the path bandwidth representation (e.g., the bandwidth of an MPLS-TE LSP).

• All the path and LSP bandwidth related sections in the "ietf-te-types" generic module, , need to be augmented with this grouping for the usage of Packet TE technologies.

• The Packet TE path bandwidth can be represented by a bandwidth profile as follow:

NOTE: Other formats for the MPLS-TE path bandwidth are defined in and they could be added in a future update of this document. te-packet-link-bandwidth:

• A YANG grouping that defines the link bandwidth information and could be used in any Packet TE model (e.g., MPLS-TE topology) for link bandwidth representation.

• All the link bandwidth related sections in the "ietf-te-types" generic module, , need to be augmented with this grouping for the usage of Packet TE technologies.

TE Types YANG Module The "ietf-te-types" module imports from the following modules: "ietf-yang-types" and "ietf-inet-types" as defined in "ietf-routing-types" as defined in In addition to and , this module references the following documents in defining the types and YANG groupings: , , , , , , , , , , , , , , and . CHANGE NOTE: Please focus your review only on the updates to the YANG model: see also . RFC Editor: remove the CHANGE NOTE above and this note

WG List: Editor: Tarek Saad Editor: Rakesh Gandhi Editor: Vishnu Pavan Beeram Editor: Xufeng Liu Editor: Igor Bryskin "; description "This YANG module contains a collection of generally useful YANG data type definitions specific to TE. The model fully conforms to the Network Management Datastore Architecture (NMDA). 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2024 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 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2024-01-29 { description "Added: - base identity lsp-provisioning-error-reason; - identity association-type-diversity; - identity tunnel-admin-state-auto; - identity lsp-restoration-restore-none; - identity restoration-scheme-rerouting; - base identity path-computation-error-reason and its derived identities; - base identity protocol-origin-type and its derived identities; - base identity svec-objective-function-type and its derived identities; - base identity svec-metric-type and its derived identities; - grouping encoding-and-switching-type. Updated: - description of the base identity objective-function-type; - description and reference of identity action-exercise; - typedef te-node-id to support also 16 octects TE identifiers. Obsoleted: - identity of-minimize-agg-bandwidth-consumption; - identity of-minimize-load-most-loaded-link; - identity of-minimize-cost-path-set; - identity lsp-protection-reroute-extra; - identity lsp-protection-reroute. Container explicit-route-objects-always renamed as explicit-route-objects."; reference "RFC XXXX: Common YANG Data Types for Traffic Engineering"; } // RFC Editor: replace XXXX with actual RFC number, update date // information and remove this note revision 2020-06-10 { description "Latest revision of TE types."; reference "RFC 8776: Common YANG Data Types for Traffic Engineering"; } /** * Typedefs */ typedef admin-group { type yang:hex-string { /* 01:02:03:04 */ length "1..11"; } description "Administrative group / resource class / color representation in 'hex-string' type. The most significant byte in the hex-string is the farthest to the left in the byte sequence. Leading zero bytes in the configured value may be omitted for brevity."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 5305: IS-IS Extensions for Traffic Engineering RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)"; } typedef admin-groups { type union { type admin-group; type extended-admin-group; } description "Derived types for TE administrative groups."; } typedef extended-admin-group { type yang:hex-string; description "Extended administrative group / resource class / color representation in 'hex-string' type. The most significant byte in the hex-string is the farthest to the left in the byte sequence. Leading zero bytes in the configured value may be omitted for brevity."; reference "RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)"; } typedef path-attribute-flags { type union { type identityref { base session-attributes-flags; } type identityref { base lsp-attributes-flags; } } description "Path attributes flags type."; } typedef performance-metrics-normality { type enumeration { enum unknown { value 0; description "Unknown."; } enum normal { value 1; description "Normal. Indicates that the anomalous bit is not set."; } enum abnormal { value 2; description "Abnormal. Indicates that the anomalous bit is set."; } } description "Indicates whether a performance metric is normal (anomalous bit not set), abnormal (anomalous bit set), or unknown."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } typedef srlg { type uint32; description "SRLG type."; reference "RFC 4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) RFC 5307: IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"; } typedef te-common-status { type enumeration { enum up { description "Enabled."; } enum down { description "Disabled."; } enum testing { description "In some test mode."; } enum preparing-maintenance { description "The resource is disabled in the control plane to prepare for a graceful shutdown for maintenance purposes."; reference "RFC 5817: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks"; } enum maintenance { description "The resource is disabled in the data plane for maintenance purposes."; } enum unknown { description "Status is unknown."; } } description "Defines a type representing the common states of a TE resource."; } typedef te-bandwidth { type string { pattern '0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|' + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?' + '[pP](\+)?(12[0-7]|' + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+' + '(,(0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|' + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?' + '[pP](\+)?(12[0-7]|' + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+))*'; } description "This is the generic bandwidth type. It is a string containing a list of numbers separated by commas, where each of these numbers can be non-negative decimal, hex integer, or hex float: (dec | hex | float)[*(','(dec | hex | float))] For the packet-switching type, the string encoding follows the type 'bandwidth-ieee-float32' as defined in RFC 8294 (e.g., 0x1p10), where the units are in bytes per second. For the Optical Transport Network (OTN) switching type, a list of integers can be used, such as '0,2,3,1', indicating two ODU0s and one ODU3. ('ODU' stands for 'Optical Data Unit'.) For Dense Wavelength Division Multiplexing (DWDM), a list of pairs of slot numbers and widths can be used, such as '0,2,3,3', indicating a frequency slot 0 with slot width 2 and a frequency slot 3 with slot width 3. Canonically, the string is represented as all lowercase and in hex, where the prefix '0x' precedes the hex number."; reference "RFC 8294: Common YANG Data Types for the Routing Area ITU-T Recommendation G.709: Interfaces for the optical transport network"; } typedef te-ds-class { type uint8 { range "0..7"; } description "The Differentiated Services Class-Type of traffic."; reference "RFC 4124: Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering, Section 4.3.1"; } typedef te-global-id { type uint32; description "An identifier to uniquely identify an operator, which can be either a provider or a client. The definition of this type is taken from RFCs 6370 and 5003. This attribute type is used solely to provide a globally unique context for TE topologies."; reference "RFC 5003: Attachment Individual Identifier (AII) Types for Aggregation RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers"; } typedef te-hop-type { type enumeration { enum loose { description "A loose hop in an explicit path."; } enum strict { description "A strict hop in an explicit path."; } } description "Enumerated type for specifying loose or strict paths."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3.3"; } typedef te-link-access-type { type enumeration { enum point-to-point { description "The link is point-to-point."; } enum multi-access { description "The link is multi-access, including broadcast and NBMA."; } } description "Defines a type representing the access type of a TE link."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2"; } typedef te-label-direction { type enumeration { enum forward { description "Label allocated for the forward LSP direction."; } enum reverse { description "Label allocated for the reverse LSP direction."; } } description "Enumerated type for specifying the forward or reverse label."; } typedef te-link-direction { type enumeration { enum incoming { description "The explicit route represents an incoming link on a node."; } enum outgoing { description "The explicit route represents an outgoing link on a node."; } } description "Enumerated type for specifying the direction of a link on a node."; } typedef te-metric { type uint32; description "TE metric."; reference "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric"; } // CHANGE NOTE: The typedef te-node-id below has been // updated in this module revision // RFC Editor: remove the note above and this note typedef te-node-id { type union { type yang:dotted-quad; type inet:ipv6-address-no-zone; } description "A type representing the identifier for a node in a TE topology. The identifier is represented either as 4 octets in dotted-quad notation or 16 octets in full, mixed, shortened, or shortened-mixed IPv6 address notation. This attribute MAY be mapped to the Router Address TLV described in Section 2.4.1 of RFC 3630, the TE Router ID described in Section 3 of RFC 6827, the Traffic Engineering Router ID TLV described in Section 4.3 of RFC 5305, the TE Router ID TLV described in Section 3.2.1 of RFC 6119, or the IPv6 TE Router ID TLV described in Section 4.1 of RFC 6119. The reachability of such a TE node MAY be achieved by a mechanism such as that described in Section 6.2 of RFC 6827."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2, Section 2.4.1 RFC 5305: IS-IS Extensions for Traffic Engineering, Section 4.3 RFC 6119: IPv6 Traffic Engineering in IS-IS, Section 3.2.1 RFC 6827: Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols, Section 3"; } typedef te-oper-status { type te-common-status; description "Defines a type representing the operational status of a TE resource."; } typedef te-admin-status { type te-common-status; description "Defines a type representing the administrative status of a TE resource."; } typedef te-path-disjointness { type bits { bit node { position 0; description "Node disjoint."; } bit link { position 1; description "Link disjoint."; } bit srlg { position 2; description "SRLG (Shared Risk Link Group) disjoint."; } } description "Type of the resource disjointness for a TE tunnel path."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } typedef te-recovery-status { type enumeration { enum normal { description "Both the recovery span and the working span are fully allocated and active, data traffic is being transported over (or selected from) the working span, and no trigger events are reported."; } enum recovery-started { description "The recovery action has been started but not completed."; } enum recovery-succeeded { description "The recovery action has succeeded. The working span has reported a failure/degrade condition, and the user traffic is being transported (or selected) on the recovery span."; } enum recovery-failed { description "The recovery action has failed."; } enum reversion-started { description "The reversion has started."; } enum reversion-succeeded { description "The reversion action has succeeded."; } enum reversion-failed { description "The reversion has failed."; } enum recovery-unavailable { description "The recovery is unavailable, as a result of either an operator's lockout command or a failure condition detected on the recovery span."; } enum recovery-admin { description "The operator has issued a command to switch the user traffic to the recovery span."; } enum wait-to-restore { description "The recovery domain is recovering from a failure/degrade condition on the working span that is being controlled by the Wait-to-Restore (WTR) timer."; } } description "Defines the status of a recovery action."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection"; } typedef te-template-name { type string { pattern '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*'; } description "A type for the name of a TE node template or TE link template."; } typedef te-topology-event-type { type enumeration { enum add { value 0; description "A TE node or TE link has been added."; } enum remove { value 1; description "A TE node or TE link has been removed."; } enum update { value 2; description "A TE node or TE link has been updated."; } } description "TE event type for notifications."; } typedef te-topology-id { type union { type string { length "0"; // empty string } type string { pattern '([a-zA-Z0-9\-_.]+:)*' + '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*'; } } description "An identifier for a topology. It is optional to have one or more prefixes at the beginning, separated by colons. The prefixes can be 'network-types' as defined in the 'ietf-network' module in RFC 8345, to help the user better understand the topology before further inquiry is made."; reference "RFC 8345: A YANG Data Model for Network Topologies"; } typedef te-tp-id { type union { type uint32; // Unnumbered type inet:ip-address; // IPv4 or IPv6 address } description "An identifier for a TE link endpoint on a node. This attribute is mapped to a local or remote link identifier as defined in RFCs 3630 and 5305."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 5305: IS-IS Extensions for Traffic Engineering"; } // CHANGE NOTE: The typedef path-type below has been // added in this module revision // RFC Editor: remove the note above and this note typedef path-type { type enumeration { enum primary-path { description "Indicates that the TE path is a primary path."; } enum secondary-path { description "Indicates that the TE path is a secondary path."; } enum primary-reverse-path { description "Indicates that the TE path is a primary reverse path."; } enum secondary-reverse-path { description "Indicates that the TE path is a secondary reverse path."; } } description "The type of TE path, indicating whether a path is a primary, or a reverse primary, or a secondary, or a reverse secondary path."; } // CHANGE NOTE: The typedef te-gen-node-id below has been // added in this module revision // RFC Editor: remove the note above and this note typedef te-gen-node-id { type union { type te-node-id; type inet:ip-address; type nw:node-id; } description "Generic type that identifies a node in a TE topology."; } /* TE features */ feature p2mp-te { description "Indicates support for Point-to-Multipoint TE (P2MP-TE)."; reference "RFC 4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"; } feature frr-te { description "Indicates support for TE Fast Reroute (FRR)."; reference "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"; } feature extended-admin-groups { description "Indicates support for TE link extended administrative groups."; reference "RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)"; } feature named-path-affinities { description "Indicates support for named path affinities."; } feature named-extended-admin-groups { description "Indicates support for named extended administrative groups."; } feature named-srlg-groups { description "Indicates support for named SRLG groups."; } feature named-path-constraints { description "Indicates support for named path constraints."; } feature path-optimization-metric { description "Indicates support for path optimization metrics."; } feature path-optimization-objective-function { description "Indicates support for path optimization objective functions."; } /* * Identities */ // CHANGE NOTE: The base identity lsp-provisioning-error-reason // has been added in this module revision // RFC Editor: remove the note above and this note identity lsp-provisioning-error-reason { description "Base identity for LSP provisioning errors."; } identity session-attributes-flags { description "Base identity for the RSVP-TE session attributes flags."; } identity local-protection-desired { base session-attributes-flags; description "Local protection is desired."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.7.1"; } identity se-style-desired { base session-attributes-flags; description "Shared explicit style, to allow the LSP to be established and share resources with the old LSP."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity local-recording-desired { base session-attributes-flags; description "Label recording is desired."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.7.1"; } identity bandwidth-protection-desired { base session-attributes-flags; description "Requests FRR bandwidth protection on LSRs, if present."; reference "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"; } identity node-protection-desired { base session-attributes-flags; description "Requests FRR node protection on LSRs, if present."; reference "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"; } identity path-reevaluation-request { base session-attributes-flags; description "This flag indicates that a path re-evaluation (of the current path in use) is requested. Note that this does not trigger any LSP reroutes but instead just signals a request to evaluate whether a preferable path exists."; reference "RFC 4736: Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)"; } identity soft-preemption-desired { base session-attributes-flags; description "Soft preemption of LSP resources is desired."; reference "RFC 5712: MPLS Traffic Engineering Soft Preemption"; } identity lsp-attributes-flags { description "Base identity for LSP attributes flags."; } identity end-to-end-rerouting-desired { base lsp-attributes-flags; description "Indicates end-to-end rerouting behavior for an LSP undergoing establishment. This MAY also be used to specify the behavior of end-to-end LSP recovery for established LSPs."; reference "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE RFC 5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity boundary-rerouting-desired { base lsp-attributes-flags; description "Indicates boundary rerouting behavior for an LSP undergoing establishment. This MAY also be used to specify segment-based LSP recovery through nested crankback for established LSPs. The boundary Area Border Router (ABR) / Autonomous System Border Router (ASBR) can decide to forward the PathErr message upstream to either an upstream boundary ABR/ASBR or the ingress LSR. Alternatively, it can try to select another egress boundary LSR."; reference "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE RFC 5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity segment-based-rerouting-desired { base lsp-attributes-flags; description "Indicates segment-based rerouting behavior for an LSP undergoing establishment. This MAY also be used to specify segment-based LSP recovery for established LSPs."; reference "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE RFC 5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity lsp-integrity-required { base lsp-attributes-flags; description "Indicates that LSP integrity is required."; reference "RFC 4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity contiguous-lsp-desired { base lsp-attributes-flags; description "Indicates that a contiguous LSP is desired."; reference "RFC 5151: Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity lsp-stitching-desired { base lsp-attributes-flags; description "Indicates that LSP stitching is desired."; reference "RFC 5150: Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity pre-planned-lsp-flag { base lsp-attributes-flags; description "Indicates that the LSP MUST be provisioned in the control plane only."; reference "RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity non-php-behavior-flag { base lsp-attributes-flags; description "Indicates that non-PHP (non-Penultimate Hop Popping) behavior for the LSP is desired."; reference "RFC 6511: Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity oob-mapping-flag { base lsp-attributes-flags; description "Indicates that signaling of the egress binding information is out of band (e.g., via the Border Gateway Protocol (BGP))."; reference "RFC 6511: Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity entropy-label-capability { base lsp-attributes-flags; description "Indicates entropy label capability."; reference "RFC 6790: The Use of Entropy Labels in MPLS Forwarding RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity oam-mep-entity-desired { base lsp-attributes-flags; description "OAM Maintenance Entity Group End Point (MEP) entities desired."; reference "RFC 7260: GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration"; } identity oam-mip-entity-desired { base lsp-attributes-flags; description "OAM Maintenance Entity Group Intermediate Points (MIP) entities desired."; reference "RFC 7260: GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration"; } identity srlg-collection-desired { base lsp-attributes-flags; description "SRLG collection desired."; reference "RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) RFC 8001: RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information"; } identity loopback-desired { base lsp-attributes-flags; description "This flag indicates that a particular node on the LSP is required to enter loopback mode. This can also be used to specify the loopback state of the node."; reference "RFC 7571: GMPLS RSVP-TE Extensions for Lock Instruct and Loopback"; } identity p2mp-te-tree-eval-request { base lsp-attributes-flags; description "P2MP-TE tree re-evaluation request."; reference "RFC 8149: RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)"; } identity rtm-set-desired { base lsp-attributes-flags; description "Residence Time Measurement (RTM) attribute flag requested."; reference "RFC 8169: Residence Time Measurement in MPLS Networks"; } identity link-protection-type { description "Base identity for the link protection type."; } identity link-protection-unprotected { base link-protection-type; description "Unprotected link type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity link-protection-extra-traffic { base link-protection-type; description "Extra-Traffic protected link type."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity link-protection-shared { base link-protection-type; description "Shared protected link type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity link-protection-1-for-1 { base link-protection-type; description "One-for-one (1:1) protected link type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity link-protection-1-plus-1 { base link-protection-type; description "One-plus-one (1+1) protected link type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity link-protection-enhanced { base link-protection-type; description "A compound link protection type derived from the underlay TE tunnel protection configuration supporting the TE link."; } identity association-type { description "Base identity for the tunnel association."; } identity association-type-recovery { base association-type; description "Association type for recovery, used to associate LSPs of the same tunnel for recovery."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery RFC 6780: RSVP ASSOCIATION Object Extensions"; } identity association-type-resource-sharing { base association-type; description "Association type for resource sharing, used to enable resource sharing during make-before-break."; reference "RFC 4873: GMPLS Segment Recovery RFC 6780: RSVP ASSOCIATION Object Extensions"; } identity association-type-double-sided-bidir { base association-type; description "Association type for double-sided bidirectional LSPs, used to associate two LSPs of two tunnels that are independently configured on either endpoint."; reference "RFC 7551: RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"; } identity association-type-single-sided-bidir { base association-type; description "Association type for single-sided bidirectional LSPs, used to associate two LSPs of two tunnels, where one tunnel is configured on one side/endpoint and the other tunnel is dynamically created on the other endpoint."; reference "RFC 6780: RSVP ASSOCIATION Object Extensions RFC 7551: RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"; } // CHANGE NOTE: The identity association-type-diversity below has // been added in this module revision // RFC Editor: remove the note above and this note identity association-type-diversity { base association-type; description "Association Type diversity used to associate LSPs whose paths are to be diverse from each other."; reference "RFC8800: Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling"; } // CHANGE NOTE: The description of the base identity // objective-function-type has been updated // in this module revision // RFC Editor: remove the note above and this note identity objective-function-type { description "Base identity for path objective function type."; } identity of-minimize-cost-path { base objective-function-type; description "Objective function for minimizing path cost."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-minimize-load-path { base objective-function-type; description "Objective function for minimizing the load on one or more paths."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-maximize-residual-bandwidth { base objective-function-type; description "Objective function for maximizing residual bandwidth."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } // CHANGE NOTE: The identity of-minimize-agg-bandwidth-consumption // below has been obsoleted in this module revision // RFC Editor: remove the note above and this note identity of-minimize-agg-bandwidth-consumption { base objective-function-type; status obsolete; description "Objective function for minimizing aggregate bandwidth consumption."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } // CHANGE NOTE: The identity of-minimize-load-most-loaded-link // below has been obsoleted in this module revision // RFC Editor: remove the note above and this note identity of-minimize-load-most-loaded-link { base objective-function-type; status obsolete; description "Objective function for minimizing the load on the link that is carrying the highest load."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } // CHANGE NOTE: The identity of-minimize-cost-path-set // below has been obsoleted in this module revision // RFC Editor: remove the note above and this note identity of-minimize-cost-path-set { base objective-function-type; status obsolete; description "Objective function for minimizing the cost on a path set."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity path-computation-method { description "Base identity for supported path computation mechanisms."; } identity path-locally-computed { base path-computation-method; description "Indicates a constrained-path LSP in which the path is computed by the local LER."; reference "RFC 3272: Overview and Principles of Internet Traffic Engineering, Section 5.4"; } identity path-externally-queried { base path-computation-method; description "Constrained-path LSP in which the path is obtained by querying an external source, such as a PCE server. In the case that an LSP is defined to be externally queried, it may also have associated explicit definitions (provided to the external source to aid computation). The path that is returned by the external source may require further local computation on the device."; reference "RFC 3272: Overview and Principles of Internet Traffic Engineering RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity path-explicitly-defined { base path-computation-method; description "Constrained-path LSP in which the path is explicitly specified as a collection of strict and/or loose hops."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 3272: Overview and Principles of Internet Traffic Engineering"; } identity lsp-metric-type { description "Base identity for the LSP metric specification types."; } identity lsp-metric-relative { base lsp-metric-type; description "The metric specified for the LSPs to which this identity refers is specified as a value relative to the IGP metric cost to the LSP's tail end."; reference "RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity lsp-metric-absolute { base lsp-metric-type; description "The metric specified for the LSPs to which this identity refers is specified as an absolute value."; reference "RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity lsp-metric-inherited { base lsp-metric-type; description "The metric for the LSPs to which this identity refers is not specified explicitly; rather, it is directly inherited from the IGP cost."; reference "RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity te-tunnel-type { description "Base identity from which specific tunnel types are derived."; } identity te-tunnel-p2p { base te-tunnel-type; description "TE Point-to-Point (P2P) tunnel type."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity te-tunnel-p2mp { base te-tunnel-type; description "TE P2MP tunnel type."; reference "RFC 4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"; } identity tunnel-action-type { description "Base identity from which specific tunnel action types are derived."; } identity tunnel-action-resetup { base tunnel-action-type; description "TE tunnel action that tears down the tunnel's current LSP (if any) and attempts to re-establish a new LSP."; } identity tunnel-action-reoptimize { base tunnel-action-type; description "TE tunnel action that reoptimizes the placement of the tunnel LSP(s)."; } identity tunnel-action-switchpath { base tunnel-action-type; description "TE tunnel action that switches the tunnel's LSP to use the specified path."; } identity te-action-result { description "Base identity from which specific TE action results are derived."; } identity te-action-success { base te-action-result; description "TE action was successful."; } identity te-action-fail { base te-action-result; description "TE action failed."; } identity tunnel-action-inprogress { base te-action-result; description "TE action is in progress."; } identity tunnel-admin-state-type { description "Base identity for TE tunnel administrative states."; } identity tunnel-admin-state-up { base tunnel-admin-state-type; description "Tunnel's administrative state is up."; } identity tunnel-admin-state-down { base tunnel-admin-state-type; description "Tunnel's administrative state is down."; } // CHANGE NOTE: The identity tunnel-admin-state-auto below // has been added in this module revision // RFC Editor: remove the note above and this note identity tunnel-admin-state-auto { base tunnel-admin-state-type; description "Tunnel administrative auto state. The administrative status in state datastore transitions to 'tunnel-admin-up' when the tunnel used by the client layer, and to 'tunnel-admin-down' when it is not used by the client layer."; } identity tunnel-state-type { description "Base identity for TE tunnel states."; } identity tunnel-state-up { base tunnel-state-type; description "Tunnel's state is up."; } identity tunnel-state-down { base tunnel-state-type; description "Tunnel's state is down."; } identity lsp-state-type { description "Base identity for TE LSP states."; } identity lsp-path-computing { base lsp-state-type; description "State path computation is in progress."; } identity lsp-path-computation-ok { base lsp-state-type; description "State path computation was successful."; } identity lsp-path-computation-failed { base lsp-state-type; description "State path computation failed."; } identity lsp-state-setting-up { base lsp-state-type; description "State is being set up."; } identity lsp-state-setup-ok { base lsp-state-type; description "State setup was successful."; } identity lsp-state-setup-failed { base lsp-state-type; description "State setup failed."; } identity lsp-state-up { base lsp-state-type; description "State is up."; } identity lsp-state-tearing-down { base lsp-state-type; description "State is being torn down."; } identity lsp-state-down { base lsp-state-type; description "State is down."; } identity path-invalidation-action-type { description "Base identity for TE path invalidation action types."; } identity path-invalidation-action-drop { base path-invalidation-action-type; description "Upon invalidation of the TE tunnel path, the tunnel remains valid, but any packet mapped over the tunnel is dropped."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 2.5"; } identity path-invalidation-action-teardown { base path-invalidation-action-type; description "TE path invalidation action teardown."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 2.5"; } identity lsp-restoration-type { description "Base identity from which LSP restoration types are derived."; } // CHANGE NOTE: The identity lsp-restoration-restore-none // below has been added in this module revision // RFC Editor: remove the note above and this note identity lsp-restoration-restore-none { base lsp-restoration-type; description "No LSP affected by a failure is restored."; } identity lsp-restoration-restore-any { base lsp-restoration-type; description "Any LSP affected by a failure is restored."; } identity lsp-restoration-restore-all { base lsp-restoration-type; description "Affected LSPs are restored after all LSPs of the tunnel are broken."; } identity restoration-scheme-type { description "Base identity for LSP restoration schemes."; } // CHANGE NOTE: The identity restoration-scheme-rerouting // below has been added in this module revision // RFC Editor: remove the note above and this note identity restoration-scheme-rerouting { base restoration-scheme-type; description "Restoration LSP is computed after the failure detection. This restoration scheme is also known as 'Full LSP Re-routing.'"; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity restoration-scheme-preconfigured { base restoration-scheme-type; description "Restoration LSP is preconfigured prior to the failure."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity restoration-scheme-precomputed { base restoration-scheme-type; description "Restoration LSP is precomputed prior to the failure."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity restoration-scheme-presignaled { base restoration-scheme-type; description "Restoration LSP is presignaled prior to the failure."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity lsp-protection-type { description "Base identity from which LSP protection types are derived."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-unprotected { base lsp-protection-type; description "'Unprotected' LSP protection type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } // CHANGE NOTE: The identity lsp-protection-reroute-extra // below has been obsoleted in this module revision // RFC Editor: remove the note above and this note identity lsp-protection-reroute-extra { base lsp-protection-type; status obsolete; description "'(Full) Rerouting' LSP protection type. This identity has been obsoleted: the 'restoration-scheme-rerouting' identity SHOULD be used instead."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } // CHANGE NOTE: The identity lsp-protection-reroute // below has been obsoleted in this module revision // RFC Editor: remove the note above and this note identity lsp-protection-reroute { base lsp-protection-type; status obsolete; description "'Rerouting without Extra-Traffic' LSP protection type. This identity has been obsoleted: the 'restoration-scheme-rerouting' identity SHOULD be used instead."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-1-for-n { base lsp-protection-type; description "'1:N Protection with Extra-Traffic' LSP protection type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-1-for-1 { base lsp-protection-type; description "LSP protection '1:1 Protection Type'."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-unidir-1-plus-1 { base lsp-protection-type; description "'1+1 Unidirectional Protection' LSP protection type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-bidir-1-plus-1 { base lsp-protection-type; description "'1+1 Bidirectional Protection' LSP protection type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-extra-traffic { base lsp-protection-type; description "Extra-Traffic LSP protection type."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity lsp-protection-state { description "Base identity of protection states for reporting purposes."; } identity normal { base lsp-protection-state; description "Normal state."; } identity signal-fail-of-protection { base lsp-protection-state; description "The protection transport entity has a signal fail condition that is of higher priority than the forced switchover command."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity lockout-of-protection { base lsp-protection-state; description "A Loss of Protection (LoP) command is active."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity forced-switch { base lsp-protection-state; description "A forced switchover command is active."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity signal-fail { base lsp-protection-state; description "There is a signal fail condition on either the working path or the protection path."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity signal-degrade { base lsp-protection-state; description "There is a signal degrade condition on either the working path or the protection path."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity manual-switch { base lsp-protection-state; description "A manual switchover command is active."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity wait-to-restore { base lsp-protection-state; description "A WTR timer is running."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity do-not-revert { base lsp-protection-state; description "A Do Not Revert (DNR) condition is active because of non-revertive behavior."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity failure-of-protocol { base lsp-protection-state; description "LSP protection is not working because of a protocol failure condition."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity protection-external-commands { description "Base identity from which protection-related external commands used for troubleshooting purposes are derived."; } identity action-freeze { base protection-external-commands; description "A temporary configuration action initiated by an operator command that prevents any switchover action from being taken and, as such, freezes the current state."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity clear-freeze { base protection-external-commands; description "An action that clears the active freeze state."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-lockout-of-normal { base protection-external-commands; description "A temporary configuration action initiated by an operator command to ensure that the normal traffic is not allowed to use the protection transport entity."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity clear-lockout-of-normal { base protection-external-commands; description "An action that clears the active lockout of the normal state."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-lockout-of-protection { base protection-external-commands; description "A temporary configuration action initiated by an operator command to ensure that the protection transport entity is temporarily not available to transport a traffic signal (either normal or Extra-Traffic)."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-forced-switch { base protection-external-commands; description "A switchover action initiated by an operator command to switch the Extra-Traffic signal, the normal traffic signal, or the null signal to the protection transport entity, unless a switchover command of equal or higher priority is in effect."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-manual-switch { base protection-external-commands; description "A switchover action initiated by an operator command to switch the Extra-Traffic signal, the normal traffic signal, or the null signal to the protection transport entity, unless a fault condition exists on other transport entities or a switchover command of equal or higher priority is in effect."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } // CHANGE NOTE: The description and reference of the // identity action-exercise have been updated in this module // revision // RFC Editor: remove the note above and this note identity action-exercise { base protection-external-commands; description "An action that starts testing whether or not Automatic Protection Switching (APS) communication is operating correctly. It is of lower priority than any other state or command."; reference "ITU-T G.808.1 v4.0 (05/2014): Generic protection switching - Linear trail and subnetwork protection"; } identity clear { base protection-external-commands; description "An action that clears the active near-end lockout of a protection, forced switchover, manual switchover, WTR state, or exercise command."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity switching-capabilities { description "Base identity for interface switching capabilities."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-psc1 { base switching-capabilities; description "Packet-Switch Capable-1 (PSC-1)."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-evpl { base switching-capabilities; description "Ethernet Virtual Private Line (EVPL)."; reference "RFC 6004: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching"; } identity switching-l2sc { base switching-capabilities; description "Layer-2 Switch Capable (L2SC)."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-tdm { base switching-capabilities; description "Time-Division-Multiplex Capable (TDM)."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-otn { base switching-capabilities; description "OTN-TDM capable."; reference "RFC 7138: Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks"; } identity switching-dcsc { base switching-capabilities; description "Data Channel Switching Capable (DCSC)."; reference "RFC 6002: Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions"; } identity switching-lsc { base switching-capabilities; description "Lambda-Switch Capable (LSC)."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-fsc { base switching-capabilities; description "Fiber-Switch Capable (FSC)."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-types { description "Base identity for encoding types."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-packet { base lsp-encoding-types; description "Packet LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-ethernet { base lsp-encoding-types; description "Ethernet LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-pdh { base lsp-encoding-types; description "ANSI/ETSI PDH LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-sdh { base lsp-encoding-types; description "SDH ITU-T G.707 / SONET ANSI T1.105 LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-digital-wrapper { base lsp-encoding-types; description "Digital Wrapper LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-lambda { base lsp-encoding-types; description "Lambda (photonic) LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-fiber { base lsp-encoding-types; description "Fiber LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-fiber-channel { base lsp-encoding-types; description "FiberChannel LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-oduk { base lsp-encoding-types; description "G.709 ODUk (Digital Path) LSP encoding."; reference "RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control"; } identity lsp-encoding-optical-channel { base lsp-encoding-types; description "G.709 Optical Channel LSP encoding."; reference "RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control"; } identity lsp-encoding-line { base lsp-encoding-types; description "Line (e.g., 8B/10B) LSP encoding."; reference "RFC 6004: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching"; } identity path-signaling-type { description "Base identity from which specific LSP path setup types are derived."; } identity path-setup-static { base path-signaling-type; description "Static LSP provisioning path setup."; } identity path-setup-rsvp { base path-signaling-type; description "RSVP-TE signaling path setup."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity path-setup-sr { base path-signaling-type; description "Segment-routing path setup."; } identity path-scope-type { description "Base identity from which specific path scope types are derived."; } identity path-scope-segment { base path-scope-type; description "Path scope segment."; reference "RFC 4873: GMPLS Segment Recovery"; } identity path-scope-end-to-end { base path-scope-type; description "Path scope end to end."; reference "RFC 4873: GMPLS Segment Recovery"; } identity route-usage-type { description "Base identity for route usage."; } identity route-include-object { base route-usage-type; description "'Include route' object."; } identity route-exclude-object { base route-usage-type; description "'Exclude route' object."; reference "RFC 4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"; } identity route-exclude-srlg { base route-usage-type; description "Excludes SRLGs."; reference "RFC 4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"; } // CHANGE NOTE: The description of the identity path-metric-type // has been updated in this module revision // RFC Editor: remove the note above and this note identity path-metric-type { description "Base identity for the path metric type. Derived identities SHOULD describe the unit and maximum value of the path metric types they define."; } identity path-metric-te { base path-metric-type; description "TE path metric."; reference "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric"; } identity path-metric-igp { base path-metric-type; description "IGP path metric."; reference "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric"; } // CHANGE NOTE: The reference for the identity path-metric-hop // has been added in this module revision // RFC Editor: remove the note above and this note identity path-metric-hop { base path-metric-type; description "Hop path metric."; reference "RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP)"; } identity path-metric-delay-average { base path-metric-type; description "Average unidirectional link delay."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions"; } identity path-metric-delay-minimum { base path-metric-type; description "Minimum unidirectional link delay."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions"; } identity path-metric-residual-bandwidth { base path-metric-type; description "Unidirectional Residual Bandwidth, which is defined to be Maximum Bandwidth (RFC 3630) minus the bandwidth currently allocated to LSPs."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions"; } identity path-metric-optimize-includes { base path-metric-type; description "A metric that optimizes the number of included resources specified in a set."; } identity path-metric-optimize-excludes { base path-metric-type; description "A metric that optimizes to a maximum the number of excluded resources specified in a set."; } identity path-tiebreaker-type { description "Base identity for the path tiebreaker type."; } identity path-tiebreaker-minfill { base path-tiebreaker-type; description "Min-Fill LSP path placement."; } identity path-tiebreaker-maxfill { base path-tiebreaker-type; description "Max-Fill LSP path placement."; } identity path-tiebreaker-random { base path-tiebreaker-type; description "Random LSP path placement."; } identity resource-affinities-type { description "Base identity for resource class affinities."; reference "RFC 2702: Requirements for Traffic Engineering Over MPLS"; } identity resource-aff-include-all { base resource-affinities-type; description "The set of attribute filters associated with a tunnel, all of which must be present for a link to be acceptable."; reference "RFC 2702: Requirements for Traffic Engineering Over MPLS RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity resource-aff-include-any { base resource-affinities-type; description "The set of attribute filters associated with a tunnel, any of which must be present for a link to be acceptable."; reference "RFC 2702: Requirements for Traffic Engineering Over MPLS RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity resource-aff-exclude-any { base resource-affinities-type; description "The set of attribute filters associated with a tunnel, any of which renders a link unacceptable."; reference "RFC 2702: Requirements for Traffic Engineering Over MPLS RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity te-optimization-criterion { description "Base identity for the TE optimization criteria."; reference "RFC 3272: Overview and Principles of Internet Traffic Engineering"; } identity not-optimized { base te-optimization-criterion; description "Optimization is not applied."; } identity cost { base te-optimization-criterion; description "Optimized on cost."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity delay { base te-optimization-criterion; description "Optimized on delay."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity path-computation-srlg-type { description "Base identity for SRLG path computation."; } identity srlg-ignore { base path-computation-srlg-type; description "Ignores SRLGs in the path computation."; } identity srlg-strict { base path-computation-srlg-type; description "Includes a strict SRLG check in the path computation."; } identity srlg-preferred { base path-computation-srlg-type; description "Includes a preferred SRLG check in the path computation."; } identity srlg-weighted { base path-computation-srlg-type; description "Includes a weighted SRLG check in the path computation."; } // CHANGE NOTE: The base identity path-computation-error-reason // and its derived identities below have been // added in this module revision // RFC Editor: remove the note above and this note identity path-computation-error-reason { description "Base identity for path computation error reasons."; } identity path-computation-error-path-not-found { base path-computation-error-reason; description "Path computation has failed because of an unspecified reason."; reference "Section 7.5 of RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP)"; } identity path-computation-error-no-topology { base path-computation-error-reason; description "Path computation has failed because there is no topology with the provided topology-identifier."; } identity path-computation-error-no-dependent-server { base path-computation-error-reason; description "Path computation has failed because one or more dependent path computation servers are unavailable. The dependent path computation server could be a Backward-Recursive Path Computation (BRPC) downstream PCE or a child PCE."; reference "RFC5441, RFC8685"; } identity path-computation-error-pce-unavailable { base path-computation-error-reason; description "Path computation has failed because PCE is not available. It corresponds to bit 31 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP); https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-no-inclusion-hop { base path-computation-error-reason; description "Path computation has failed because there is no node or link provided by one or more inclusion hops."; } identity path-computation-error-destination-unknown-in-domain { base path-computation-error-reason; description "Path computation has failed because the destination node is unknown in indicated destination domain. It corresponds to bit 19 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC8685; https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-no-resource { base path-computation-error-reason; description "Path computation has failed because there is no available resource in one or more domains. It corresponds to bit 20 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC8685; https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-child-pce-unresponsive { base path-computation-error-no-dependent-server; description "Path computation has failed because child PCE is not responsive. It corresponds to bit 21 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC8685; https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-destination-domain-unknown { base path-computation-error-reason; description "Path computation has failed because the destination domain was unknown. It corresponds to bit 22 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC8685; https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-p2mp { base path-computation-error-reason; description "Path computation has failed because of P2MP reachability problem. It corresponds to bit 24 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC8306; https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-no-gco-migration { base path-computation-error-reason; description "Path computation has failed because of no Global Concurrent Optimization (GCO) migration path found. It corresponds to bit 26 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC5557; https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-no-gco-solution { base path-computation-error-reason; description "Path computation has failed because of no GCO solution found. It corresponds to bit 25 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC5557; https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-pks-expansion { base path-computation-error-reason; description "Path computation has failed because of Path-Key Subobject (PKS) expansion failure. It corresponds to bit 27 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC5520; https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-brpc-chain-unavailable { base path-computation-error-no-dependent-server; description "Path computation has failed because PCE BRPC chain unavailable. It corresponds to bit 28 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC5441; https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-source-unknown { base path-computation-error-reason; description "Path computation has failed because source node is unknown. It corresponds to bit 29 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP); https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-destination-unknown { base path-computation-error-reason; description "Path computation has failed because destination node is unknown. It corresponds to bit 30 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP); https://www.iana.org/assignments/pcep/pcep.xhtml"; } identity path-computation-error-no-server { base path-computation-error-reason; description "Path computation has failed because path computation server is unavailable."; reference "RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP); https://www.iana.org/assignments/pcep/pcep.xhtml"; } // CHANGE NOTE: The base identity protocol-origin-type and // its derived identities below have been // added in this module revision // RFC Editor: remove the note above and this note identity protocol-origin-type { description "Base identity for protocol origin type."; } identity protocol-origin-api { base protocol-origin-type; description "Protocol origin is via Application Programmable Interface (API)."; } identity protocol-origin-pcep { base protocol-origin-type; description "Protocol origin is Path Computation Engine Protocol (PCEP)."; reference "RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP)"; } identity protocol-origin-bgp { base protocol-origin-type; description "Protocol origin is Border Gateway Protocol (BGP)."; reference "RFC9012"; } // CHANGE NOTE: The base identity svec-objective-function-type // and its derived identities below have been // added in this module revision // RFC Editor: remove the note above and this note identity svec-objective-function-type { description "Base identity for SVEC objective function type."; reference "RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)."; } identity svec-of-minimize-agg-bandwidth-consumption { base svec-objective-function-type; description "Objective function for minimizing aggregate bandwidth consumption (MBC)."; reference "RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)."; } identity svec-of-minimize-load-most-loaded-link { base svec-objective-function-type; description "Objective function for minimizing the load on the link that is carrying the highest load (MLL)."; reference "RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)."; } identity svec-of-minimize-cost-path-set { base svec-objective-function-type; description "Objective function for minimizing the cost on a path set (MCC)."; reference "RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)."; } identity svec-of-minimize-common-transit-domain { base svec-objective-function-type; description "Objective function for minimizing the number of common transit domains (MCTD)."; reference "RFC8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture."; } identity svec-of-minimize-shared-link { base svec-objective-function-type; description "Objective function for minimizing the number of shared links (MSL)."; reference "RFC8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture."; } identity svec-of-minimize-shared-srlg { base svec-objective-function-type; description "Objective function for minimizing the number of shared Shared Risk Link Groups (SRLG) (MSS)."; reference "RFC8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture."; } identity svec-of-minimize-shared-nodes { base svec-objective-function-type; description "Objective function for minimizing the number of shared nodes (MSN)."; reference "RFC8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture."; } // CHANGE NOTE: The base identity svec-metric-type and // its derived identities below have been // added in this module revision // RFC Editor: remove the note above and this note identity svec-metric-type { description "Base identity for SVEC metric type."; reference "RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)."; } identity svec-metric-cumul-te { base svec-metric-type; description "Cumulative TE cost."; reference "RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)."; } identity svec-metric-cumul-igp { base svec-metric-type; description "Cumulative IGP cost."; reference "RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)."; } identity svec-metric-cumul-hop { base svec-metric-type; description "Cumulative Hop path metric."; reference "RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)."; } identity svec-metric-aggregate-bandwidth-consumption { base svec-metric-type; description "Aggregate bandwidth consumption."; reference "RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)."; } identity svec-metric-load-of-the-most-loaded-link { base svec-metric-type; description "Load of the most loaded link."; reference "RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)."; } /** * TE bandwidth groupings **/ grouping te-bandwidth { description "This grouping defines the generic TE bandwidth. For some known data-plane technologies, specific modeling structures are specified. The string-encoded 'te-bandwidth' type is used for unspecified technologies. The modeling structure can be augmented later for other technologies."; container te-bandwidth { description "Container that specifies TE bandwidth. The choices can be augmented for specific data-plane technologies."; choice technology { default "generic"; description "Data-plane technology type."; case generic { leaf generic { type te-bandwidth; description "Bandwidth specified in a generic format."; } } } } } /** * TE label groupings **/ grouping te-label { description "This grouping defines the generic TE label. The modeling structure can be augmented for each technology. For unspecified technologies, 'rt-types:generalized-label' is used."; container te-label { description "Container that specifies the TE label. The choices can be augmented for specific data-plane technologies."; choice technology { default "generic"; description "Data-plane technology type."; case generic { leaf generic { type rt-types:generalized-label; description "TE label specified in a generic format."; } } } leaf direction { type te-label-direction; default "forward"; description "Label direction."; } } } grouping te-topology-identifier { description "Augmentation for a TE topology."; container te-topology-identifier { description "TE topology identifier container."; leaf provider-id { type te-global-id; default "0"; description "An identifier to uniquely identify a provider. If omitted, it assumes that the topology provider ID value = 0 (the default)."; } leaf client-id { type te-global-id; default "0"; description "An identifier to uniquely identify a client. If omitted, it assumes that the topology client ID value = 0 (the default)."; } leaf topology-id { type te-topology-id; default ""; description "When the datastore contains several topologies, 'topology-id' distinguishes between them. If omitted, the default (empty) string for this leaf is assumed."; } } } /** * TE performance metrics groupings **/ grouping performance-metrics-one-way-delay-loss { description "Performance Metrics (PM) information in real time that can be applicable to links or connections. PM defined in this grouping are applicable to generic TE PM as well as packet TE PM."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; leaf one-way-delay { type uint32 { range "0..16777215"; } description "One-way delay or latency in microseconds."; } leaf one-way-delay-normality { type te-types:performance-metrics-normality; description "One-way delay normality."; } } grouping performance-metrics-two-way-delay-loss { description "PM information in real time that can be applicable to links or connections. PM defined in this grouping are applicable to generic TE PM as well as packet TE PM."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; leaf two-way-delay { type uint32 { range "0..16777215"; } description "Two-way delay or latency in microseconds."; } leaf two-way-delay-normality { type te-types:performance-metrics-normality; description "Two-way delay normality."; } } grouping performance-metrics-one-way-bandwidth { description "PM information in real time that can be applicable to links. PM defined in this grouping are applicable to generic TE PM as well as packet TE PM."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; leaf one-way-residual-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Residual bandwidth that subtracts tunnel reservations from Maximum Bandwidth (or link capacity) (RFC 3630) and provides an aggregated remainder across QoS classes."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2"; } leaf one-way-residual-bandwidth-normality { type te-types:performance-metrics-normality; default "normal"; description "Residual bandwidth normality."; } leaf one-way-available-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Available bandwidth that is defined to be residual bandwidth minus the measured bandwidth used for the actual forwarding of non-RSVP-TE LSP packets. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths."; } leaf one-way-available-bandwidth-normality { type te-types:performance-metrics-normality; default "normal"; description "Available bandwidth normality."; } leaf one-way-utilized-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Bandwidth utilization that represents the actual utilization of the link (i.e., as measured in the router). For a bundled link, bandwidth utilization is defined to be the sum of the component link bandwidth utilizations."; } leaf one-way-utilized-bandwidth-normality { type te-types:performance-metrics-normality; default "normal"; description "Bandwidth utilization normality."; } } grouping one-way-performance-metrics { description "One-way PM throttle grouping."; leaf one-way-delay { type uint32 { range "0..16777215"; } default "0"; description "One-way delay or latency in microseconds."; } leaf one-way-residual-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Residual bandwidth that subtracts tunnel reservations from Maximum Bandwidth (or link capacity) (RFC 3630) and provides an aggregated remainder across QoS classes."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2"; } leaf one-way-available-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Available bandwidth that is defined to be residual bandwidth minus the measured bandwidth used for the actual forwarding of non-RSVP-TE LSP packets. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths."; } leaf one-way-utilized-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Bandwidth utilization that represents the actual utilization of the link (i.e., as measured in the router). For a bundled link, bandwidth utilization is defined to be the sum of the component link bandwidth utilizations."; } } grouping two-way-performance-metrics { description "Two-way PM throttle grouping."; leaf two-way-delay { type uint32 { range "0..16777215"; } default "0"; description "Two-way delay or latency in microseconds."; } } grouping performance-metrics-thresholds { description "Grouping for configurable thresholds for measured attributes."; uses one-way-performance-metrics; uses two-way-performance-metrics; } grouping performance-metrics-attributes { description "Contains PM attributes."; container performance-metrics-one-way { description "One-way link performance information in real time."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; uses performance-metrics-one-way-delay-loss; uses performance-metrics-one-way-bandwidth; } container performance-metrics-two-way { description "Two-way link performance information in real time."; reference "RFC 6374: Packet Loss and Delay Measurement for MPLS Networks"; uses performance-metrics-two-way-delay-loss; } } grouping performance-metrics-throttle-container { description "Controls PM throttling."; container throttle { must 'suppression-interval >= measure-interval' { error-message "'suppression-interval' cannot be less than " + "'measure-interval'."; description "Constraint on 'suppression-interval' and 'measure-interval'."; } description "Link performance information in real time."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; leaf one-way-delay-offset { type uint32 { range "0..16777215"; } default "0"; description "Offset value to be added to the measured delay value."; } leaf measure-interval { type uint32; default "30"; description "Interval, in seconds, to measure the extended metric values."; } leaf advertisement-interval { type uint32; default "0"; description "Interval, in seconds, to advertise the extended metric values."; } leaf suppression-interval { type uint32 { range "1..max"; } default "120"; description "Interval, in seconds, to suppress advertisement of the extended metric values."; reference "RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 6"; } container threshold-out { uses performance-metrics-thresholds; description "If the measured parameter falls outside an upper bound for all but the minimum-delay metric (or a lower bound for the minimum-delay metric only) and the advertised value is not already outside that bound, an 'anomalous' announcement (anomalous bit set) will be triggered."; } container threshold-in { uses performance-metrics-thresholds; description "If the measured parameter falls inside an upper bound for all but the minimum-delay metric (or a lower bound for the minimum-delay metric only) and the advertised value is not already inside that bound, a 'normal' announcement (anomalous bit cleared) will be triggered."; } container threshold-accelerated-advertisement { description "When the difference between the last advertised value and the current measured value exceeds this threshold, an 'anomalous' announcement (anomalous bit set) will be triggered."; uses performance-metrics-thresholds; } } } /** * TE tunnel generic groupings **/ // CHANGE NOTE: The explicit-route-hop grouping below has been // updated in this module revision // RFC Editor: remove the note above and this note grouping explicit-route-hop { description "The explicit route entry grouping."; choice type { description "The explicit route entry type."; case numbered-node-hop { container numbered-node-hop { must "node-id-uri or node-id" { description "At least one node identifier MUST be present."; } leaf node-id-uri { type nw:node-id; description "The identifier of a node in the topology."; } leaf node-id { type te-node-id; description "The identifier of a node in the TE topology."; } leaf hop-type { type te-hop-type; default "strict"; description "Strict or loose hop."; } description "Numbered node route hop."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3, EXPLICIT_ROUTE in RSVP-TE RFC 3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; } } case numbered-link-hop { container numbered-link-hop { leaf link-tp-id { type te-tp-id; mandatory true; description "TE Link Termination Point (LTP) identifier."; } leaf hop-type { type te-hop-type; default "strict"; description "Strict or loose hop."; } leaf direction { type te-link-direction; default "outgoing"; description "Link route object direction."; } description "Numbered link explicit route hop."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3, EXPLICIT_ROUTE in RSVP-TE RFC 3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; } } case unnumbered-link-hop { container unnumbered-link-hop { must "(link-tp-id-uri or link-tp-id) and " + "(node-id-uri or node-id)" { description "At least one node identifier and at least one Link Termination Point (LTP) identifier MUST be present."; } leaf link-tp-id-uri { type nt:tp-id; description "Link Termination Point (LTP) identifier."; } leaf link-tp-id { type te-tp-id; description "TE LTP identifier. The combination of the TE link ID and the TE node ID is used to identify an unnumbered TE link."; } leaf node-id-uri { type nw:node-id; description "The identifier of a node in the topology."; } leaf node-id { type te-node-id; description "The identifier of a node in the TE topology."; } leaf hop-type { type te-hop-type; default "strict"; description "Strict or loose hop."; } leaf direction { type te-link-direction; default "outgoing"; description "Link route object direction."; } description "Unnumbered link explicit route hop."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3, EXPLICIT_ROUTE in RSVP-TE RFC 3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; } } case as-number { container as-number-hop { leaf as-number { type inet:as-number; mandatory true; description "The Autonomous System (AS) number."; } leaf hop-type { type te-hop-type; default "strict"; description "Strict or loose hop."; } description "AS explicit route hop."; } } case label { container label-hop { description "Label hop type."; uses te-label; } description "The label explicit route hop type."; } } } grouping record-route-state { description "The Record Route grouping."; leaf index { type uint32; description "Record Route hop index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } choice type { description "The Record Route entry type."; case numbered-node-hop { container numbered-node-hop { must "node-id-uri or node-id" { description "At least one node identifier MUST be present."; } description "Numbered node route hop container."; leaf node-id-uri { type nw:node-id; description "The identifier of a node in the topology."; } leaf node-id { type te-node-id; description "The identifier of a node in the TE topology."; } leaf-list flags { type path-attribute-flags; description "Path attributes flags."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } } description "Numbered node route hop."; } case numbered-link-hop { container numbered-link-hop { description "Numbered link route hop container."; leaf link-tp-id { type te-tp-id; mandatory true; description "Numbered TE LTP identifier."; } leaf-list flags { type path-attribute-flags; description "Path attributes flags."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } } description "Numbered link route hop."; } case unnumbered-link-hop { container unnumbered-link-hop { must "(link-tp-id-uri or link-tp-id) and " + "(node-id-uri or node-id)" { description "At least one node identifier and at least one Link Termination Point (LTP) identifier MUST be present."; } leaf link-tp-id-uri { type nt:tp-id; description "Link Termination Point (LTP) identifier."; } leaf link-tp-id { type te-tp-id; description "TE LTP identifier. The combination of the TE link ID and the TE node ID is used to identify an unnumbered TE link."; } leaf node-id-uri { type nw:node-id; description "The identifier of a node in the topology."; } leaf node-id { type te-node-id; description "The identifier of a node in the TE topology."; } leaf-list flags { type path-attribute-flags; description "Path attributes flags."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } description "Unnumbered link Record Route hop."; reference "RFC 3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; } description "Unnumbered link route hop."; } case label { container label-hop { description "Label route hop type."; uses te-label; leaf-list flags { type path-attribute-flags; description "Path attributes flags."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } } description "The label Record Route entry types."; } } } grouping label-restriction-info { description "Label set item information."; leaf restriction { type enumeration { enum inclusive { description "The label or label range is inclusive."; } enum exclusive { description "The label or label range is exclusive."; } } default "inclusive"; description "Indicates whether the list item is inclusive or exclusive."; } leaf index { type uint32; description "The index of the label restriction list entry."; } container label-start { must "(not(../label-end/te-label/direction) and" + " not(te-label/direction))" + " or " + "(../label-end/te-label/direction = te-label/direction)" + " or " + "(not(te-label/direction) and" + " (../label-end/te-label/direction = 'forward'))" + " or " + "(not(../label-end/te-label/direction) and" + " (te-label/direction = 'forward'))" { error-message "'label-start' and 'label-end' must have the " + "same direction."; } description "This is the starting label if a label range is specified. This is the label value if a single label is specified, in which case the 'label-end' attribute is not set."; uses te-label; } container label-end { must "(not(../label-start/te-label/direction) and" + " not(te-label/direction))" + " or " + "(../label-start/te-label/direction = te-label/direction)" + " or " + "(not(te-label/direction) and" + " (../label-start/te-label/direction = 'forward'))" + " or " + "(not(../label-start/te-label/direction) and" + " (te-label/direction = 'forward'))" { error-message "'label-start' and 'label-end' must have the " + "same direction."; } description "This is the ending label if a label range is specified. This attribute is not set if a single label is specified."; uses te-label; } container label-step { description "The step increment between labels in the label range. The label start/end values will have to be consistent with the sign of label step. For example, 'label-start' < 'label-end' enforces 'label-step' > 0 'label-start' > 'label-end' enforces 'label-step' < 0."; choice technology { default "generic"; description "Data-plane technology type."; case generic { leaf generic { type int32; default "1"; description "Label range step."; } } } } leaf range-bitmap { type yang:hex-string; description "When there are gaps between 'label-start' and 'label-end', this attribute is used to specify the positions of the used labels. This is represented in big endian as 'hex-string'. The most significant byte in the hex-string is the farthest to the left in the byte sequence. Leading zero bytes in the configured value may be omitted for brevity. Each bit position in the 'range-bitmap' 'hex-string' maps to a label in the range derived from 'label-start'. For example, assuming that 'label-start' = 16000 and 'range-bitmap' = 0x01000001, then: - bit position (0) is set, and the corresponding mapped label from the range is 16000 + (0 * 'label-step') or 16000 for default 'label-step' = 1. - bit position (24) is set, and the corresponding mapped label from the range is 16000 + (24 * 'label-step') or 16024 for default 'label-step' = 1."; } } grouping label-set-info { description "Grouping for the list of label restrictions specifying what labels may or may not be used."; container label-restrictions { description "The label restrictions container."; list label-restriction { key "index"; description "The absence of the label restrictions container implies that all labels are acceptable; otherwise, only restricted labels are available."; reference "RFC 7579: General Network Element Constraint Encoding for GMPLS-Controlled Networks"; uses label-restriction-info; } } } grouping optimization-metric-entry { description "Optimization metrics configuration grouping."; leaf metric-type { type identityref { base path-metric-type; } description "Identifies the 'metric-type' that the path computation process uses for optimization."; } leaf weight { type uint8; default "1"; description "TE path metric normalization weight."; } container explicit-route-exclude-objects { when "../metric-type = " + "'te-types:path-metric-optimize-excludes'"; description "Container for the 'exclude route' object list."; uses path-route-exclude-objects; } container explicit-route-include-objects { when "../metric-type = " + "'te-types:path-metric-optimize-includes'"; description "Container for the 'include route' object list."; uses path-route-include-objects; } } grouping common-constraints { description "Common constraints grouping that can be set on a constraint set or directly on the tunnel."; uses te-bandwidth { description "A requested bandwidth to use for path computation."; } leaf link-protection { type identityref { base link-protection-type; } default "te-types:link-protection-unprotected"; description "Link protection type required for the links included in the computed path."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"; } leaf setup-priority { type uint8 { range "0..7"; } default "7"; description "TE LSP requested setup priority."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } leaf hold-priority { type uint8 { range "0..7"; } default "7"; description "TE LSP requested hold priority."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } leaf signaling-type { type identityref { base path-signaling-type; } default "te-types:path-setup-rsvp"; description "TE tunnel path signaling type."; } } grouping tunnel-constraints { description "Tunnel constraints grouping that can be set on a constraint set or directly on the tunnel."; leaf network-id { type nw:network-id; description "The network topology identifier."; } uses te-topology-identifier; uses common-constraints; } grouping path-constraints-route-objects { description "List of route entries to be included or excluded when performing the path computation."; // CHANGE NOTE: The explicit-route-objects container below has // been updated in this module revision // RFC Editor: remove the note above and this note container explicit-route-objects { description "Container for the explicit route object lists."; list route-object-exclude-always { key "index"; ordered-by user; description "List of route objects to always exclude from the path computation."; leaf index { type uint32; description "Explicit Route Object index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } uses explicit-route-hop; } list route-object-include-exclude { key "index"; ordered-by user; description "List of route objects to include or exclude in the path computation."; leaf explicit-route-usage { type identityref { base route-usage-type; } default "te-types:route-include-object"; description "Indicates whether to include or exclude the route object. The default is to include it."; } leaf index { type uint32; description "Route object include-exclude index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } uses explicit-route-hop { augment "type" { case srlg { container srlg { description "SRLG container."; leaf srlg { type uint32; description "SRLG value."; } } description "An SRLG value to be included or excluded."; } description "Augmentation for a generic explicit route for SRLG exclusion."; } } } } } grouping path-route-include-objects { description "List of route objects to be included when performing the path computation."; list route-object-include-object { key "index"; ordered-by user; description "List of Explicit Route Objects to be included in the path computation."; leaf index { type uint32; description "Route object entry index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } uses explicit-route-hop; } } grouping path-route-exclude-objects { description "List of route objects to be excluded when performing the path computation."; list route-object-exclude-object { key "index"; ordered-by user; description "List of Explicit Route Objects to be excluded in the path computation."; leaf index { type uint32; description "Route object entry index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } uses explicit-route-hop { augment "type" { case srlg { container srlg { description "SRLG container."; leaf srlg { type uint32; description "SRLG value."; } } description "An SRLG value to be included or excluded."; } description "Augmentation for a generic explicit route for SRLG exclusion."; } } } } grouping generic-path-metric-bounds { description "TE path metric bounds grouping."; container path-metric-bounds { description "TE path metric bounds container."; list path-metric-bound { key "metric-type"; description "List of TE path metric bounds."; leaf metric-type { type identityref { base path-metric-type; } description "Identifies an entry in the list of 'metric-type' items bound for the TE path."; } leaf upper-bound { type uint64; default "0"; description "Upper bound on the end-to-end TE path metric. A zero indicates an unbounded upper limit for the specific 'metric-type'. The unit of is interpreted in the context of the path-metric-type."; } } } } grouping generic-path-optimization { description "TE generic path optimization grouping."; container optimizations { description "The objective function container that includes attributes to impose when computing a TE path."; choice algorithm { description "Optimizations algorithm."; case metric { if-feature "path-optimization-metric"; /* Optimize by metric */ list optimization-metric { key "metric-type"; description "TE path metric type."; uses optimization-metric-entry; } /* Tiebreakers */ container tiebreakers { description "Container for the list of tiebreakers."; list tiebreaker { key "tiebreaker-type"; description "The list of tiebreaker criteria to apply on an equally favored set of paths, in order to pick the best."; leaf tiebreaker-type { type identityref { base path-metric-type; } description "Identifies an entry in the list of tiebreakers."; } } } } case objective-function { if-feature "path-optimization-objective-function"; /* Objective functions */ container objective-function { description "The objective function container that includes attributes to impose when computing a TE path."; leaf objective-function-type { type identityref { base objective-function-type; } default "te-types:of-minimize-cost-path"; description "Objective function entry."; } } } } } } grouping generic-path-affinities { description "Path affinities grouping."; container path-affinities-values { description "Path affinities represented as values."; list path-affinities-value { key "usage"; description "List of named affinity constraints."; leaf usage { type identityref { base resource-affinities-type; } description "Identifies an entry in the list of value affinity constraints."; } leaf value { type admin-groups; default ""; description "The affinity value. The default is empty."; } } } container path-affinity-names { description "Path affinities represented as names."; list path-affinity-name { key "usage"; description "List of named affinity constraints."; leaf usage { type identityref { base resource-affinities-type; } description "Identifies an entry in the list of named affinity constraints."; } list affinity-name { key "name"; leaf name { type string; description "Identifies a named affinity entry."; } description "List of named affinities."; } } } } grouping generic-path-srlgs { description "Path SRLG grouping."; container path-srlgs-lists { description "Path SRLG properties container."; list path-srlgs-list { key "usage"; description "List of SRLG values to be included or excluded."; leaf usage { type identityref { base route-usage-type; } description "Identifies an entry in a list of SRLGs to either include or exclude."; } leaf-list values { type srlg; description "List of SRLG values."; } } } container path-srlgs-names { description "Container for the list of named SRLGs."; list path-srlgs-name { key "usage"; description "List of named SRLGs to be included or excluded."; leaf usage { type identityref { base route-usage-type; } description "Identifies an entry in a list of named SRLGs to either include or exclude."; } leaf-list names { type string; description "List of named SRLGs."; } } } } grouping generic-path-disjointness { description "Path disjointness grouping."; leaf disjointness { type te-path-disjointness; description "The type of resource disjointness. When configured for a primary path, the disjointness level applies to all secondary LSPs. When configured for a secondary path, the disjointness level overrides the level configured for the primary path."; } } grouping common-path-constraints-attributes { description "Common path constraints configuration grouping."; uses common-constraints; uses generic-path-metric-bounds; uses generic-path-affinities; uses generic-path-srlgs; } grouping generic-path-constraints { description "Global named path constraints configuration grouping."; container path-constraints { description "TE named path constraints container."; uses common-path-constraints-attributes; uses generic-path-disjointness; } } grouping generic-path-properties { description "TE generic path properties grouping."; container path-properties { config false; description "The TE path properties."; list path-metric { key "metric-type"; description "TE path metric type."; leaf metric-type { type identityref { base path-metric-type; } description "TE path metric type."; } leaf accumulative-value { type uint64; description "TE path metric accumulative value."; } } uses generic-path-affinities; uses generic-path-srlgs; container path-route-objects { description "Container for the list of route objects either returned by the computation engine or actually used by an LSP."; list path-route-object { key "index"; ordered-by user; description "List of route objects either returned by the computation engine or actually used by an LSP."; leaf index { type uint32; description "Route object entry index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } uses explicit-route-hop; } } } } // NOTE: The grouping encoding-and-switching-type below has been // added in this module revision // RFC Editor: remove the note above and this note grouping encoding-and-switching-type { description "Common grouping to define the LSP encoding and switching types"; leaf encoding { type identityref { base te-types:lsp-encoding-types; } description "LSP encoding type."; reference "RFC3945"; } leaf switching-type { type identityref { base te-types:switching-capabilities; } description "LSP switching type."; reference "RFC3945"; } } // CHANGE NOTE: The typedef te-gen-node-id below has been // added in this module revision // RFC Editor: remove the note above and this note grouping te-generic-node-id { description "A reusable grouping for a TE generic node identifier."; leaf id { type te-gen-node-id; description "The identifier of the node. Can be represented as IP address or dotted quad address or as an URI."; } leaf type { type enumeration { enum ip { description "IP address representation of the node identifier."; } enum te-id { description "TE identifier of the node"; } enum node-id { description "URI representation of the node identifier."; } } description "Type of node identifier representation."; } } } ]]>

Packet TE Types YANG Module The "ietf-te-packet-types" module imports from the "ietf-te-types" module defined in of this document. CHANGE NOTE: Please focus your review only on the updates to the YANG model: see also . RFC Editor: remove the CHANGE NOTE above and this note

WG List: Editor: Tarek Saad Editor: Rakesh Gandhi Editor: Vishnu Pavan Beeram Editor: Xufeng Liu Editor: Igor Bryskin "; description "This YANG module contains a collection of generally useful YANG data type definitions specific to Packet Traffic Enginnering (TE). The model fully conforms to the Network Management Datastore Architecture (NMDA). 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2024 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 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2024-01-25 { description "Added common TE packet identities: - bandwidth-profile-type; - path-metric-loss; - path-metric-delay-variation. Added common TE packet groupings: - te-packet-path-bandwidth; - te-packet-link-bandwidth. Updated module description."; reference "RFC XXXX: Common YANG Data Types for Traffic Engineering"; } // RFC Editor: replace XXXX with actual RFC number, update date // information and remove this note revision 2020-06-10 { description "Latest revision of TE MPLS types."; reference "RFC 8776: Common YANG Data Types for Traffic Engineering"; } /* * Identities */ // CHANGE NOTE: The base identity bandwidth-profile-type and // its derived identities below have been // added in this module revision // RFC Editor: remove the note above and this note identity bandwidth-profile-type { description "Bandwidth Profile Types"; } identity mef-10-bwp { base bandwidth-profile-type; description "MEF 10 Bandwidth Profile"; reference "MEF 10.3: Ethernet Services Attributes Phase 3"; } identity rfc-2697-bwp { base bandwidth-profile-type; description "RFC 2697 Bandwidth Profile"; reference "RFC2697: A Single Rate Three Color Marker"; } identity rfc-2698-bwp { base bandwidth-profile-type; description "RFC 2698 Bandwidth Profile"; reference "RFC2698: A Two Rate Three Color Marker"; } identity rfc-4115-bwp { base bandwidth-profile-type; description "RFC 4115 Bandwidth Profile"; reference "RFC4115: A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic"; } // CHANGE NOTE: The identity path-metric-loss below has // been added in this module revision // RFC Editor: remove the note above and this note identity path-metric-loss { base te-types:path-metric-type; description "The path loss (as a packet percentage) metric type encodes a function of the unidirectional loss metrics of all links traversed by a P2P path. The basic unit is 0.000003%, where (2^24 - 2) or 50.331642% is the maximum value of the path loss percentage that can be expressed. Values that are larger than the maximum value SHOULD be encoded as the maximum value."; reference "RFC8233: Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs); RFC7471: OSPF Traffic Engineering (TE) Metric Extensions; RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions."; } // CHANGE NOTE: The identity path-metric-delay-variation below has // been added in this module revision // RFC Editor: remove the note above and this note identity path-metric-delay-variation { base te-types:path-metric-type; description "The path delay variation encodes the sum of the unidirectional delay variation metrics of all links traversed by a P2P path. The path delay variation metric unit is in microseconds, where (2^24 - 1) or 16,777,215 microseconds (16.777215 sec) is the maximum value of the path delay variation that can be expressed. Values that are larger than the maximum value SHOULD be encoded as the maximum value."; reference "RFC8233: Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs); RFC7471: OSPF Traffic Engineering (TE) Metric Extensions; RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions."; } /* * Typedefs */ typedef te-bandwidth-requested-type { type enumeration { enum specified { description "Bandwidth is explicitly specified."; } enum auto { description "Bandwidth is automatically computed."; } } description "Enumerated type for specifying whether bandwidth is explicitly specified or automatically computed."; } typedef te-class-type { type uint8; description "Diffserv-TE Class-Type. Defines a set of Traffic Trunks crossing a link that is governed by a specific set of bandwidth constraints. Class-Type is used for the purposes of link bandwidth allocation, constraint-based routing, and admission control."; reference "RFC 4124: Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering"; } typedef bc-type { type uint8 { range "0..7"; } description "Diffserv-TE bandwidth constraints as defined in RFC 4124."; reference "RFC 4124: Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering"; } typedef bandwidth-kbps { type uint64; units "Kbps"; description "Bandwidth values, expressed in kilobits per second."; } typedef bandwidth-mbps { type uint64; units "Mbps"; description "Bandwidth values, expressed in megabits per second."; } typedef bandwidth-gbps { type uint64; units "Gbps"; description "Bandwidth values, expressed in gigabits per second."; } identity backup-protection-type { description "Base identity for the backup protection type."; } identity backup-protection-link { base backup-protection-type; description "Backup provides link protection only."; } identity backup-protection-node-link { base backup-protection-type; description "Backup offers node (preferred) or link protection."; } identity bc-model-type { description "Base identity for the Diffserv-TE Bandwidth Constraints Model type."; reference "RFC 4124: Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering"; } identity bc-model-rdm { base bc-model-type; description "Russian Dolls Bandwidth Constraints Model type."; reference "RFC 4127: Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering"; } identity bc-model-mam { base bc-model-type; description "Maximum Allocation Bandwidth Constraints Model type."; reference "RFC 4125: Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering"; } identity bc-model-mar { base bc-model-type; description "Maximum Allocation with Reservation Bandwidth Constraints Model type."; reference "RFC 4126: Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons"; } /* * Groupings */ grouping performance-metrics-attributes-packet { description "Contains PM attributes."; uses te-types:performance-metrics-attributes { augment "performance-metrics-one-way" { leaf one-way-min-delay { type uint32 { range "0..16777215"; } description "One-way minimum delay or latency in microseconds."; } leaf one-way-min-delay-normality { type te-types:performance-metrics-normality; default "normal"; description "One-way minimum delay or latency normality."; } leaf one-way-max-delay { type uint32 { range "0..16777215"; } description "One-way maximum delay or latency in microseconds."; } leaf one-way-max-delay-normality { type te-types:performance-metrics-normality; default "normal"; description "One-way maximum delay or latency normality."; } leaf one-way-delay-variation { type uint32 { range "0..16777215"; } description "One-way delay variation in microseconds."; reference "RFC 5481: Packet Delay Variation Applicability Statement, Section 4.2"; } leaf one-way-delay-variation-normality { type te-types:performance-metrics-normality; default "normal"; description "One-way delay variation normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } leaf one-way-packet-loss { type decimal64 { fraction-digits 6; range "0..50.331642"; } description "One-way packet loss as a percentage of the total traffic sent over a configurable interval. The finest precision is 0.000003%, where the maximum is 50.331642%."; reference "RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 4.4"; } leaf one-way-packet-loss-normality { type te-types:performance-metrics-normality; default "normal"; description "Packet loss normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } description "PM one-way packet-specific augmentation for a generic PM grouping."; } augment "performance-metrics-two-way" { leaf two-way-min-delay { type uint32 { range "0..16777215"; } default "0"; description "Two-way minimum delay or latency in microseconds."; } leaf two-way-min-delay-normality { type te-types:performance-metrics-normality; default "normal"; description "Two-way minimum delay or latency normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } leaf two-way-max-delay { type uint32 { range "0..16777215"; } default "0"; description "Two-way maximum delay or latency in microseconds."; } leaf two-way-max-delay-normality { type te-types:performance-metrics-normality; default "normal"; description "Two-way maximum delay or latency normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } leaf two-way-delay-variation { type uint32 { range "0..16777215"; } default "0"; description "Two-way delay variation in microseconds."; reference "RFC 5481: Packet Delay Variation Applicability Statement, Section 4.2"; } leaf two-way-delay-variation-normality { type te-types:performance-metrics-normality; default "normal"; description "Two-way delay variation normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } leaf two-way-packet-loss { type decimal64 { fraction-digits 6; range "0..50.331642"; } default "0"; description "Two-way packet loss as a percentage of the total traffic sent over a configurable interval. The finest precision is 0.000003%."; } leaf two-way-packet-loss-normality { type te-types:performance-metrics-normality; default "normal"; description "Two-way packet loss normality."; } description "PM two-way packet-specific augmentation for a generic PM grouping."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } } } grouping one-way-performance-metrics-packet { description "One-way packet PM throttle grouping."; leaf one-way-min-delay { type uint32 { range "0..16777215"; } default "0"; description "One-way minimum delay or latency in microseconds."; } leaf one-way-max-delay { type uint32 { range "0..16777215"; } default "0"; description "One-way maximum delay or latency in microseconds."; } leaf one-way-delay-variation { type uint32 { range "0..16777215"; } default "0"; description "One-way delay variation in microseconds."; } leaf one-way-packet-loss { type decimal64 { fraction-digits 6; range "0..50.331642"; } default "0"; description "One-way packet loss as a percentage of the total traffic sent over a configurable interval. The finest precision is 0.000003%."; } } grouping two-way-performance-metrics-packet { description "Two-way packet PM throttle grouping."; leaf two-way-min-delay { type uint32 { range "0..16777215"; } default "0"; description "Two-way minimum delay or latency in microseconds."; } leaf two-way-max-delay { type uint32 { range "0..16777215"; } default "0"; description "Two-way maximum delay or latency in microseconds."; } leaf two-way-delay-variation { type uint32 { range "0..16777215"; } default "0"; description "Two-way delay variation in microseconds."; } leaf two-way-packet-loss { type decimal64 { fraction-digits 6; range "0..50.331642"; } default "0"; description "Two-way packet loss as a percentage of the total traffic sent over a configurable interval. The finest precision is 0.000003%."; } } grouping performance-metrics-throttle-container-packet { description "Packet PM threshold grouping."; uses te-types:performance-metrics-throttle-container { augment "throttle/threshold-out" { uses one-way-performance-metrics-packet; uses two-way-performance-metrics-packet; description "PM threshold-out packet augmentation for a generic grouping."; } augment "throttle/threshold-in" { uses one-way-performance-metrics-packet; uses two-way-performance-metrics-packet; description "PM threshold-in packet augmentation for a generic grouping."; } augment "throttle/threshold-accelerated-advertisement" { uses one-way-performance-metrics-packet; uses two-way-performance-metrics-packet; description "PM accelerated advertisement packet augmentation for a generic grouping."; } } } // CHANGE NOTE: The te-packet-path-bandwidth below has been // added in this module revision // RFC Editor: remove the note above and this note grouping te-packet-path-bandwidth { description "Path bandwidth for Packet. "; leaf bandwidth-profile-name { type string; description "Name of Bandwidth Profile."; } leaf bandwidth-profile-type { type identityref { base bandwidth-profile-type; } description "Type of Bandwidth Profile."; } leaf cir { type uint64; units "bits/second"; mandatory true; description "Committed Information Rate (CIR)."; } leaf cbs { type uint64; units "bits/second"; mandatory true; description "Committed Burst Size (CBS)."; } leaf eir { type uint64; units "bits/second"; description "Excess Information Rate (EIR)."; } leaf ebs { type uint64; units "bytes"; description "Excess Burst Size (EBS)."; } leaf pir { type uint64; units "bits/second"; description "Peak Information Rate (PIR)."; } leaf pbs { type uint64; units "bytes"; description "Peak Burst Size (PBS)."; } } // CHANGE NOTE: The te-packet-path-bandwidth below has been // added in this module revision // RFC Editor: remove the note above and this note grouping te-packet-link-bandwidth { description "Link Bandwidth for Packet. "; leaf packet-bandwidth { type uint64; units "bits/second"; description "Available bandwith value."; } } } ]]>

IANA Considerations For the following URIs in the "IETF XML Registry" , IANA has updated the reference field to refer to this document:

This document also adds updated YANG modules to the "YANG Module Names" registry :

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

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 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 Network Configuration Access Control Model (NACM) 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 YANG module in this document defines common TE type definitions (e.g., typedef, identity, and grouping statements) in YANG data modeling language to be imported and used by other TE modules. When imported and used, the resultant schema will have data nodes that can be writable or readable. Access to such data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. The security considerations spelled out in the YANG 1.1 specification apply for this document as well.

ITU-T Recommendation G.808.1 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] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). 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 defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities. 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. This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. 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 introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other. The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.). In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE. This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation. This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK] This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains. This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures. The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK] Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK] The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK] Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs. This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. This document obsoletes RFC 6006. This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. 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. MEF International Telecommunication Union Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. Huawei Technologies Nokia Telefonica Google China Unicom There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. Alef Edge Individual Juniper Networks Cisco Systems Inc Ciena Telefonica This document defines a YANG data model for layer 3 traffic engineering topologies. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810. In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections. This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering. These extensions address the requirements for DS-TE spelled out in RFC 3564. [STANDARDS-TRACK] This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions. 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. [STANDARDS-TRACK] The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and Virtual Private Network (VPN) auto-discovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. [STANDARDS-TRACK] This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK] This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK] This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK] MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305). This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications 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 addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK] This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK] This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. This memo provides information for the Internet community. This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. [STANDARDS-TRACK] In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK] Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS-TRACK] RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop. This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK] This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. [STANDARDS-TRACK] In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs). This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK] There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK] Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK] Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling. This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP). The reoptimization of a Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point-to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list. This document specifies a new Generic Associated Channel (G-ACh) for Residence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain. Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a Precision Time Protocol event message. The RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK] This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK] This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK] This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation. IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation. Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS-TRACK] This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. This memo defines an Experimental Protocol for the Internet community. This document complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. This memo defines an Experimental Protocol for the Internet community. This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. This memo defines an Experimental Protocol for the Internet community. This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community. This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community. This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community. 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 memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. This memo provides information for the Internet community. This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK] This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. [STANDARDS-TRACK] In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. [STANDARDS-TRACK] The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community. There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. [STANDARDS-TRACK] ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility. This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex. This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case. This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane. Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. 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. This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342). This document updates "YANG Data Model for Bidirectional Forwarding Detection (BFD)" (RFC 9127).

Changes from RFC 8776 To be added in a future revision of this draft.

TE Types YANG Diffs RFC Editor: please remove this appendix before publication. This section provides the diff between the YANG module in section 3.1 of and the YANG model revision in . The intention of this appendix is to facilitate focusing the review of the YANG model in to the changes compared with the YANG model in . This diff has been generated using the following UNIX commands to compare the YANG module revisions in section 3.1 of and in :

model-diff.txt sed 's/^/ /' model-diff.txt > model-diff-spaces.txt sed 's/^ > / > /' model-diff-spaces.txt > model-updates.txt ]]>

The output (model-updates.txt) is reported here:

import ietf-network { > prefix "nw"; > reference "RFC 8345: A YANG Data Model for Network Topologies"; > } > > import ietf-network-topology { > prefix "nt"; > reference "RFC 8345: A YANG Data Model for Network Topologies"; > } > 30c40 < --- > 55c65 < Copyright (c) 2020 IETF Trust and the persons identified as --- > Copyright (c) 2024 IETF Trust and the persons identified as 60c70 < the license terms contained in, the Simplified BSD License set --- > the license terms contained in, the Revised BSD License set 65,66c75,113 < This version of this YANG module is part of RFC 8776; see the < RFC itself for full legal notices."; --- > This version of this YANG module is part of RFC XXXX > (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself > for full legal notices."; > revision 2024-01-29 { > description > "Added: > - base identity lsp-provisioning-error-reason; > - identity association-type-diversity; > - identity tunnel-admin-state-auto; > - identity lsp-restoration-restore-none; > - identity restoration-scheme-rerouting; > - base identity path-computation-error-reason and > its derived identities; > - base identity protocol-origin-type and > its derived identities; > - base identity svec-objective-function-type and its derived > identities; > - base identity svec-metric-type and its derived identities; > - grouping encoding-and-switching-type. > > Updated: > - description of the base identity objective-function-type; > - description and reference of identity action-exercise; > - typedef te-node-id to support also 16 octects TE identifiers. > > Obsoleted: > - identity of-minimize-agg-bandwidth-consumption; > - identity of-minimize-load-most-loaded-link; > - identity of-minimize-cost-path-set; > - identity lsp-protection-reroute-extra; > - identity lsp-protection-reroute. > > Container explicit-route-objects-always renamed as > explicit-route-objects."; > reference > "RFC XXXX: Common YANG Data Types for Traffic Engineering"; > } > // RFC Editor: replace XXXX with actual RFC number, update date > // information and remove this note 351a399,401 > // CHANGE NOTE: The typedef te-node-id below has been > // updated in this module revision > // RFC Editor: remove the note above and this note 353c403,406 < type yang:dotted-quad; --- > type union { > type yang:dotted-quad; > type inet:ipv6-address-no-zone; > } 357,358c410,414 < The identifier is represented as 4 octets in dotted-quad < notation. --- > > The identifier is represented either as 4 octets in > dotted-quad notation or 16 octets in full, mixed, shortened, > or shortened-mixed IPv6 address notation. > 362,363c418,421 < Router ID TLV described in Section 4.3 of RFC 5305, or the < TE Router ID TLV described in Section 3.2.1 of RFC 6119. --- > Router ID TLV described in Section 4.3 of RFC 5305, the TE > Router ID TLV described in Section 3.2.1 of RFC 6119, or the > IPv6 TE Router ID TLV described in Section 4.1 of RFC 6119. > 368a427 > 370a430 > 371a432 > 545a607,647 > // CHANGE NOTE: The typedef path-type below has been > // added in this module revision > // RFC Editor: remove the note above and this note > typedef path-type { > type enumeration { > enum primary-path { > description > "Indicates that the TE path is a primary path."; > } > enum secondary-path { > description > "Indicates that the TE path is a secondary path."; > } > enum primary-reverse-path { > description > "Indicates that the TE path is a primary reverse path."; > } > enum secondary-reverse-path { > description > "Indicates that the TE path is a secondary reverse path."; > } > } > description > "The type of TE path, indicating whether a path is a primary, > or a reverse primary, or a secondary, or a reverse secondary > path."; > } > > // CHANGE NOTE: The typedef te-gen-node-id below has been > // added in this module revision > // RFC Editor: remove the note above and this note > typedef te-gen-node-id { > type union { > type te-node-id; > type inet:ip-address; > type nw:node-id; > } > description > "Generic type that identifies a node in a TE topology."; > } > 606a709,716 > // CHANGE NOTE: The base identity lsp-provisioning-error-reason > // has been added in this module revision > // RFC Editor: remove the note above and this note > identity lsp-provisioning-error-reason { > description > "Base identity for LSP provisioning errors."; > } > 982a1093,1110 > // CHANGE NOTE: The identity association-type-diversity below has > // been added in this module revision > // RFC Editor: remove the note above and this note > identity association-type-diversity { > base association-type; > description > "Association Type diversity used to associate LSPs whose > paths are to be diverse from each other."; > reference > "RFC8800: Path Computation Element Communication Protocol > (PCEP) Extension for Label Switched Path (LSP) Diversity > Constraint Signaling"; > } > > // CHANGE NOTE: The description of the base identity > // objective-function-type has been updated > // in this module revision > // RFC Editor: remove the note above and this note 985c1113 < "Base objective function type."; --- > "Base identity for path objective function type."; 1015a1144,1146 > // CHANGE NOTE: The identity of-minimize-agg-bandwidth-consumption > // below has been obsoleted in this module revision > // RFC Editor: remove the note above and this note 1017a1149 > status obsolete; 1020c1152 < consumption."; --- > consumption."; 1023c1155 < Computation Element Communication Protocol (PCEP)"; --- > Computation Element Communication Protocol (PCEP)"; 1025a1158,1160 > // CHANGE NOTE: The identity of-minimize-load-most-loaded-link > // below has been obsoleted in this module revision > // RFC Editor: remove the note above and this note 1027a1163 > status obsolete; 1030c1166 < is carrying the highest load."; --- > is carrying the highest load."; 1033c1169 < Computation Element Communication Protocol (PCEP)"; --- > Computation Element Communication Protocol (PCEP)"; 1035a1172,1174 > // CHANGE NOTE: The identity of-minimize-cost-path-set > // below has been obsoleted in this module revision > // RFC Editor: remove the note above and this note 1037a1177 > status obsolete; 1216a1357,1368 > // CHANGE NOTE: The identity tunnel-admin-state-auto below > // has been added in this module revision > // RFC Editor: remove the note above and this note > identity tunnel-admin-state-auto { > base tunnel-admin-state-type; > description > "Tunnel administrative auto state. The administrative status > in state datastore transitions to 'tunnel-admin-up' when the > tunnel used by the client layer, and to 'tunnel-admin-down' > when it is not used by the client layer."; > } > 1321a1474,1482 > // CHANGE NOTE: The identity lsp-restoration-restore-none > // below has been added in this module revision > // RFC Editor: remove the note above and this note > identity lsp-restoration-restore-none { > base lsp-restoration-type; > description > "No LSP affected by a failure is restored."; > } > 1339a1501,1515 > // CHANGE NOTE: The identity restoration-scheme-rerouting > // below has been added in this module revision > // RFC Editor: remove the note above and this note > identity restoration-scheme-rerouting { > base restoration-scheme-type; > description > "Restoration LSP is computed after the failure detection. > > This restoration scheme is also known as > 'Full LSP Re-routing.'"; > reference > "RFC 4427: Recovery (Protection and Restoration) Terminology > for Generalized Multi-Protocol Label Switching (GMPLS)"; > } > 1383a1560,1562 > // CHANGE NOTE: The identity lsp-protection-reroute-extra > // below has been obsoleted in this module revision > // RFC Editor: remove the note above and this note 1385a1565 > status obsolete; 1387c1567,1571 < "'(Full) Rerouting' LSP protection type."; --- > "'(Full) Rerouting' LSP protection type. > > This identity has been obsoleted: the > 'restoration-scheme-rerouting' identity SHOULD be used > instead."; 1392a1577,1579 > // CHANGE NOTE: The identity lsp-protection-reroute > // below has been obsoleted in this module revision > // RFC Editor: remove the note above and this note 1394a1582 > status obsolete; 1396c1584,1588 < "'Rerouting without Extra-Traffic' LSP protection type."; --- > "'Rerouting without Extra-Traffic' LSP protection type. > > This identity has been obsoleted: the > 'restoration-scheme-rerouting' identity SHOULD be used > instead."; 1628a1821,1824 > // CHANGE NOTE: The description and reference of the > // identity action-exercise have been updated in this module > // revision > // RFC Editor: remove the note above and this note 1632,1633c1828,1830 < "An action that starts testing whether or not APS communication < is operating correctly. It is of lower priority than any --- > "An action that starts testing whether or not Automatic > Protection Switching (APS) communication is operating > correctly. It is of lower priority than any 1636,1637c1833,1834 < "RFC 4427: Recovery (Protection and Restoration) Terminology < for Generalized Multi-Protocol Label Switching (GMPLS)"; --- > "ITU-T G.808.1 v4.0 (05/2014): Generic protection switching - > Linear trail and subnetwork protection"; 1916a2114,2116 > // CHANGE NOTE: The description of the identity path-metric-type > // has been updated in this module revision > // RFC Editor: remove the note above and this note 1919c2119,2122 < "Base identity for the path metric type."; --- > "Base identity for the path metric type. > > Derived identities SHOULD describe the unit and maximum value > of the path metric types they define."; 1939a2143,2145 > // CHANGE NOTE: The reference for the identity path-metric-hop > // has been added in this module revision > // RFC Editor: remove the note above and this note 1943a2150,2152 > reference > "RFC5440: Path Computation Element (PCE) Communication > Protocol (PCEP)"; 1945a2155 > 2110a2321,2724 > // CHANGE NOTE: The base identity path-computation-error-reason > // and its derived identities below have been > // added in this module revision > // RFC Editor: remove the note above and this note > identity path-computation-error-reason { > description > "Base identity for path computation error reasons."; > } > > identity path-computation-error-path-not-found { > base path-computation-error-reason; > description > "Path computation has failed because of an unspecified > reason."; > reference > "Section 7.5 of RFC5440: Path Computation Element (PCE) > Communication Protocol (PCEP)"; > } > > identity path-computation-error-no-topology { > base path-computation-error-reason; > description > "Path computation has failed because there is no topology > with the provided topology-identifier."; > } > > identity path-computation-error-no-dependent-server { > base path-computation-error-reason; > description > "Path computation has failed because one or more dependent > path computation servers are unavailable. > > The dependent path computation server could be > a Backward-Recursive Path Computation (BRPC) downstream > PCE or a child PCE."; > reference > "RFC5441, RFC8685"; > } > > identity path-computation-error-pce-unavailable { > base path-computation-error-reason; > description > "Path computation has failed because PCE is not available. > > It corresponds to bit 31 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC5440: Path Computation Element (PCE) Communication > Protocol (PCEP); > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-no-inclusion-hop { > base path-computation-error-reason; > description > "Path computation has failed because there is no > node or link provided by one or more inclusion hops."; > } > > identity path-computation-error-destination-unknown-in-domain { > base path-computation-error-reason; > description > "Path computation has failed because the destination node is > unknown in indicated destination domain. > > It corresponds to bit 19 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC8685; > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-no-resource { > base path-computation-error-reason; > description > "Path computation has failed because there is no > available resource in one or more domains. > > It corresponds to bit 20 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC8685; > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-child-pce-unresponsive { > base path-computation-error-no-dependent-server; > description > "Path computation has failed because child PCE is not > responsive. > > It corresponds to bit 21 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC8685; > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-destination-domain-unknown { > base path-computation-error-reason; > description > "Path computation has failed because the destination domain > was unknown. > > It corresponds to bit 22 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC8685; > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-p2mp { > base path-computation-error-reason; > description > "Path computation has failed because of P2MP reachability > problem. > > It corresponds to bit 24 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC8306; > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-no-gco-migration { > base path-computation-error-reason; > description > "Path computation has failed because of no Global Concurrent > Optimization (GCO) migration path found. > > It corresponds to bit 26 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC5557; > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-no-gco-solution { > base path-computation-error-reason; > description > "Path computation has failed because of no GCO solution > found. > > It corresponds to bit 25 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC5557; > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-pks-expansion { > base path-computation-error-reason; > description > "Path computation has failed because of Path-Key Subobject > (PKS) expansion failure. > > It corresponds to bit 27 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC5520; > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-brpc-chain-unavailable { > base path-computation-error-no-dependent-server; > description > "Path computation has failed because PCE BRPC chain > unavailable. > > It corresponds to bit 28 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC5441; > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-source-unknown { > base path-computation-error-reason; > description > "Path computation has failed because source node is > unknown. > > It corresponds to bit 29 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC5440: Path Computation Element (PCE) Communication > Protocol (PCEP); > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-destination-unknown { > base path-computation-error-reason; > description > "Path computation has failed because destination node is > unknown. > > It corresponds to bit 30 of the Flags field of the > NO-PATH-VECTOR TLV."; > reference > "RFC5440: Path Computation Element (PCE) Communication > Protocol (PCEP); > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > identity path-computation-error-no-server { > base path-computation-error-reason; > description > "Path computation has failed because path computation > server is unavailable."; > reference > "RFC5440: Path Computation Element (PCE) Communication > Protocol (PCEP); > > https://www.iana.org/assignments/pcep/pcep.xhtml"; > } > > // CHANGE NOTE: The base identity protocol-origin-type and > // its derived identities below have been > // added in this module revision > // RFC Editor: remove the note above and this note > identity protocol-origin-type { > description > "Base identity for protocol origin type."; > } > > identity protocol-origin-api { > base protocol-origin-type; > description > "Protocol origin is via Application Programmable Interface > (API)."; > } > > identity protocol-origin-pcep { > base protocol-origin-type; > description > "Protocol origin is Path Computation Engine Protocol > (PCEP)."; > reference > "RFC5440: Path Computation Element (PCE) Communication > Protocol (PCEP)"; > } > > identity protocol-origin-bgp { > base protocol-origin-type; > description > "Protocol origin is Border Gateway Protocol (BGP)."; > reference "RFC9012"; > } > > // CHANGE NOTE: The base identity svec-objective-function-type > // and its derived identities below have been > // added in this module revision > // RFC Editor: remove the note above and this note > identity svec-objective-function-type { > description > "Base identity for SVEC objective function type."; > reference > "RFC5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)."; > } > > identity svec-of-minimize-agg-bandwidth-consumption { > base svec-objective-function-type; > description > "Objective function for minimizing aggregate bandwidth > consumption (MBC)."; > reference > "RFC5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)."; > } > > identity svec-of-minimize-load-most-loaded-link { > base svec-objective-function-type; > description > "Objective function for minimizing the load on the link that > is carrying the highest load (MLL)."; > reference > "RFC5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)."; > } > > identity svec-of-minimize-cost-path-set { > base svec-objective-function-type; > description > "Objective function for minimizing the cost on a path set > (MCC)."; > reference > "RFC5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)."; > } > > identity svec-of-minimize-common-transit-domain { > base svec-objective-function-type; > description > "Objective function for minimizing the number of common > transit domains (MCTD)."; > reference > "RFC8685: Path Computation Element Communication Protocol > (PCEP) Extensions for the Hierarchical Path Computation > Element (H-PCE) Architecture."; > } > > identity svec-of-minimize-shared-link { > base svec-objective-function-type; > description > "Objective function for minimizing the number of shared > links (MSL)."; > reference > "RFC8685: Path Computation Element Communication Protocol > (PCEP) Extensions for the Hierarchical Path Computation > Element (H-PCE) Architecture."; > } > > identity svec-of-minimize-shared-srlg { > base svec-objective-function-type; > description > "Objective function for minimizing the number of shared > Shared Risk Link Groups (SRLG) (MSS)."; > reference > "RFC8685: Path Computation Element Communication Protocol > (PCEP) Extensions for the Hierarchical Path Computation > Element (H-PCE) Architecture."; > } > > identity svec-of-minimize-shared-nodes { > base svec-objective-function-type; > description > "Objective function for minimizing the number of shared > nodes (MSN)."; > reference > "RFC8685: Path Computation Element Communication Protocol > (PCEP) Extensions for the Hierarchical Path Computation > Element (H-PCE) Architecture."; > } > > // CHANGE NOTE: The base identity svec-metric-type and > // its derived identities below have been > // added in this module revision > // RFC Editor: remove the note above and this note > identity svec-metric-type { > description > "Base identity for SVEC metric type."; > reference > "RFC5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)."; > } > > identity svec-metric-cumul-te { > base svec-metric-type; > description > "Cumulative TE cost."; > reference > "RFC5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)."; > } > > identity svec-metric-cumul-igp { > base svec-metric-type; > description > "Cumulative IGP cost."; > reference > "RFC5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)."; > } > > identity svec-metric-cumul-hop { > base svec-metric-type; > description > "Cumulative Hop path metric."; > reference > "RFC5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)."; > } > > identity svec-metric-aggregate-bandwidth-consumption { > base svec-metric-type; > description > "Aggregate bandwidth consumption."; > reference > "RFC5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)."; > } > > identity svec-metric-load-of-the-most-loaded-link { > base svec-metric-type; > description > "Load of the most loaded link."; > reference > "RFC5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)."; > } > 2506a3121,3123 > // CHANGE NOTE: The explicit-route-hop grouping below has been > // updated in this module revision > // RFC Editor: remove the note above and this note 2514a3132,3140 > must "node-id-uri or node-id" { > description > "At least one node identifier MUST be present."; > } > leaf node-id-uri { > type nw:node-id; > description > "The identifier of a node in the topology."; > } 2517d3142 < mandatory true; 2566a3192,3202 > must "(link-tp-id-uri or link-tp-id) and " + > "(node-id-uri or node-id)" { > description > "At least one node identifier and at least one Link > Termination Point (LTP) identifier MUST be present."; > } > leaf link-tp-id-uri { > type nt:tp-id; > description > "Link Termination Point (LTP) identifier."; > } 2569d3204 < mandatory true; 2574a3210,3214 > leaf node-id-uri { > type nw:node-id; > description > "The identifier of a node in the topology."; > } 2577d3216 < mandatory true; 2646a3286,3289 > must "node-id-uri or node-id" { > description > "At least one node identifier MUST be present."; > } 2648a3292,3296 > leaf node-id-uri { > type nw:node-id; > description > "The identifier of a node in the topology."; > } 2651d3298 < mandatory true; 2696a3344,3354 > must "(link-tp-id-uri or link-tp-id) and " + > "(node-id-uri or node-id)" { > description > "At least one node identifier and at least one Link > Termination Point (LTP) identifier MUST be present."; > } > leaf link-tp-id-uri { > type nt:tp-id; > description > "Link Termination Point (LTP) identifier."; > } 2699d3356 < mandatory true; 2704a3362,3366 > leaf node-id-uri { > type nw:node-id; > description > "The identifier of a node in the topology."; > } 2968a3631,3635 > leaf network-id { > type nw:network-id; > description > "The network topology identifier."; > } 2977c3644,3647 < container explicit-route-objects-always { --- > // CHANGE NOTE: The explicit-route-objects container below has > // been updated in this module revision > // RFC Editor: remove the note above and this note > container explicit-route-objects { 2979c3649 < "Container for the 'exclude route' object list."; --- > "Container for the explicit route object lists."; 3124,3126c3794,3800 < "Upper bound on the end-to-end TE path metric. A zero < indicates an unbounded upper limit for the specific < 'metric-type'."; --- > "Upper bound on the end-to-end TE path metric. > > A zero indicates an unbounded upper limit for the > specific 'metric-type'. > > The unit of is interpreted in the context of the > path-metric-type."; 3379c4053,4112 < } \ No newline at end of file --- > > // NOTE: The grouping encoding-and-switching-type below has been > // added in this module revision > // RFC Editor: remove the note above and this note > grouping encoding-and-switching-type { > description > "Common grouping to define the LSP encoding and > switching types"; > leaf encoding { > type identityref { > base te-types:lsp-encoding-types; > } > description > "LSP encoding type."; > reference > "RFC3945"; > } > leaf switching-type { > type identityref { > base te-types:switching-capabilities; > } > description > "LSP switching type."; > reference > "RFC3945"; > } > } > > // CHANGE NOTE: The typedef te-gen-node-id below has been > // added in this module revision > // RFC Editor: remove the note above and this note > grouping te-generic-node-id { > description > "A reusable grouping for a TE generic node identifier."; > leaf id { > type te-gen-node-id; > description > "The identifier of the node. Can be represented as IP > address or dotted quad address or as an URI."; > } > leaf type { > type enumeration { > enum ip { > description > "IP address representation of the node identifier."; > } > enum te-id { > description > "TE identifier of the node"; > } > enum node-id { > description > "URI representation of the node identifier."; > } > } > description > "Type of node identifier representation."; > } > } > } ]]>

Packet TE Types YANG Diffs RFC Editor: please remove this appendix before publication. This section provides the diff between the YANG module in section 3.2 of and the YANG model revision in . The intention of this appendix is to facilitate focusing the review of the YANG model in to the changes compared with the YANG model in . This diff has been generated using the following UNIX commands to compare the YANG module revisions in section 3.2 of and in :

model-diff.txt sed 's/^/ /' model-diff.txt > model-diff-spaces.txt sed 's/^ > / > /' model-diff-spaces.txt > model-updates.txt ]]>

The output (model-updates.txt) is reported here:

"RFCXXXX: Common YANG Data Types for Traffic Engineering"; 12a13,14 > // RFC Editor: replace XXXX with actual RFC number > // and remove this note 22c24 < --- > 37,39c39,49 < data type definitions specific to MPLS TE. The model fully < conforms to the Network Management Datastore Architecture < (NMDA). --- > data type definitions specific to Packet Traffic Enginnering > (TE). > > The model fully conforms to the Network Management Datastore > Architecture (NMDA). > > 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 (RFC 2119) (RFC 8174) when, and only when, > they appear in all capitals, as shown here. 41c51 < Copyright (c) 2020 IETF Trust and the persons identified as --- > Copyright (c) 2024 IETF Trust and the persons identified as 46c56 < the license terms contained in, the Simplified BSD License set --- > the license terms contained in, the Revised BSD License set 51,52c61,80 < This version of this YANG module is part of RFC 8776; see the < RFC itself for full legal notices."; --- > This version of this YANG module is part of RFC XXXX > (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself > for full legal notices."; > revision 2024-01-25 { > description > "Added common TE packet identities: > - bandwidth-profile-type; > - path-metric-loss; > - path-metric-delay-variation. > > Added common TE packet groupings: > - te-packet-path-bandwidth; > - te-packet-link-bandwidth. > > Updated module description."; > reference > "RFC XXXX: Common YANG Data Types for Traffic Engineering"; > } > // RFC Editor: replace XXXX with actual RFC number, update date > // information and remove this note 61c89,187 < /** --- > /* > * Identities > */ > > // CHANGE NOTE: The base identity bandwidth-profile-type and > // its derived identities below have been > // added in this module revision > // RFC Editor: remove the note above and this note > identity bandwidth-profile-type { > description > "Bandwidth Profile Types"; > } > > identity mef-10-bwp { > base bandwidth-profile-type; > description > "MEF 10 Bandwidth Profile"; > reference > "MEF 10.3: Ethernet Services Attributes Phase 3"; > } > > identity rfc-2697-bwp { > base bandwidth-profile-type; > description > "RFC 2697 Bandwidth Profile"; > reference > "RFC2697: A Single Rate Three Color Marker"; > } > > identity rfc-2698-bwp { > base bandwidth-profile-type; > description > "RFC 2698 Bandwidth Profile"; > reference > "RFC2698: A Two Rate Three Color Marker"; > } > > identity rfc-4115-bwp { > base bandwidth-profile-type; > description > "RFC 4115 Bandwidth Profile"; > reference > "RFC4115: A Differentiated Service Two-Rate, Three-Color > Marker with Efficient Handling of in-Profile Traffic"; > } > > // CHANGE NOTE: The identity path-metric-loss below has > // been added in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-loss { > base te-types:path-metric-type; > description > "The path loss (as a packet percentage) metric type > encodes a function of the unidirectional loss metrics of all > links traversed by a P2P path. > > The basic unit is 0.000003%, > where (2^24 - 2) or 50.331642% is the maximum value of the > path loss percentage that can be expressed. > > Values that are larger than the maximum value SHOULD be > encoded as the maximum value."; > reference > "RFC8233: Extensions to the Path Computation Element > Communication Protocol (PCEP) to Compute Service-Aware Label > Switched Paths (LSPs); > > RFC7471: OSPF Traffic Engineering (TE) Metric Extensions; > > RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions."; > } > > // CHANGE NOTE: The identity path-metric-delay-variation below has > // been added in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-delay-variation { > base te-types:path-metric-type; > description > "The path delay variation encodes the sum of the unidirectional > delay variation metrics of all links traversed by a P2P path. > > The path delay variation metric unit is in microseconds, where > (2^24 - 1) or 16,777,215 microseconds (16.777215 sec) is the > maximum value of the path delay variation that can be > expressed. > > Values that are larger than the maximum value SHOULD be > encoded as the maximum value."; > reference > "RFC8233: Extensions to the Path Computation Element > Communication Protocol (PCEP) to Compute Service-Aware Label > Switched Paths (LSPs); > > RFC7471: OSPF Traffic Engineering (TE) Metric Extensions; > > RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions."; > } > > /* 180a307,310 > /* > * Groupings > */ > 472a603,672 > } > } > > // CHANGE NOTE: The te-packet-path-bandwidth below has been > // added in this module revision > // RFC Editor: remove the note above and this note > grouping te-packet-path-bandwidth { > description > "Path bandwidth for Packet. "; > leaf bandwidth-profile-name { > type string; > description "Name of Bandwidth Profile."; > } > leaf bandwidth-profile-type { > type identityref { > base bandwidth-profile-type; > } > description "Type of Bandwidth Profile."; > } > leaf cir { > type uint64; > units "bits/second"; > mandatory true; > description > "Committed Information Rate (CIR)."; > } > leaf cbs { > type uint64; > units "bits/second"; > mandatory true; > description > "Committed Burst Size (CBS)."; > } > leaf eir { > type uint64; > units "bits/second"; > description > "Excess Information Rate (EIR)."; > } > leaf ebs { > type uint64; > units "bytes"; > description > "Excess Burst Size (EBS)."; > } > leaf pir { > type uint64; > units "bits/second"; > description > "Peak Information Rate (PIR)."; > } > leaf pbs { > type uint64; > units "bytes"; > description > "Peak Burst Size (PBS)."; > } > } > > // CHANGE NOTE: The te-packet-path-bandwidth below has been > // added in this module revision > // RFC Editor: remove the note above and this note > grouping te-packet-link-bandwidth { > description > "Link Bandwidth for Packet. "; > leaf packet-bandwidth { > type uint64; > units "bits/second"; > description > "Available bandwith value."; ]]>

Option Considered for updating RFC8776 RFC Editor: please remove this appendix before publication. The concern is how to be able to update the ietf-te-types YANG module published in without delaying too much the progress of the mature WG documents. Three possible options have been identified to address this concern. One option is to keep these definitions in the YANG modules where they have initially been defined: other YANG modules can still import them. The drawback of this approach is that it defeating the value of common YANG modules like ietf-te-types since common definitions will be spread around multiple specific YANG modules. A second option is to define them in a new common YANG module (e.g., ietf-te-types-ext). The drawback of this approach is that it will increase the number of YANG modules providing tiny updates to the ietf-te-types YANG module. A third option is to develop a revision of the ietf-te-types YANG module within an RFC8776-bis. The drawback of this approach is that the process for developing a big RFC8776-bis just for a tiny update is too high. Moreover, as suggested during IETF 113 Netmod WG discussion, a new revision of the ietf-te-packet-types YANG module, which is also defined in but it does not need to be revised, needs to be published just to change its reference to RFC8776-bis (see ). A fourth option, considered in the -00 WG version, was to: describe within the document only the updates to the ietf-te-types YANG module proposed by this document; include the whole updated YANG model within the main body; add some notes, to be removed before publication, within updated YANG model to focus the review only to the updates to the ietf-te-types YANG module proposed by this document. Based on the feedbacks from IETF 114 discussion, this version has been restructured to become an RFC8776-bis, with some notes, to be removed before publication, to focus the review only to the updates to the ietf-te-types YANG module proposed by this document. During the Netmod WG session at IETF 114, an alternative process has been introduced: https://datatracker.ietf.org/meeting/114/materials/slides-114-netmod-ad-topic-managing-the-evolution-of-ietf-yang-modules-00.pdf Future updates of this document could align with the proposed approach.

Acknowledgements The authors would like to thank Robert Wilton, Lou Berger, Mahesh Jethanandani and Jeff Haas for their valuable input to the discussion about the process to follow to provide tiny updates to a YANG module already published as an RFC. This document was prepared using kramdown.

Contributors Juniper Networks

vbeeram@juniper.net

Cisco Systems, Inc.

rgandhi@cisco.com