Internet-Draft | TE Common YANG Types | March 2023 |
Busi, et al. | Expires 11 September 2023 | [Page] |
- Workgroup:
- TEAS Working Group
- Internet-Draft:
- draft-ietf-teas-rfc8776-update-02
- Obsoletes:
- 8776 (if approved)
- Published:
- Intended Status:
- Standards Track
- Expires:
Common YANG Data Types for Traffic Engineering
Abstract
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.¶
Status of This Memo
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 11 September 2023.¶
Copyright Notice
Copyright (c) 2023 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.¶
1. Introduction
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¶
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
1.2. Terminology
The terminology for describing YANG data models is found in [RFC7950].¶
1.3. Prefixes in Data Node Names
In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in 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.¶
2. Acronyms and Abbreviations
GMPLS:¶
-
Generalized Multiprotocol Label Switching¶
LSP:¶
-
Label Switched Path¶
LSR:¶
-
Label Switching Router¶
LER:¶
-
Label Edge Router¶
MPLS:¶
-
Multiprotocol Label Switching¶
RSVP:¶
-
Resource Reservation Protocol¶
TE:¶
-
Traffic Engineering¶
DS-TE:¶
-
Differentiated Services Traffic Engineering¶
SRLG:¶
-
Shared Risk Link Group¶
NBMA:¶
-
Non-Broadcast Multi-Access¶
APS:¶
-
Automatic Protection Switching¶
SD:¶
-
Signal Degrade¶
SF:¶
-
Signal Fail¶
WTR:¶
-
Wait-to-Restore¶
PM:¶
-
Performance Metrics¶
3. Overview
This document defines two YANG modules for common TE types: "ietf-te-types" for TE generic types and "ietf-te-packet-types" for packet-specific types. Other technology-specific TE types are outside the scope of this document.¶
3.1. TE Types Module Contents
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].¶
path-metric-type:¶
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¶
bandwidth-scientific-notation:¶
-
This data type represents the bandwidth, in bit-per-second, using the scientific notation (e.g., 10e3).¶
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¶
3.1.1. Path Computation Errors
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.¶
3.1.2. Protocol Origin
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).¶
3.2. Packet TE Types Module Contents
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.¶
-
All the link 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 link bandwidth can be represented by a bandwidth expressed in scientific notation as follow:¶
+--:(packet) +--rw packet-bandwidth? bandwidth-scientific-notation¶
4. TE Types YANG Module
The "ietf-te-types" module imports from the following modules:¶
- "ietf-yang-types" and "ietf-inet-types" as defined in [RFC6991]¶
- "ietf-routing-types" as defined in [RFC8294]¶
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¶
5. Packet TE Types YANG Module
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¶
6. IANA Considerations
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.¶
7. Security Considerations
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [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.¶
8. References
8.1. Normative References
- [ITU_G.808.1]
- ITU-T Recommendation G.808.1, "Generic protection switching - Linear trail and subnetwork protection", ITU-T G.808.1 , .
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC5440]
- Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <https://www.rfc-editor.org/info/rfc5440>.
- [RFC5441]
- Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, , <https://www.rfc-editor.org/info/rfc5441>.
- [RFC5520]
- Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, , <https://www.rfc-editor.org/info/rfc5520>.
- [RFC5541]
- Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, , <https://www.rfc-editor.org/info/rfc5541>.
- [RFC5557]
- Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, , <https://www.rfc-editor.org/info/rfc5557>.
- [RFC6020]
- Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, , <https://www.rfc-editor.org/info/rfc6020>.
- [RFC6241]
- Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
- [RFC6242]
- Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, , <https://www.rfc-editor.org/info/rfc6242>.
- [RFC6991]
- Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, , <https://www.rfc-editor.org/info/rfc6991>.
- [RFC7950]
- Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
- [RFC8040]
- Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
- [RFC8174]
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8294]
- Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, , <https://www.rfc-editor.org/info/rfc8294>.
- [RFC8306]
- Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 8306, DOI 10.17487/RFC8306, , <https://www.rfc-editor.org/info/rfc8306>.
- [RFC8341]
- Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, , <https://www.rfc-editor.org/info/rfc8341>.
- [RFC8345]
- Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, , <https://www.rfc-editor.org/info/rfc8345>.
- [RFC8446]
- Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
- [RFC8685]
- Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., and D. King, "Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture", RFC 8685, DOI 10.17487/RFC8685, , <https://www.rfc-editor.org/info/rfc8685>.
- [RFC8776]
- Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, "Common YANG Data Types for Traffic Engineering", RFC 8776, DOI 10.17487/RFC8776, , <https://www.rfc-editor.org/info/rfc8776>.
- [RFC8800]
- Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, "Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800, , <https://www.rfc-editor.org/info/rfc8800>.
- [RFC9012]
- Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, , <https://www.rfc-editor.org/info/rfc9012>.
8.2. Informative References
- [I-D.ietf-teas-yang-l3-te-topo]
- Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H. C., and O. G. de Dios, "YANG Data Model for Layer 3 TE Topologies", Work in Progress, Internet-Draft, draft-ietf-teas-yang-l3-te-topo-13, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-l3-te-topo-13>.
- [I-D.ietf-teas-yang-path-computation]
- Busi, I., Belotti, S., de Dios, O. G., Sharma, A., Shi, Y., and D. Ceccarelli, "A YANG Data Model for requesting path computation", Work in Progress, Internet-Draft, draft-ietf-teas-yang-path-computation-20, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-path-computation-20>.
- [I-D.ietf-teas-yang-te]
- Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., and O. G. de Dios, "A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces", Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-31, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-31>.
- [I-D.ietf-teas-yang-te-mpls]
- Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I. Bryskin, "A YANG Data Model for MPLS Traffic Engineering Tunnels", Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-mpls-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-mpls-03>.
- [ITU-T_G.709]
- International Telecommunication Union, "Interfaces for the optical transport network", ITU-T G.709 , .
- [MEF_10.3]
- MEF, "Ethernet Services Attributes Phase 3", MEF 10.3 , .
- [RFC2697]
- Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, DOI 10.17487/RFC2697, , <https://www.rfc-editor.org/info/rfc2697>.
- [RFC2698]
- Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, DOI 10.17487/RFC2698, , <https://www.rfc-editor.org/info/rfc2698>.
- [RFC2702]
- Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, , <https://www.rfc-editor.org/info/rfc2702>.
- [RFC3209]
- Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, , <https://www.rfc-editor.org/info/rfc3209>.
- [RFC3272]
- Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10.17487/RFC3272, , <https://www.rfc-editor.org/info/rfc3272>.
- [RFC3471]
- Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, , <https://www.rfc-editor.org/info/rfc3471>.
- [RFC3477]
- Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, , <https://www.rfc-editor.org/info/rfc3477>.
- [RFC3630]
- Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, , <https://www.rfc-editor.org/info/rfc3630>.
- [RFC3688]
- Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
- [RFC3785]
- Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, DOI 10.17487/RFC3785, , <https://www.rfc-editor.org/info/rfc3785>.
- [RFC4090]
- Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, , <https://www.rfc-editor.org/info/rfc4090>.
- [RFC4115]
- Aboul-Magd, O. and S. Rabie, "A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, , <https://www.rfc-editor.org/info/rfc4115>.
- [RFC4124]
- Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, DOI 10.17487/RFC4124, , <https://www.rfc-editor.org/info/rfc4124>.
- [RFC4125]
- Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, DOI 10.17487/RFC4125, , <https://www.rfc-editor.org/info/rfc4125>.
- [RFC4126]
- Ash, J., "Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons", RFC 4126, DOI 10.17487/RFC4126, , <https://www.rfc-editor.org/info/rfc4126>.
- [RFC4127]
- Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, DOI 10.17487/RFC4127, , <https://www.rfc-editor.org/info/rfc4127>.
- [RFC4202]
- Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, , <https://www.rfc-editor.org/info/rfc4202>.
- [RFC4203]
- Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, , <https://www.rfc-editor.org/info/rfc4203>.
- [RFC4328]
- Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, DOI 10.17487/RFC4328, , <https://www.rfc-editor.org/info/rfc4328>.
- [RFC4427]
- Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, , <https://www.rfc-editor.org/info/rfc4427>.
- [RFC4561]
- Vasseur, J.-P., Ed., Ali, Z., and S. Sivabalan, "Definition of a Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, DOI 10.17487/RFC4561, , <https://www.rfc-editor.org/info/rfc4561>.
- [RFC4657]
- Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, , <https://www.rfc-editor.org/info/rfc4657>.
- [RFC4736]
- Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, DOI 10.17487/RFC4736, , <https://www.rfc-editor.org/info/rfc4736>.
- [RFC4872]
- Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, , <https://www.rfc-editor.org/info/rfc4872>.
- [RFC4873]
- Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, , <https://www.rfc-editor.org/info/rfc4873>.
- [RFC4875]
- Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, , <https://www.rfc-editor.org/info/rfc4875>.
- [RFC4920]
- Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, , <https://www.rfc-editor.org/info/rfc4920>.
- [RFC5003]
- Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, DOI 10.17487/RFC5003, , <https://www.rfc-editor.org/info/rfc5003>.
- [RFC5150]
- Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, DOI 10.17487/RFC5150, , <https://www.rfc-editor.org/info/rfc5150>.
- [RFC5151]
- Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, DOI 10.17487/RFC5151, , <https://www.rfc-editor.org/info/rfc5151>.
- [RFC5305]
- Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, , <https://www.rfc-editor.org/info/rfc5305>.
- [RFC5307]
- Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, , <https://www.rfc-editor.org/info/rfc5307>.
- [RFC5420]
- Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangar, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, , <https://www.rfc-editor.org/info/rfc5420>.
- [RFC5712]
- Meyer, M., Ed. and JP. Vasseur, Ed., "MPLS Traffic Engineering Soft Preemption", RFC 5712, DOI 10.17487/RFC5712, , <https://www.rfc-editor.org/info/rfc5712>.
- [RFC6001]
- Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, DOI 10.17487/RFC6001, , <https://www.rfc-editor.org/info/rfc6001>.
- [RFC6004]
- Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching", RFC 6004, DOI 10.17487/RFC6004, , <https://www.rfc-editor.org/info/rfc6004>.
- [RFC6119]
- Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, , <https://www.rfc-editor.org/info/rfc6119>.
- [RFC6370]
- Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, , <https://www.rfc-editor.org/info/rfc6370>.
- [RFC6378]
- Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, , <https://www.rfc-editor.org/info/rfc6378>.
- [RFC6511]
- Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths", RFC 6511, DOI 10.17487/RFC6511, , <https://www.rfc-editor.org/info/rfc6511>.
- [RFC6780]
- Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/RFC6780, , <https://www.rfc-editor.org/info/rfc6780>.
- [RFC6790]
- Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, , <https://www.rfc-editor.org/info/rfc6790>.
- [RFC6827]
- Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, Ed., "Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols", RFC 6827, DOI 10.17487/RFC6827, , <https://www.rfc-editor.org/info/rfc6827>.
- [RFC7139]
- Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., and K. Pithewan, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", RFC 7139, DOI 10.17487/RFC7139, , <https://www.rfc-editor.org/info/rfc7139>.
- [RFC7260]
- Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, , <https://www.rfc-editor.org/info/rfc7260>.
- [RFC7308]
- Osborne, E., "Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)", RFC 7308, DOI 10.17487/RFC7308, , <https://www.rfc-editor.org/info/rfc7308>.
- [RFC7471]
- Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, , <https://www.rfc-editor.org/info/rfc7471>.
- [RFC7551]
- Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, , <https://www.rfc-editor.org/info/rfc7551>.
- [RFC7570]
- Margaria, C., Ed., Martinelli, G., Balls, S., and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, , <https://www.rfc-editor.org/info/rfc7570>.
- [RFC7571]
- Dong, J., Chen, M., Li, Z., and D. Ceccarelli, "GMPLS RSVP-TE Extensions for Lock Instruct and Loopback", RFC 7571, DOI 10.17487/RFC7571, , <https://www.rfc-editor.org/info/rfc7571>.
- [RFC7579]
- Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "General Network Element Constraint Encoding for GMPLS-Controlled Networks", RFC 7579, DOI 10.17487/RFC7579, , <https://www.rfc-editor.org/info/rfc7579>.
- [RFC7823]
- Atlas, A., Drake, J., Giacalone, S., and S. Previdi, "Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions", RFC 7823, DOI 10.17487/RFC7823, , <https://www.rfc-editor.org/info/rfc7823>.
- [RFC8001]
- Zhang, F., Ed., Gonzalez de Dios, O., Ed., Margaria, C., Hartley, M., and Z. Ali, "RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information", RFC 8001, DOI 10.17487/RFC8001, , <https://www.rfc-editor.org/info/rfc8001>.
- [RFC8149]
- Saad, T., Ed., Gandhi, R., Ed., Ali, Z., Venator, R., and Y. Kamite, "RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)", RFC 8149, DOI 10.17487/RFC8149, , <https://www.rfc-editor.org/info/rfc8149>.
- [RFC8169]
- Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., and A. Vainshtein, "Residence Time Measurement in MPLS Networks", RFC 8169, DOI 10.17487/RFC8169, , <https://www.rfc-editor.org/info/rfc8169>.
- [RFC8570]
- Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, , <https://www.rfc-editor.org/info/rfc8570>.
- [RFC9314]
- Jethanandani, M., Ed., Rahman, R., Ed., Zheng, L., Ed., Pallagatti, S., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", RFC 9314, DOI 10.17487/RFC9314, , <https://www.rfc-editor.org/info/rfc9314>.
Appendix A. Changes from RFC 8776
To be added in a future revision of this draft.¶
A.1. TE Types YANG Diffs
RFC Editor: please remove this appendix before publication.¶
This section provides the diff between the YANG module in section 3.1 of [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:¶
30c30 < <mailto:tsaad@juniper.net> --- > <mailto:tsaad.net@gmail.com> 55c55 < Copyright (c) 2020 IETF Trust and the persons identified as --- > Copyright (c) 2023 IETF Trust and the persons identified as 60c60 < the license terms contained in, the Simplified BSD License set --- > the license terms contained in, the Revised BSD License set 65,66c65,99 < 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-03-10 { > description > "Added: > - typedef bandwidth-scientific-notation; > - base identity lsp-provisioning-error-reason; > - identity association-type-diversity; > - identity tunnel-admin-state-auto; > - identity lsp-restoration-restore-none; > - 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. > > Obsoleted: > - identity of-minimize-agg-bandwidth-consumption > - identity of-minimize-load-most-loaded-link > - identity of-minimize-cost-path-set"; > reference > "RFC XXXX: Updated Common YANG Data Types for Traffic > Engineering"; > } > // RFC Editor: replace XXXX with actual RFC number, update date > // information and remove this note 545a579,640 > // CHANGE NOTE: The typedef bandwidth-scientific-notation below > // has been added in this module revision > // RFC Editor: remove the note above and this note > typedef bandwidth-scientific-notation { > type string { > pattern > '0(\.0?)?([eE](\+)?0?)?|' > + '[1-9](\.[0-9]{0,6})?[eE](\+)?(9[0-6]|[1-8][0-9]|0?[0-9])?'; > } > units "bps"; > description > "Bandwidth values, expressed using the scientific notation > in bits per second. > The encoding format is the external decimal-significant > character sequences specified in IEEE 754 and ISO/IEC C99 > for 32-bit decimal floating-point numbers: > (-1)**(S) * 10**(Exponent) * (Significant), > where Significant uses 7 digits. > An implementation for this representation may use decimal32 > or binary32. The range of the Exponent is from -95 to +96 > for decimal32, and from -38 to +38 for binary32. > As a bandwidth value, the format is restricted to be > normalized, non-negative, and non-fraction: > n.dddddde{+}dd, N.DDDDDDE{+}DD, 0e0 or 0E0, > where 'd' and 'D' are decimal digits; 'n' and 'N' are > non-zeror decimal digits; 'e' and 'E' indicate a power of ten. > Some examples are 0e0, 1e10, and 9.953e9."; > reference > "IEEE Std 754-2008: IEEE Standard for Floating-Point > Arithmetic. > ISO/IEC C99: Information technology - Programming > Languages - C."; > } > > // 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."; > } > 606a702,709 > // 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."; > } > 982a1086,1103 > // 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 985c1106 < "Base objective function type."; --- > "Base identity for path objective function type."; 1015a1137,1139 > // 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 1017a1142 > status obsolete; 1020c1145 < consumption."; --- > consumption."; 1023c1148 < Computation Element Communication Protocol (PCEP)"; --- > Computation Element Communication Protocol (PCEP)"; 1025a1151,1153 > // 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 1027a1156 > status obsolete; 1030c1159 < is carrying the highest load."; --- > is carrying the highest load."; 1033c1162 < Computation Element Communication Protocol (PCEP)"; --- > Computation Element Communication Protocol (PCEP)"; 1035a1165,1167 > // 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 1037a1170 > status obsolete; 1216a1350,1361 > // 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."; > } > 1321a1467,1475 > // 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."; > } > 1628a1783,1786 > // 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,1633c1790,1792 < "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,1637c1795,1796 < "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"; 2110a2270,2602 > // 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-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."; > reference > "RFC5440"; > } > > 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."; > reference > "RFC8685"; > } > > 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."; > reference > "RFC8685"; > } > > identity path-computation-error-child-pce-unresponsive { > base path-computation-error-reason; > description > "Path computation has failed because child PCE is not > responsive."; > reference > "RFC8685"; > } > > identity path-computation-error-destination-domain-unknown { > base path-computation-error-reason; > description > "Path computation has failed because the destination domain > was unknown."; > reference > "RFC8685"; > } > > identity path-computation-error-p2mp { > base path-computation-error-reason; > description > "Path computation has failed because of P2MP reachability > problem."; > reference > "RFC8306"; > } > > 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."; > reference > "RFC5557"; > } > > identity path-computation-error-no-gco-solution { > base path-computation-error-reason; > description > "Path computation has failed because of no GCO solution > found."; > reference > "RFC5557"; > } > > identity path-computation-error-path-not-found { > base path-computation-error-reason; > description > "Path computation no path found error reason."; > reference > "RFC5440"; > } > > identity path-computation-error-pks-expansion { > base path-computation-error-reason; > description > "Path computation has failed because of Path-Key Subobject > (PKS) expansion failure."; > reference > "RFC5520"; > } > > identity path-computation-error-brpc-chain-unavailable { > base path-computation-error-reason; > description > "Path computation has failed because PCE BRPC chain > unavailable."; > reference > "RFC5441"; > } > > identity path-computation-error-source-unknown { > base path-computation-error-reason; > description > "Path computation has failed because source node is > unknown."; > reference > "RFC5440"; > } > > identity path-computation-error-destination-unknown { > base path-computation-error-reason; > description > "Path computation has failed because destination node is > unknown."; > reference > "RFC5440"; > } > > identity path-computation-error-no-server { > base path-computation-error-reason; > description > "Path computation has failed because path computation > server is unavailable."; > reference > "RFC5440"; > } > > // 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"; > } > > 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)."; > } > 3379c3871,3898 < } \ 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"; > } > } > }¶
A.2. Packet TE Types YANG Diffs
RFC Editor: please remove this appendix before publication.¶
This section provides the diff between the YANG module in section 3.2 of [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,12 < "RFC 8776: Common YANG Data Types for Traffic Engineering"; --- > "RFCXXXX: Updated Common YANG Data Types for Traffic > Engineering"; 12a14,15 > // RFC Editor: replace XXXX with actual RFC number > // and remove this note 22c25 < <mailto:tsaad@juniper.net> --- > <mailto:tsaad.net@gmail.com> 41c44 < Copyright (c) 2020 IETF Trust and the persons identified as --- > Copyright (c) 2023 IETF Trust and the persons identified as 46c49 < the license terms contained in, the Simplified BSD License set --- > the license terms contained in, the Revised BSD License set 51,52c54,71 < 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-03-10 { > description > "Added common TE packet identities: > - bandwidth-profile-type. > > Added common TE packet groupings: > - te-packet-path-bandwidth; > - te-packet-link-bandwidth."; > reference > "RFC XXXX: Updated Common YANG Data Types for Traffic > Engineering"; > } > // RFC Editor: replace XXXX with actual RFC number, update date > // information and remove this note 61c80,126 < /** --- > /* > * 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"; > } > > /* 180a246,249 > /* > * Groupings > */ > 472a542,617 > } > } > > // 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 "Kbps"; > description > "Committed Information Rate in kilobits per second."; > } > > leaf eir { > type uint64; > units "Kbps"; > /* > Need to indicate that EIR is not supported by RFC 2697 > > must > > '../bw-profile-type = "etht-types:mef-10-bwp" or ' + > '../bw-profile-type = "etht-types:rfc-2698-bwp" or ' + > '../bw-profile-type = "etht-types:rfc-4115-bwp"' > > must > '../bw-profile-type != "etht-types:rfc-2697-bwp"' > */ > description > "Excess Information Rate in kilobits per second. > > In case of RFC 2698: PIR = CIR + EIR"; > } > > leaf cbs { > type uint64; > units "KBytes"; > description > "Committed Burst Size."; > } > > leaf ebs { > type uint64; > units "KBytes"; > description > "Excess Burst Size. > > In case of RFC 2698: PBS = CBS + EBS"; > } > } > > // 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 te-types:bandwidth-scientific-notation; > description > "Available bandwith value expressed in kilobits per > second";¶
Appendix B. Option Considered for updating RFC8776
RFC Editor: please remove this appendix before publication.¶
The concern is how to be able to update the ietf-te-types YANG module published in [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.¶
Acknowledgements
The authors would like to thank Robert Wilton, Lou Berger, Mahesh Jethanandani and Jeff Haas for their valuable input to the discussion about the process to follow to provide tiny updates to a YANG module already published as an RFC.¶
This document was prepared using kramdown.¶