Internet-Draft | TE Common YANG Types | January 2024 |
Busi, et al. | Expires 1 August 2024 | [Page] |
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.¶
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 1 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 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 [RFC8776].¶
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 [I-D.ietf-teas-yang-te], [I-D.ietf-teas-yang-path-computation] and [I-D.ietf-teas-yang-l3-te-topo] and are quite mature: [I-D.ietf-teas-yang-te] and [I-D.ietf-teas-yang-path-computation] 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¶
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: [RFC3272], [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.¶
To be added in a future revision of this draft.¶
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) 2023 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 2023-11-25e { > 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 353c400,403 < type yang:dotted-quad; --- > type union { > type yang:dotted-quad; > type inet:ipv6-address-no-zone; > } 357,358c407,411 < 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,363c415,418 < 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. > 368a424 > 370a427 > 371a429 > 545a604,631 > // 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."; > } > 606a693,700 > // 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."; > } > 982a1077,1094 > // 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 985c1097 < "Base objective function type."; --- > "Base identity for path objective function type."; 1015a1128,1130 > // 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 1017a1133 > status obsolete; 1020c1136 < consumption."; --- > consumption."; 1023c1139 < Computation Element Communication Protocol (PCEP)"; --- > Computation Element Communication Protocol (PCEP)"; 1025a1142,1144 > // 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 1027a1147 > status obsolete; 1030c1150 < is carrying the highest load."; --- > is carrying the highest load."; 1033c1153 < Computation Element Communication Protocol (PCEP)"; --- > Computation Element Communication Protocol (PCEP)"; 1035a1156,1158 > // 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 1037a1161 > status obsolete; 1216a1341,1352 > // 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."; > } > 1321a1458,1466 > // 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."; > } > 1339a1485,1499 > // 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)"; > } > 1383a1544,1546 > // 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 1385a1549 > status obsolete; 1387c1551,1555 < "'(Full) Rerouting' LSP protection type."; --- > "'(Full) Rerouting' LSP protection type. > > This identity has been obsoleted: the > 'restoration-scheme-rerouting' identity SHOULD be used > instead."; 1392a1561,1563 > // CHANGE NOTE: The identity lsp-protection-reroute > // below has been obsoleted in this module revision > // RFC Editor: remove the note above and this note 1394a1566 > status obsolete; 1396c1568,1572 < "'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."; 1628a1805,1808 > // cCHANGE 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,1633c1812,1814 < "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,1637c1817,1818 < "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"; 1916a2098,2100 > // 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 1919c2103,2106 < "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."; 1939a2127,2129 > // 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 1943a2134,2136 > reference > "RFC5440: Path Computation Element (PCE) Communication > Protocol (PCEP)"; 1945a2139 > 2110a2305,2708 > // 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)."; > } > 2514a3113,3121 > 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."; > } 2517d3123 < mandatory true; 2566a3173,3183 > 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."; > } 2569d3185 < mandatory true; 2574a3191,3195 > leaf node-id-uri { > type nw:node-id; > description > "The identifier of a node in the topology."; > } 2577d3197 < mandatory true; 2646a3267,3270 > must "node-id-uri or node-id" { > description > "At least one node identifier MUST be present."; > } 2648a3273,3277 > leaf node-id-uri { > type nw:node-id; > description > "The identifier of a node in the topology."; > } 2651d3279 < mandatory true; 2696a3325,3335 > 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."; > } 2699d3337 < mandatory true; 2704a3343,3347 > leaf node-id-uri { > type nw:node-id; > description > "The identifier of a node in the topology."; > } 2968a3612,3616 > leaf network-id { > type nw:network-id; > description > "The network topology identifier."; > } 2977c3625 < container explicit-route-objects-always { --- > container explicit-route-objects { 3124,3126c3772,3778 < "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."; 3379c4031,4058 < } \ 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"; > } > } > }¶
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,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.";¶
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.¶