Internet-Draft | TE Common YANG Types | February 2024 |
Busi, et al. | Expires 25 August 2024 | [Page] |
This document defines a collection of common data types, identities, 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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 August 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
YANG [RFC6020] [RFC7950] 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) [RFC6241]. 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 data types, identities, and groupings are designed to be the common definitions applicable for modeling Traffic Engineering (TE) features in model(s) defined outside of this document.¶
This document adds new common data types, identities, and groupings to both the "ietf-te-types" and the "ietf-te-packet-types" YANG models and obsoletes [RFC8776]. For further details, see the revision statements of the YANG modules in Section 4 and Section 5, or the summary in Appendix A.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The terminology for describing YANG data models is found in [RFC7950].¶
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 Table 1.¶
Prefix | YANG module | Reference |
---|---|---|
yang | ietf-yang-types | [RFC6991] |
inet | ietf-inet-types | [RFC6991] |
rt-types | ietf-routing-types | [RFC8294] |
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.¶
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¶
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.¶
The "ietf-te-types" module (Section 4) 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 [RFC7471], [RFC8570], and [RFC7823].¶
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 [RFC4124].¶
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 [RFC6370] and [RFC5003]. 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 [RFC3630], the TE Router ID described in Section 3 of [RFC6827], the Traffic Engineering Router ID TLV described in Section 4.3 of [RFC5305], or the TE Router ID TLV described in Section 3.2.1 of [RFC6119]. The reachability of such a TE node MAY be achieved by a mechanism such as that described in Section 6.2 of [RFC6827].¶
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 [RFC8345], 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 [RFC3630] [RFC5305].¶
te-path-disjointness:¶
A type representing the different resource disjointness options for a TE tunnel path as defined in [RFC4872].¶
admin-groups:¶
A union type for a TE link's classic or extended administrative groups as defined in [RFC3630], [RFC5305], and [RFC7308].¶
srlg:¶
te-metric:¶
te-recovery-status:¶
An enumerated type for the different statuses of a recovery action as defined in [RFC4427] and [RFC6378].¶
path-attribute-flags:¶
A base YANG identity for supported LSP path flags as defined in [RFC3209], [RFC4090], [RFC4736], [RFC5712], [RFC4920], [RFC5420], [RFC7570], [RFC4875], [RFC5151], [RFC5150], [RFC6001], [RFC6790], [RFC7260], [RFC8001], [RFC8149], and [RFC8169].¶
link-protection-type:¶
restoration-scheme-type:¶
protection-external-commands:¶
A base YANG identity for supported protection-related external commands used for troubleshooting purposes, as defined in [RFC4427] and [ITU_G.808.1].¶
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 [RFC6780], [RFC4872], [RFC4873], and [RFC8800].¶
CHANGE NOTE: The association-type-diversity identity, defined in [RFC8800] has been added to the association-type base identity.¶
RFC Editor: remove the CHANGE NOTE above and this note¶
objective-function-type:¶
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 [RFC5541] 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:¶
lsp-encoding-types:¶
lsp-protection-type:¶
switching-capabilities:¶
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 [RFC2702] and [RFC3209].¶
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 [RFC3630] [RFC3785], [RFC5440], [RFC7471], [RFC8233] and [RFC8570].¶
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 [RFC7471] and [RFC8570].¶
explicit-route-hop:¶
te-link-access-type:¶
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 Section 3.1.1.¶
protocol-origin-type:¶
A base YANG identity for the type of protocol origin as defined in Section 3.1.2.¶
svec-objective-function-type:¶
svec-metric-type:¶
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¶
The "ietf-te-types" module contains the YANG reusable identities for reporting path computation error reasons as defined in [RFC5440], [RFC5441], [RFC5520], [RFC5557], [RFC8306], and [RFC8685].¶
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.¶
The "ietf-te-types" module contains the YANG reusable identities for the type of protocol origin as defined in [RFC5440] and [RFC9012].¶
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).¶
The "ietf-te-packet-types" module (Section 5) 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 [RFC4090].¶
te-class-type:¶
bc-type:¶
bc-model-type:¶
A base YANG identity for supported Diffserv-TE Bandwidth Constraints Models as defined in [RFC4125], [RFC4126], and [RFC4127].¶
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 [MEF_10.3], [RFC2697], [RFC2698] and [RFC4115] 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, Section 4, 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:¶
+--:(packet) +--rw bandwidth-profile-name? string +--rw bandwidth-profile-type? identityref +--rw cir? uint64 +--rw eir? uint64 +--rw cbs? uint64 +--rw ebs? uint64¶
NOTE: Other formats for the MPLS-TE path bandwidth are defined in [I-D.ietf-teas-yang-te-mpls] 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.¶
The "ietf-te-types" module imports from the following modules:¶
In addition to [RFC6991] and [RFC8294], this module references the following documents in defining the types and YANG groupings: [RFC9522], [RFC4090], [RFC4202], [RFC4328], [RFC4561], [RFC4657], [RFC4736], [RFC6004], [RFC6511], [RFC7139], [RFC7308], [RFC7551], [RFC7571], [RFC7579], and [ITU-T_G.709].¶
CHANGE NOTE: Please focus your review only on the updates to the YANG model: see also Appendix A.1.¶
RFC Editor: remove the CHANGE NOTE above and this note¶
The "ietf-te-packet-types" module imports from the "ietf-te-types" module defined in Section 4 of this document.¶
CHANGE NOTE: Please focus your review only on the updates to the YANG model: see also Appendix A.1.¶
RFC Editor: remove the CHANGE NOTE above and this note¶
For the following URIs in the "IETF XML Registry" [RFC3688], IANA has updated the reference field to refer to this document:¶
URI: urn:ietf:params:xml:ns:yang:ietf-te-types Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-te-packet-types Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.¶
This document also adds updated YANG modules to the "YANG Module Names" registry [RFC7950]:¶
name: ietf-te-types namespace: urn:ietf:params:xml:ns:yang:ietf-te-types prefix: te-types reference: RFC XXXX name: ietf-te-packet-types namespace: urn:ietf:params:xml:ns:yang:ietf-te-packet-types prefix: te-packet-types reference: RFC XXXX¶
RFC Editor: Please replace XXXX with the RFC number assigned to this document.¶
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
The 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 [RFC7950] apply for this document as well.¶
This version adds new common data types, identities, and groupings to the YANG modules. It also updates some of the existing data types, identities, and groupings in the YANG modules and fixes few bugs in [RFC8776].¶
The following new identities have been added to the 'ietf-te-types' module:¶
lsp-provisioning-error-reason;¶
association-type-diversity;¶
tunnel-admin-state-auto;¶
lsp-restoration-restore-none;¶
restoration-scheme-rerouting;¶
path-metric-optimization-type;¶
link-path-metric-type;¶
link-metric-type and its derived identities;¶
path-computation-error-reason and its derived identities;¶
protocol-origin-type and its derived identities;¶
svec-objective-function-type and its derived identities;¶
svec-metric-type and its derived identities.¶
The following new data types have been added to the 'ietf-te-types' module:¶
The following new groupings have been added to the 'ietf-te-types' module:¶
The following new identities have been added to the 'ietf-te-packet-types' module:¶
bandwidth-profile-type;¶
link-metric-delay-variation;¶
link-metric-loss;¶
path-metric-delay-variation;¶
path-metric-loss.¶
The following new groupings have been added to the 'ietf-te-packet-types' module:¶
The following identities, already defined in [RFC8776], have been updated in the 'ietf-te-types' module:¶
objective-function-type (editorial);¶
action-exercise (bug fix);¶
path-metric-type:¶
new base identities have been added;¶
path-metric-te (bug fix);¶
path-metric-igp (bug fix);¶
path-metric-hop (bug fix);¶
path-metric-delay-average (bug fix);¶
path-metric-delay-minimum (bug fix);¶
path-metric-residual-bandwidth (bug fix);¶
path-metric-optimize-includes (bug fix);¶
path-metric-optimize-excludes (bug fix);¶
te-optimization-criterion (editorial).¶
The following data type, already defined in [RFC8776], has been updated in the 'ietf-te-types' module:¶
The following groupings, already defined in [RFC8776], have been updated in the 'ietf-te-types' module:¶
explicit-route-hop¶
The following new leaves have been added to the 'explicit-route-hop' grouping:¶
The following leaves, already defined in [RFC8776], have been updated in the 'explicit-route-hop':¶
explicit-route-hop¶
The following new leaves have been added to the 'explicit-route-hop' grouping:¶
The following leaves, already defined in [RFC8776], have been updated in the 'explicit-route-hop':¶
optimization-metric-entry:¶
The following leaves, already defined in [RFC8776], have been updated in the 'optimization-metric-entry':¶
tunnel-constraints;¶
The following new leaf have been added to the 'tunnel-constraints' grouping:¶
network-id;¶
path-constraints-route-objects:¶
The following container, already defined in [RFC8776], has been updated in the 'path-constraints-route-objects':¶
generic-path-metric-bounds:¶
The following leaves, already defined in [RFC8776], have been updated in the 'optimization-metric-entry':¶
generic-path-optimization¶
The following new leaf have been added to the 'generic-path-optimization' grouping:¶
tiebreaker;¶
The following container, already defined in [RFC8776], has been deprecated:¶
tiebreakers.¶
The following identities, already defined in [RFC8776], have been obsoletes in the 'ietf-te-types' module for bug fixing:¶
of-minimize-agg-bandwidth-consumption;¶
of-minimize-load-most-loaded-link;¶
of-minimize-cost-path-set;¶
lsp-protection-reroute-extra;¶
lsp-protection-reroute.¶
RFC Editor: please remove this appendix before publication.¶
This section provides the diff between the YANG module in section 3.1 of [RFC8776] and the YANG model revision in Section 4.¶
The intention of this appendix is to facilitate focusing the review of the YANG model in Section 4 to the changes compared with the YANG model in [RFC8776].¶
This diff has been generated using the following UNIX commands to compare the YANG module revisions in section 3.1 of [RFC8776] and in Section 4:¶
diff ietf-te-types@2020-06-10.yang ietf-te-types.yang > 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:¶
21a22,31 > 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 < <mailto:tsaad@juniper.net> --- > <mailto:tsaad.net@gmail.com> 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,164 < 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-02-22 { > description > "This revision adds the following new identities: > - lsp-provisioning-error-reason; > - association-type-diversity; > - tunnel-admin-state-auto; > - lsp-restoration-restore-none; > - restoration-scheme-rerouting; > - path-metric-optimization-type; > - link-path-metric-type; > - link-metric-type and its derived identities; > - path-computation-error-reason and its derived identities; > - protocol-origin-type and its derived identities; > - svec-objective-function-type and its derived identities; > - svec-metric-type and its derived identities. > > This revision adds the following new data types: > - path-type; > - te-gen-node-id. > > This revision adds the following new groupings: > - encoding-and-switching-type; > - te-generic-node-id. > > This revision updates the following identities: > - objective-function-type; > - action-exercise; > - path-metric-type; > - path-metric-te; > - path-metric-igp; > - path-metric-hop; > - path-metric-delay-average; > - path-metric-delay-minimum; > - path-metric-residual-bandwidth; > - path-metric-optimize-includes; > - path-metric-optimize-excludes; > - te-optimization-criterion. > > This revision updates the following data types: > - te-node-id. > > This revision updates the following groupings: > - explicit-route-hop: > - adds the following leaves: > - node-id-uri; > - link-tp-id-uri; > - updates the following leaves: > - node-id; > - link-tp-id; > - record-route-state: > - adds the following leaves: > - node-id-uri; > - link-tp-id-uri; > - updates the following leaves: > - node-id; > - link-tp-id; > - optimization-metric-entry: > - updates the following leaves: > - metric-type; > - tunnel-constraints; > - adds the following leaves: > - network-id; > - path-constraints-route-objects: > - updates the following containers: > - explicit-route-objects-always; > - generic-path-metric-bounds: > - updates the following leaves: > - metric-type; > - generic-path-optimization > - adds the following leaves: > - tiebreaker; > - deprecate the following containers: > - tiebreakers. > > This revision obsoletes the following identities: > - of-minimize-agg-bandwidth-consumption; > - of-minimize-load-most-loaded-link; > - of-minimize-cost-path-set; > - lsp-protection-reroute-extra; > - lsp-protection-reroute. > > This revision provides also few editorial changes."; > 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 70c168 < "Latest revision of TE types."; --- > "Initial Version of TE types."; 86a185 > 92a192 > 93a194 > 111a213 > 155a258 > 158a262 > 263a368 > 264a370 > 269a376 > 351a459,461 > // CHANGE NOTE: The typedef te-node-id below has been > // updated in this module revision > // RFC Editor: remove the note above and this note 353c463,466 < type yang:dotted-quad; --- > type union { > type yang:dotted-quad; > type inet:ipv6-address-no-zone; > } 357,358c470,474 < 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,363c478,481 < 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. > 368a487 > 370a490 > 371a492 > 519a641 > 537a660 > 545a669,709 > // 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."; > } > 606a771,778 > // 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."; > } > 982a1155,1172 > // 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 > "RFC 8800: 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 985c1175 < "Base objective function type."; --- > "Base identity for path objective function types."; 1015a1206,1208 > // 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 1017a1211 > status obsolete; 1020c1214,1218 < consumption."; --- > consumption. > > This identity has been obsoleted: the > 'svec-of-minimize-agg-bandwidth-consumption' identity SHOULD > be used instead."; 1023c1221 < Computation Element Communication Protocol (PCEP)"; --- > Computation Element Communication Protocol (PCEP)"; 1025a1224,1226 > // 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 1027a1229 > status obsolete; 1030c1232,1236 < is carrying the highest load."; --- > is carrying the highest load. > > This identity has been obsoleted: the > 'svec-of-minimize-load-most-loaded-link' identity SHOULD > be used instead."; 1033c1239 < Computation Element Communication Protocol (PCEP)"; --- > Computation Element Communication Protocol (PCEP)"; 1035a1242,1244 > // 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 1037a1247 > status obsolete; 1039c1249,1253 < "Objective function for minimizing the cost on a path set."; --- > "Objective function for minimizing the cost on a path set. > > This identity has been obsoleted: the > 'svec-of-minimize-cost-path-set' identity SHOULD > be used instead."; 1049a1264,1266 > // CHANGE NOTE: The reference of the identity path-locally-computed > // below has been updated in this module revision > // RFC Editor: remove the note above and this note 1056,1057c1273,1274 < "RFC 3272: Overview and Principles of Internet Traffic < Engineering, Section 5.4"; --- > "RFC 9522: Overview and Principles of Internet Traffic > Engineering, Section 4.4"; 1059a1277,1280 > // CHANGE NOTE: The reference of the identity > // path-externally-queried below has been updated > // in this module revision > // RFC Editor: remove the note above and this note 1071c1292 < "RFC 3272: Overview and Principles of Internet Traffic --- > "RFC 9522: Overview and Principles of Internet Traffic 1072a1294 > 1076a1299,1302 > // CHANGE NOTE: The reference of the identity > // path-explicitly-defined below has been updated > // in this module revision > // RFC Editor: remove the note above and this note 1085c1311,1312 < RFC 3272: Overview and Principles of Internet Traffic --- > > RFC 9522: Overview and Principles of Internet Traffic 1216a1444,1455 > // 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."; > } > 1321a1561,1569 > // 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."; > } > 1339a1588,1602 > // 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)"; > } > 1383a1647,1649 > // 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 1385a1652 > status obsolete; 1387c1654,1658 < "'(Full) Rerouting' LSP protection type."; --- > "'(Full) Rerouting' LSP protection type. > > This identity has been obsoleted: the > 'restoration-scheme-rerouting' identity SHOULD be used > instead."; 1392a1664,1666 > // CHANGE NOTE: The identity lsp-protection-reroute > // below has been obsoleted in this module revision > // RFC Editor: remove the note above and this note 1394a1669 > status obsolete; 1396c1671,1675 < "'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."; 1628a1908,1911 > // 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,1633c1915,1917 < "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,1637c1920,1921 < "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"; 1917c2201,2204 < identity path-metric-type { --- > // CHANGE NOTE: The path-metric-optimization-type base identity > // has been added in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-optimization-type { 1919c2206,2207 < "Base identity for the path metric type."; --- > "Base identity used to define the path metric optimization > types."; 1922,1923c2210,2213 < identity path-metric-te { < base path-metric-type; --- > // CHANGE NOTE: The link-path-metric-type base identity > // has been added in this module revision > // RFC Editor: remove the note above and this note > identity link-path-metric-type { 1925,1928c2215,2221 < "TE path metric."; < reference < "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a < second MPLS Traffic Engineering (TE) Metric"; --- > "Base identity used to define the link and the path metric > types. > > The unit of the path metric value is interpreted in the > context of the path metric type and the derived identities > SHOULD describe the unit of the path metric types they > define."; 1931,1938c2224,2232 < 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 link-metric-type base identity > // and its derived identities > // have been added in this module revision > // RFC Editor: remove the note above and this note > identity link-metric-type { > base link-path-metric-type; > description > "Base identity for the link metric types."; > } 1940,1944c2234,2240 < identity path-metric-hop { < base path-metric-type; < description < "Hop path metric."; < } --- > identity link-metric-te { > base link-metric-type; > description > "Traffic Engineering (TE) Link Metric."; > reference > "RFC 3630: Traffic Engineering (TE) Extensions to OSPF > Version 2, section 2.5.5 1946,1952c2242,2244 < identity path-metric-delay-average { < base path-metric-type; < description < "Average unidirectional link delay."; < reference < "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions"; < } --- > RFC 5305: IS-IS Extensions for Traffic Engineering, > section 3.7"; > } 1954,1960c2246,2253 < identity path-metric-delay-minimum { < base path-metric-type; < description < "Minimum unidirectional link delay."; < reference < "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions"; < } --- > identity link-metric-igp { > base link-metric-type; > description > "Interior Gateway Protocol (IGP) Link Metric."; > reference > "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric > as a second MPLS Traffic Engineering (TE) Metric"; > } 1962,1972c2255,2266 < 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 link-metric-delay-average { > base link-metric-type; > description > "Unidirectional Link Delay, measured in units of > microseconds."; > reference > "RFC 7471: OSPF Traffic Engineering (TE) Metric > Extensions, section 4.1 > > RFC 8570: IS-IS Traffic Engineering (TE) Metric > Extensions, section 4.1"; > } 1974,1979c2268,2279 < identity path-metric-optimize-includes { < base path-metric-type; < description < "A metric that optimizes the number of included resources < specified in a set."; < } --- > identity link-metric-delay-minimum { > base link-metric-type; > description > "Minimum unidirectional Link Delay, measured in units of > microseconds."; > reference > "RFC 7471: OSPF Traffic Engineering (TE) Metric > Extensions, section 4.2 > > RFC 8570: IS-IS Traffic Engineering (TE) Metric > Extensions, section 4.2"; > } 1981,1986c2281,2425 < 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 link-metric-delay-maximum { > base link-metric-type; > description > "Maximum unidirectional Link Delay, measured in units of > microseconds."; > reference > "RFC 7471: OSPF Traffic Engineering (TE) Metric > Extensions, section 4.2 > > RFC 8570: IS-IS Traffic Engineering (TE) Metric > Extensions, section 4.2"; > } > > identity link-metric-residual-bandwidth { > base link-metric-type; > description > "Unidirectional Residual Bandwidth, measured in units of > bytes per second. > > It is defined to be Maximum Bandwidth minus the bandwidth > currently allocated to LSPs."; > reference > "RFC 7471: OSPF Traffic Engineering (TE) Metric > Extensions, section 4.5 > > RFC 8570: IS-IS Traffic Engineering (TE) Metric > Extensions, section 4.5"; > } > > // CHANGE NOTE: The base and the description of the > // path-metric-type identity > // has been updated in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-type { > base link-path-metric-type; > base path-metric-optimization-type; > description > "Base identity for the path metric types."; > } > > // CHANGE NOTE: The description and the reference of the > // path-metric-te identity have been updated > // in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-te { > base path-metric-type; > description > "Traffic Engineering (TE) Path Metric."; > reference > "RFC 5440: Path Computation Element (PCE) Communication > Protocol (PCEP), section 7.8"; > } > > // CHANGE NOTE: The description and the reference of the > // path-metric-igp identity have been updated > // in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-igp { > base path-metric-type; > description > "Interior Gateway Protocol (IGP) Path Metric."; > reference > "RFC 5440: Path Computation Element (PCE) Communication > Protocol (PCEP), section 7.8"; > } > > // CHANGE NOTE: The description and the reference of the > // path-metric-hop identity have been updated > // in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-hop { > base path-metric-type; > description > "Hop Count Path Metric."; > reference > "RFC 5440: Path Computation Element (PCE) Communication > Protocol (PCEP), section 7.8"; > } > > // CHANGE NOTE: The description and the reference of the > // path-metric-delay-average identity have been updated > // in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-delay-average { > base path-metric-type; > description > "The Path Delay Metric, measured in units of > microseconds."; > reference > "RFC8233: Extensions to the Path Computation Element > Communication Protocol (PCEP) to Compute Service-Aware > Label Switched Paths (LSPs), section 3.1.1"; > } > > // CHANGE NOTE: The description and the reference of the > // path-metric-delay-minimum identity have been updated > // in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-delay-minimum { > base path-metric-type; > description > "The Path Min Delay Metric, measured in units of > microseconds."; > reference > "I-D.ietf-pce-sid-algo: Carrying SR-Algorithm information > in PCE-based Networks, section 3.5.1"; > } > > // CHANGE NOTE: The description and the reference of the > // path-metric-residual-bandwidth identity have been updated > // in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-residual-bandwidth { > base path-metric-type; > description > "The Path Residual Bandwidth, defined as the minimum Link > Residual Bandwidth all the links along the path. > > The Path Residual Bandwidth can be seen as the path > metric associated with the Maximum residual Bandwidth Path > (MBP) objective function."; > reference > "RFC 5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)"; > } > > // CHANGE NOTE: The base of the path-metric-optimize-includes > // identity has been updated in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-optimize-includes { > base path-metric-optimization-type; > description > "A metric that optimizes the number of included resources > specified in a set."; > } > > // CHANGE NOTE: The base of the path-metric-optimize-excludes > // identity has been updated in this module revision > // RFC Editor: remove the note above and this note > identity path-metric-optimize-excludes { > base path-metric-optimization-type; > description > "A metric that optimizes to a maximum the number of excluded > resources specified in a set."; > } 2049a2489,2492 > // CHANGE NOTE: The reference of the identity > // te-optimization-criterion below has been updated > // in this module revision > // RFC Editor: remove the note above and this note 2054c2497 < "RFC 3272: Overview and Principles of Internet Traffic --- > "RFC 9522: Overview and Principles of Internet Traffic 2110a2554,2994 > // 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 > "RFC 5440: Path Computation Element (PCE) Communication > Protocol (PCEP), section 7.5"; > } > > 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 > "RFC 5441: A Backward-Recursive PCE-Based Computation (BRPC) > Procedure to Compute Shortest Constrained Inter-Domain > Traffic Engineering Label Switched Paths > > RFC 8685: Path Computation Element Communication Protocol > (PCEP) Extensions for the Hierarchical Path Computation > Element (H-PCE) Architecture"; > } > > 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 > "RFC 5440: Path Computation Element (PCE) Communication > Protocol (PCEP) > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 8685: Path Computation Element Communication Protocol > (PCEP) Extensions for the Hierarchical Path Computation > Element (H-PCE) Architecture > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 8685: Path Computation Element Communication Protocol > (PCEP) Extensions for the Hierarchical Path Computation > Element (H-PCE) Architecture > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 8685: Path Computation Element Communication Protocol > (PCEP) Extensions for the Hierarchical Path Computation > Element (H-PCE) Architecture > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 8685: Path Computation Element Communication Protocol > (PCEP) Extensions for the Hierarchical Path Computation > Element (H-PCE) Architecture > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 8306: Extensions to the Path Computation Element > Communication Protocol (PCEP) for Point-to-Multipoint > Traffic Engineering Label Switched Paths > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 5557: Path Computation Element Communication Protocol > (PCEP) Requirements and Protocol Extensions in Support of > Global Concurrent Optimization > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 5557: Path Computation Element Communication Protocol > (PCEP) Requirements and Protocol Extensions in Support of > Global Concurrent Optimization > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 5520: Preserving Topology Confidentiality in > Inter-Domain Path Computation Using a Path-Key-Based > Mechanism > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 5441: A Backward-Recursive PCE-Based Computation (BRPC) > Procedure to Compute Shortest Constrained Inter-Domain > Traffic Engineering Label Switched Paths > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 5440: Path Computation Element (PCE) Communication > Protocol (PCEP); > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > 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 > "RFC 5440: Path Computation Element (PCE) Communication > Protocol (PCEP); > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > identity path-computation-error-no-server { > base path-computation-error-reason; > description > "Path computation has failed because path computation > server is unavailable."; > reference > "RFC 5440: Path Computation Element (PCE) Communication > Protocol (PCEP); > > https://www.iana.org/assignments/pcep > /pcep.xhtml#no-path-vector-tlv"; > } > > // 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 > "RFC 5440: Path Computation Element (PCE) Communication > Protocol (PCEP)"; > } > > identity protocol-origin-bgp { > base protocol-origin-type; > description > "Protocol origin is Border Gateway Protocol (BGP)."; > reference "RFC 9012"; > } > > // 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 > "RFC 5541: 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 > "RFC 5541: 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 > "RFC 5541: 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 > "RFC 5541: 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 > "RFC 8685: 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 > "RFC 8685: 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 > "RFC 8685: 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 > "RFC 8685: 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 > "RFC 5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)"; > } > > identity svec-metric-cumulative-te { > base svec-metric-type; > description > "Cumulative TE cost."; > reference > "RFC 5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)"; > } > > identity svec-metric-cumulative-igp { > base svec-metric-type; > description > "Cumulative IGP cost."; > reference > "RFC 5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)"; > } > > identity svec-metric-cumulative-hop { > base svec-metric-type; > description > "Cumulative Hop path metric."; > reference > "RFC 5541: 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 > "RFC 5541: 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 > "RFC 5541: Encoding of Objective Functions in the Path > Computation Element Communication Protocol (PCEP)"; > } > 2222,2225c3106,3111 < 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"; --- > > 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"; 2506a3393,3395 > // CHANGE NOTE: The explicit-route-hop grouping below has been > // updated in this module revision > // RFC Editor: remove the note above and this note 2514a3404,3412 > 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."; > } 2517d3414 < mandatory true; 2566a3464,3474 > 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."; > } 2569d3476 < mandatory true; 2574a3482,3486 > leaf node-id-uri { > type nw:node-id; > description > "The identifier of a node in the topology."; > } 2577d3488 < mandatory true; 2631a3543,3545 > // CHANGE NOTE: The explicit-route-hop grouping below has been > // updated in this module revision > // RFC Editor: remove the note above and this note 2646a3561,3564 > must "node-id-uri or node-id" { > description > "At least one node identifier MUST be present."; > } 2648a3567,3571 > leaf node-id-uri { > type nw:node-id; > description > "The identifier of a node in the topology."; > } 2651d3573 < mandatory true; 2696a3619,3629 > 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."; > } 2699d3631 < mandatory true; 2704a3637,3641 > leaf node-id-uri { > type nw:node-id; > description > "The identifier of a node in the topology."; > } 2881a3819,3821 > // CHANGE NOTE: The grouping optimization-metric-entry below has > // been updated in this module revision > // RFC Editor: remove the note above and this note 2887c3827 < base path-metric-type; --- > base path-metric-optimization-type; 2964a3905,3907 > // CHANGE NOTE: The grouping tunnel-constraints below has > // been updated in this module revision > // RFC Editor: remove the note above and this note 2968a3912,3916 > leaf network-id { > type nw:network-id; > description > "The network topology identifier."; > } 2972a3921,3923 > // CHANGE NOTE: The grouping path-constraints-route-objects below > // has been updated in this module revision > // RFC Editor: remove the note above and this note 2977c3928 < container explicit-route-objects-always { --- > container explicit-route-objects { 2979c3930 < "Container for the 'exclude route' object list."; --- > "Container for the explicit route object lists."; 3101a4053,4055 > // CHANGE NOTE: The grouping generic-path-metric-bounds below > // has been updated in this module revision > // RFC Editor: remove the note above and this note 3107c4061 < "TE path metric bounds container."; --- > "Top-level container for the list of path metric bounds."; 3111c4065,4073 < "List of TE path metric bounds."; --- > "List of path metric bounds, which can apply to link and > path metrics. > > TE paths which have at least one path metric which > exceeds the specified bounds MUST NOT be selected. > > TE paths that traverse TE links which have at least one > link metric which exceeds the specified bounds MUST NOT > be selected."; 3114c4076 < base path-metric-type; --- > base link-path-metric-type; 3124,3126c4086,4092 < "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 specified 'metric-type'. > > A zero indicates an unbounded upper limit for the > specificied 'metric-type'. > > The unit of is interpreted in the context of the > 'metric-type' identity."; 3131a4098,4100 > // CHANGE NOTE: The grouping generic-path-metric-bounds below > // has been updated in this module revision > // RFC Editor: remove the note above and this note 3152a4122 > status deprecated; 3154c4124,4127 < "Container for the list of tiebreakers."; --- > "Container for the list of tiebreakers. > > This container has been obsoleted by the tiebreaker > leaf."; 3189a4163,4171 > leaf tiebreaker { > type identityref { > base path-tiebreaker-type; > } > default "te-types:path-tiebreaker-random"; > description > "The tiebreaker criteria to apply on an equally favored set > of paths, in order to pick the best."; > } 3379c4361,4420 < } \ 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 > "RFC 3945"; > } > leaf switching-type { > type identityref { > base te-types:switching-capabilities; > } > description > "LSP switching type."; > reference > "RFC 3945"; > } > } > > // 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."; > } > } > }¶
RFC Editor: please remove this appendix before publication.¶
This section provides the diff between the YANG module in section 3.2 of [RFC8776] and the YANG model revision in Section 5.¶
The intention of this appendix is to facilitate focusing the review of the YANG model in Section 5 to the changes compared with the YANG model in [RFC8776].¶
This diff has been generated using the following UNIX commands to compare the YANG module revisions in section 3.2 of [RFC8776] and in Section 5:¶
diff ietf-te-packet-types@2020-06-10.yang ietf-te-packet-types.yang > 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:¶
11c11 < "RFC 8776: Common YANG Data Types for Traffic Engineering"; --- > "RFCXXXX: Common YANG Data Types for Traffic Engineering"; 12a13,14 > // RFC Editor: replace XXXX with actual RFC number > // and remove this note 22c24 < <mailto:tsaad@juniper.net> --- > <mailto:tsaad.net@gmail.com> 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,82 < 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-02-16 { > description > "This revision adds the following new identities: > - bandwidth-profile-type; > - link-metric-delay-variation; > - link-metric-loss; > - path-metric-delay-variation; > - path-metric-loss. > > This revision adds the following new groupings: > - te-packet-path-bandwidth; > - te-packet-link-bandwidth. > > This revision provides also few editorial changes."; > 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 61c91,196 < /** --- > /* > * 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 link-metric-delay-variation > // below has been added in this module revision > // RFC Editor: remove the note above and this note > identity link-metric-delay-variation { > base te-types:link-metric-type; > description > "The Unidirectional Delay Variation Metric, > measured in units of microseconds."; > reference > "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions, > section 4.3 > > RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions, > section 4.3"; > } > > // CHANGE NOTE: The identity link-metric-loss below has > // been added in this module revision > // RFC Editor: remove the note above and this note > identity link-metric-loss { > base te-types:link-metric-type; > description > "The Unidirectional Link Loss Metric, > measured in units of 0.000003%."; > reference > "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions, > section 4.4 > > RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions, > section 4.4"; > } > > // 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 Metric, > measured in units of microseconds."; > reference > "RFC8233: Extensions to the Path Computation Element > Communication Protocol (PCEP) to Compute Service-Aware Label > Switched Paths (LSPs), section 3.1.2"; > } > > // 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 Metric, measured in units of 0.000003%."; > reference > "RFC8233: Extensions to the Path Computation Element > Communication Protocol (PCEP) to Compute Service-Aware Label > Switched Paths (LSPs), section 3.1.3"; > } > > /* 180a316,319 > /* > * Groupings > */ > 472a612,681 > } > } > > // 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.";¶
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 [RFC8776] 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 [RFC8776] but it does not need to be revised, needs to be published just to change its reference to RFC8776-bis (see [RFC9314]).¶
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.¶
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.¶