RFC 9194
A YANG Module for IS-IS Reverse Metric
A YANG Module for IS-IS Reverse Metric 🦋
okay bestie, this is RFC 9194 and it's giving "official standards-track spec" energy 💅
- Series and number: Request for Comments 9194 from the Internet Engineering Task Force (IETF) 🌸
- Author: C. Hopps, LabN Consulting, L.L.C. ✨
- Category: Standards Track, so this is an official Internet Standard 👑
- Date: October 2022 📅
- ISSN: 2070-1721 🔥
- Obsoletes or updates: the header doesn't list anything this one obsoletes or updates, so it's standing on its own 💜
Abstract
okay so this doc defines a YANG module for managing the reverse metric extension to the Intermediate System to Intermediate System (IS-IS) intra-domain routing information exchange protocol 🧚
Status of This Memo
this is an Internet Standards Track document 🎀
it's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💅 if you want more about Internet Standards, check out Section 2 of RFC 7841 📖
for the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9194 🦋
Copyright Notice
Copyright (c) 2022 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) as they stand on the publication date 📜 please actually read them, because they explain your rights and restrictions for this document 🙈 any Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 💀
Table of Contents 📚
1. Introduction
2. YANG Management
2.1. YANG Tree
2.2. YANG Module
3. IANA Considerations
3.1. Updates to the IETF XML Registry
3.2. Updates to the YANG Module Names Registry
4. Security Considerations
5. Normative References
6. Informative References
Appendix A. Examples
A.1. Enablement Example Using XML YANG Instance Data
A.2. Usage Example Using XML YANG Instance Data
A.3. Usage Example Using JSON YANG Instance Data
Author's Address1. Introduction ✨
okay so this doc defines a YANG module for managing the reverse metric extension to IS-IS [RFC8500] [ISO-10589] 🌸 if you want the description and definition of what this module manages, go read [RFC8500] 📖
the YANG data model in here follows the Network Management Datastore Architecture defined in [RFC8342] 💜 that's the big-brain architecture part, bestie 🧠✨
2. YANG Management 🎀
2.1. YANG Tree 🌳
this is the YANG tree diagram [RFC8340] for the IS-IS reverse metric extension additions 🦋
module: ietf-isis-reverse-metric
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis:
+--rw reverse-metric
+--rw enable-receive? boolean
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:interfaces
/isis:interface:
+--rw reverse-metric
+--rw metric? isis:wide-metric
+--rw flags
| +--rw whole-lan? boolean
| +--rw allow-unreachable? boolean
+--rw exclude-te-metric? boolean
+--rw level-1
| +--rw metric? isis:wide-metric
| +--rw flags
| | +--rw whole-lan? boolean
| | +--rw allow-unreachable? boolean
| +--rw exclude-te-metric? boolean
+--rw level-2
+--rw metric? isis:wide-metric
+--rw flags
| +--rw whole-lan? boolean
| +--rw allow-unreachable? boolean
+--rw exclude-te-metric? boolean
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:interfaces
/isis:interface/isis:adjacencies/isis:adjacency:
+--ro reverse-metric
+--ro metric? isis:wide-metric
+--ro flags
| +--ro whole-lan? boolean
| +--ro allow-unreachable? boolean
+--ro te-metric? uint322.2. YANG Module
okay so this is the actual YANG module bestie 💅 it manages the IS-IS reverse metric stuff from [RFC8500] ✨ and it pulls in bits from [RFC8349] and [RFC9130] 🦋. it uses the same per-level hierarchical config structure as the augmented base module, so if you've already met that one, you're basically winning 🏆
<CODE BEGINS> file "ietf-isis-reverse-metric@2022-10-19.yang"
module ietf-isis-reverse-metric {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric";
prefix isis-rmetric;
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
import ietf-isis {
prefix isis;
reference
"RFC 9130: YANG Data Model for the IS-IS Protocol";
}
organization
"IETF LSR Working Group (LSR)";
contact
"WG Web: <https://datatracker.ietf.org/wg/lsr/>
WG List: <mailto:lsr@ietf.org>
Author: Christian Hopps
<mailto:chopps@chopps.org>";
description
"This module defines the configuration and operational state
for managing the IS-IS reverse metric functionality
(RFC 8500).
Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9194; see the
RFC itself for full legal notices.";
reference
"RFC 8500: IS-IS Routing with Reverse Metric";
revision 2022-10-19 {
description
"Initial revision.";
reference
"RFC 9194: A YANG Module for IS-IS Reverse Metric";
}
grouping reverse-metric-data {
description
"IS-IS reverse metric data.";
leaf metric {
type isis:wide-metric;
description
"The reverse metric value.";
reference
"RFC 8500: IS-IS Routing with Reverse Metric, Section 2";
}
container flags {
description
"The reverse metric flag values.";
leaf whole-lan {
type boolean;
description
"The 'Whole LAN' bit (W bit) (RFC 8500). If true, then
a Designated Intermediate System (DIS) processing this
reverse metric will add the metric value to all the
nodes it advertises in the pseudonode Link State
Protocol Data Unit (LSP) for this interface.
Otherwise, it will only increment the metric for the
advertising node in the pseudonode LSP for this
interface.";
reference
"RFC 8500: IS-IS Routing with Reverse Metric,
Section 2";
}
leaf allow-unreachable {
type boolean;
description
"The 'Unreachable' bit (U bit) (RFC 8500). If true, it
allows the neighbor to increment the overall metric up
to 2^24-1 rather than the lesser maximum of 2^24-2.
If the metric is then set by the neighbor to 2^24-1,
it will cause traffic to stop using, rather than avoid
using, the interface.";
reference
"RFC 8500: IS-IS Routing with Reverse Metric,
Section 2";
}
}
}
grouping reverse-metric-if-config-data {
description
"IS-IS reverse metric config data.";
uses reverse-metric-data;
leaf exclude-te-metric {
type boolean;
default "false";
description
"If true and there is a TE metric defined for this
interface, then do not send the Traffic Engineering
Metric sub-TLV in the Reverse Metric TLV.";
reference
"RFC 8500: IS-IS Routing with Reverse Metric, Section 2";
}
}
grouping tlv16-reverse-metric {
description
"IS-IS Reverse Metric TLV data.";
uses reverse-metric-data;
leaf te-metric {
type uint32;
description
"The TE metric value from the sub-TLV, if present.";
reference
"RFC 8500: IS-IS Routing with Reverse Metric, Section 2";
}
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/"
+ "isis:isis" {
when "derived-from-or-self(../rt:type, 'isis:isis')" {
description
"This augment is only valid when the routing protocol
instance type is 'isis'.";
}
description
"The reverse metric configuration for an IS-IS instance.";
container reverse-metric {
description
"Global reverse metric configuration.";
leaf enable-receive {
type boolean;
default "false";
description
"Enables handling of reverse metric announcements from
neighbors. By default, reverse metric handling is
disabled and must be explicitly enabled through this
configuration.";
}
}
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/"
+ "isis:isis/isis:interfaces/isis:interface" {
when "derived-from-or-self(../../../rt:type, 'isis:isis')" {
description
"This augment is only valid when the routing protocol
instance type is 'isis'.";
}
description
"The reverse metric configuration for an interface.";
container reverse-metric {
description
"Announces a reverse metric to neighbors. The
configuration is hierarchical and follows the same
behavior as that defined for per-level values in the
augmented base module.
Reverse metric operation is enabled by the configuration
of a 'reverse-metric' metric value either at the top
level or under a level-specific container node. If a
'reverse-metric' metric value is only specified under a
level-specific container node, then operation is only
enabled at the specified level.
As the reverse metric is advertised in IS-IS Hello
Protocol Data Units (IIH PDUs), level-specific
configuration is only available for broadcast interface
types.";
uses reverse-metric-if-config-data {
refine "flags/whole-lan" {
default "false";
}
refine "flags/allow-unreachable" {
default "false";
}
}
container level-1 {
when '../../isis:interface-type = "broadcast"';
description
"Announces a reverse metric to level-1 neighbors.";
uses reverse-metric-if-config-data;
}
container level-2 {
when '../../isis:interface-type = "broadcast"';
description
"Announces a reverse metric to level-2 neighbors.";
uses reverse-metric-if-config-data;
}
}
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/"
+ "isis:isis/isis:interfaces/isis:interface/"
+ "isis:adjacencies/isis:adjacency" {
when "derived-from-or-self(../../../../../rt:type,
'isis:isis')" {
description
"This augment is only valid when the routing protocol
instance type is 'isis'.";
}
description
"The reverse metric state advertised by an adjacency.";
container reverse-metric {
description
"IS-IS Reverse Metric TLV data.";
uses tlv16-reverse-metric;
}
}
}
<CODE ENDS>3. IANA Considerations ✨
3.1. Updates to the IETF XML Registry 🎀
so this doc registers a URI in the "IETF XML Registry" [RFC3688] 🌸. following the format in [RFC3688], the registration looks like this:
URI: urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.3.2. Updates to the YANG Module Names Registry 🧚
this doc registers one YANG module in the "YANG Module Names" registry [RFC6020] 💜. following the format in [RFC6020], the registration looks like this:
Name: ietf-isis-reverse-metric
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric
Prefix: isis-rmetric
Reference: RFC 91944. Security Considerations 🔐
okay bestie, security time 😭🔒 this YANG module is a schema for data that gets accessed through network management protocols like NETCONF [RFC6241] or RESTCONF [RFC8040]. The bottom layer of NETCONF is the secure transport layer, and its mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The bottom layer of RESTCONF is HTTPS, and its mandatory-to-implement secure transport is TLS [RFC8446]. ✨
The Network Configuration Access Control Model (NACM) [RFC8341] is how you restrict access for particular NETCONF or RESTCONF users. You get to limit them to a preconfigured subset of all the available NETCONF or RESTCONF protocol operations and content. It's giving gatekeeper energy 💅
The YANG module defined in this document can enable, disable, and modify the behavior of metrics used by routing. For the security implications of those changes, check out [RFC8500], which defines the functionality, and [RFC9130] too 🧚
⚠️ Heads up: there are a bunch of data nodes in this module that are writable, creatable, and deletable (that's config true, which is the default). These nodes may be considered sensitive or vulnerable in some network environments. Write operations (like edit-config) to these nodes without proper protection can have a negative effect on network operations. These YANG nodes correspond directly to the functionality in RFC 8500, and the security considerations of that functionality are described in RFC 8500 too. Here are the subtrees and data nodes 👇
Under the following path:
"/rt:routing/rt:control-plane-protocols/" +
"rt:control-plane-protocol/isis:isis"/isis-rmetric:reverse-metric/isis-rmetric:enable-receive
Under the following path:
"/rt:routing/rt:control-plane-protocols/" +
"rt:control-plane-protocol/isis:isis/" +
"isis:interfaces/isis:interface/" +
"isis-rmetric:reverse-metric"/isis-rmetric:metric/isis-rmetric:flags/isis-rmetric:whole-lan/isis-rmetric:flags/isis-rmetric:allow-unreachable/isis-rmetric:exclude-te-metric
Under the following path:
"/rt:routing/rt:control-plane-protocols/" +
"rt:control-plane-protocol/isis:isis/" +
"isis:interfaces/isis:interface/" +
"isis-rmetric:reverse-metric/" +
"isis-rmetric:level-1/"/isis-rmetric:metric/isis-rmetric:flags/isis-rmetric:whole-lan/isis-rmetric:flags/isis-rmetric:allow-unreachable/isis-rmetric:exclude-te-metric
Under the following path:
"/rt:routing/rt:control-plane-protocols/" +
"rt:control-plane-protocol/isis:isis/" +
"isis:interfaces/isis:interface/" +
"isis-rmetric:reverse-metric/" +
"isis-rmetric:level-2/"/isis-rmetric:metric/isis-rmetric:flags/isis-rmetric:whole-lan/isis-rmetric:flags/isis-rmetric:allow-unreachable/isis-rmetric:exclude-te-metric
Some of the readable data nodes in this module may be considered sensitive or vulnerable in some network environments, so it's really important to control read access to them (for example, via get, get-config, or notification) 🙈 These YANG nodes also correspond directly to the functionality in RFC 8500, and that functionality's security considerations are described in RFC 8500. Here are the subtrees and data nodes:
Under the following path:
"/rt:routing/rt:control-plane-protocols/" +
"rt:control-plane-protocol/isis:isis/" +
"isis:interfaces/isis:interface/" +
"isis:adjacencies/isis:adjacency/" +
"isis-rmetric:reverse-metric"/isis-rmetric:metric/isis-rmetric:flags/isis-rmetric:whole-lan/isis-rmetric:flags/isis-rmetric:allow-unreachable/isis-rmetric:te-metric
5. Normative References 📚
The references below are the normative ones, the ones you really need to read before you can say you're caught up 🤓
[ISO-10589]
ISO, "Intermediate System to Intermediate System intra-
domain routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)",
International Standard 10589: 2002, Second Edition, 2002,
<https://www.iso.org/standard/30932.html>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<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, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8500] Shen, N., Amante, S., and M. Abrahamsson, "IS-IS Routing
with Reverse Metric", RFC 8500, DOI 10.17487/RFC8500,
February 2019, <https://www.rfc-editor.org/info/rfc8500>.
[RFC9130] Litkowski, S., Ed., Yeung, D., Lindem, A., Zhang, J., and
L. Lhotka, "YANG Data Model for the IS-IS Protocol",
RFC 9130, DOI 10.17487/RFC9130, October 2022,
<https://www.rfc-editor.org/info/rfc9130>.
[W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126>.6. Informative References 💡
Here's the extra reading that's nice to know but isn't required 🌸
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.Appendix A. Examples 🎀
A.1. Enablement Example Using XML YANG Instance Data
Okay, here's an example of XML [W3C.REC-xml-20081126] YANG instance data [RFC8342] that turns on reverse metric processing. Look at that structure 🥰
<rt:routing
xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"
xmlns:isis="urn:ietf:params:xml:ns:yang:ietf-isis"
xmlns:isis-rmetric=
"urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric">
<rt:control-plane-protocols>
<rt:control-plane-protocol>
<rt:type>isis:isis</rt:type>
<rt:name>default</rt:name>
<isis:isis>
<isis:area-address>00</isis:area-address>
<isis-rmetric:reverse-metric>
<isis-rmetric:enable-receive>true</isis-rmetric:enable-receive>
</isis-rmetric:reverse-metric>
</isis:isis>
</rt:control-plane-protocol>
</rt:control-plane-protocols>
</rt:routing>Figure 1: Example XML Data to Enable Reverse Metric Processing
A.2. Usage Example Using XML YANG Instance Data
Next up, an example of XML YANG instance data [RFC8342] for the "ietf-isis-reverse-metric" module. Slay 💅✨
<if:interfaces
xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
<if:interface>
<if:name>eth0</if:name>
<if:type>ianaift:ethernetCsmacd</if:type>
</if:interface>
</if:interfaces>
<rt:routing
xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"
xmlns:isis="urn:ietf:params:xml:ns:yang:ietf-isis"
xmlns:isis-rmetric=
"urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric">
<rt:control-plane-protocols>
<rt:control-plane-protocol>
<rt:type>isis:isis</rt:type>
<rt:name>default</rt:name>
<isis:isis>
<isis:area-address>00</isis:area-address>
<isis:interfaces>
<isis:interface>
<isis:name>eth0</isis:name>
<isis-rmetric:reverse-metric>
<isis-rmetric:metric>
65535
</isis-rmetric:metric>
</isis-rmetric:reverse-metric>
</isis:interface>
</isis:interfaces>
</isis:isis>
</rt:control-plane-protocol>
</rt:control-plane-protocols>
</rt:routing>Figure 2: Example XML Data for the "ietf-isis-reverse-metric" Module
A.3. Usage Example Using JSON YANG Instance Data
And last but not least, the JSON version of YANG instance data [RFC7951] for the "ietf-isis-reverse-metric" module. Same vibes, different format 🦋
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"type": "iana-if-type:ethernetCsmacd"
}
]
},
"ietf-routing:routing": {
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-isis:isis",
"name": "default",
"ietf-isis:isis": {
"area-address": [
"00"
],
"interfaces": {
"interface": [
{
"name": "eth0",
"ietf-isis-reverse-metric:reverse-metric": {
"level-1": {
"metric": 65535,
"exclude-te-metric": true
}
}
}
]
}
}
}
]
}
}
}Figure 3: Example JSON Data for the Level-1-Only Reverse Metric
Author's Address 💌
Christian Hopps
LabN Consulting, L.L.C.
Email: chopps@chopps.org📦 where this page comes from
- ietf: rfc9194 2022-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms