idnits 2.17.1 draft-hopps-lsr-yang-isis-reverse-metric-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 318 has weird spacing: '...mespace urn:i...' -- The document date (21 November 2019) is 1617 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Hopps 3 Internet-Draft LabN Consulting, L.L.C. 4 Intended status: Standards Track 21 November 2019 5 Expires: 24 May 2020 7 YANG Module for IS-IS Reverse Metric 8 draft-hopps-lsr-yang-isis-reverse-metric-02 10 Abstract 12 This document defines a YANG module for managing the reverse metric 13 extension to the the intermediate system to intermediate system 14 routeing protocol. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 24 May 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. YANG Management . . . . . . . . . . . . . . . . . . . . . . . 2 51 2.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 54 3.1. Updates to the IETF XML Registry . . . . . . . . . . . . 7 55 3.2. Updates to the YANG Module Names Registry . . . . . . . . 7 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 5. Normative References . . . . . . . . . . . . . . . . . . . . 8 58 6. Informative References . . . . . . . . . . . . . . . . . . . 9 59 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 60 A.1. Example Enable XML . . . . . . . . . . . . . . . . . . . 9 61 A.2. Example Use XML . . . . . . . . . . . . . . . . . . . . . 10 62 A.3. Example JSON . . . . . . . . . . . . . . . . . . . . . . 11 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 65 1. Introduction 67 This document defines a YANG module for managing the reverse metric 68 extension to the intermediate system to intermediate system routeing 69 protocol (IS-IS) [RFC8500], [ISO10589]. Please refer to [RFC8500] 70 for the description and definition of the functionality managed by 71 this module. 73 The YANG data model described in this document conforms to the 74 Network Management Datastore Architecture defined in [RFC8342]. 76 2. YANG Management 78 2.1. YANG Tree 80 The following is the YANG tree diagram ([RFC8340]) for the IS-IS 81 reverse metric extension additions. 83 module: ietf-isis-reverse-metric 84 augment /rt:routing/rt:control-plane-protocols 85 /rt:control-plane-protocol/isis:isis: 86 +--rw reverse-metric 87 +--rw enable-receive? boolean 88 augment /rt:routing/rt:control-plane-protocols 89 /rt:control-plane-protocol/isis:isis/isis:interfaces 90 /isis:interface: 91 +--rw reverse-metric 92 +--rw reverse-metric 93 | +--rw metric? isis:wide-metric 94 | +--rw flags 95 | | +--rw whole-lan? boolean 96 | | +--rw allow-unreachable? boolean 97 | +--rw exclude-te-metric? boolean 98 +--rw level-1 99 | +--rw reverse-metric 100 | +--rw metric? isis:wide-metric 101 | +--rw flags 102 | | +--rw whole-lan? boolean 103 | | +--rw allow-unreachable? boolean 104 | +--rw exclude-te-metric? boolean 105 +--rw level-2 106 +--rw reverse-metric 107 +--rw metric? isis:wide-metric 108 +--rw flags 109 | +--rw whole-lan? boolean 110 | +--rw allow-unreachable? boolean 111 +--rw exclude-te-metric? boolean 112 augment /rt:routing/rt:control-plane-protocols 113 /rt:control-plane-protocol/isis:isis/isis:interfaces 114 /isis:interface/isis:adjacencies/isis:adjacency: 115 +--ro reverse-metric 116 +--ro metric? isis:wide-metric 117 +--ro flags 118 | +--ro whole-lan? boolean 119 | +--ro allow-unreachable? boolean 120 +--ro te-metric? uint32 122 2.2. YANG Module 124 The following is the YANG module for managing the IS-IS reverse 125 metric functionality defined in [RFC8500]. 127 file "ietf-isis-reverse-metric@2019-11-21.yang" 128 module ietf-isis-reverse-metric { 129 yang-version 1.1; 130 namespace "urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric"; 131 prefix isis-rmetric; 133 import ietf-routing { prefix "rt"; } 134 import ietf-isis { prefix "isis"; } 136 organization 137 "IETF LSR Working Group (LSR)"; 139 contact 140 "WG Web: 141 WG List: 143 Author: Christian Hopps 144 "; 146 // RFC Ed.: replace XXXX with actual RFC number and 147 // remove this note. 149 description 150 "This module defines the configuration and operational state for 151 managing the IS-IS reverse metric functionality [RFC8500]. 153 Copyright (c) 2019 IETF Trust and the persons identified as 154 authors of the code. All rights reserved. 156 Redistribution and use in source and binary forms, with or 157 without modification, is permitted pursuant to, and subject to 158 the license terms contained in, the Simplified BSD License set 159 forth in Section 4.c of the IETF Trust's Legal Provisions 160 Relating to IETF Documents 161 (https://trustee.ietf.org/license-info). 163 This version of this YANG module is part of RFC XXXX 164 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 165 full legal notices."; 167 revision 2019-11-21 { 168 description "Initial Revision"; 169 reference "RFC XXXX: YANG IS-IS Reverse Metric"; 170 } 172 grouping reverse-metric-data { 173 description "IS-IS reverse metric data."; 174 leaf metric { 175 type isis:wide-metric; 176 description "The reverse metric value."; 177 } 179 container flags { 180 description "The reverse metric flag values."; 181 leaf whole-lan { 182 type boolean; 183 description 184 "The 'whole LAN' or W-bit. If true then a DIS processing this 185 reverse metric will add the metric value to all the nodes it 186 advertises in the pseudo-node LSP for this interface. 187 Otherwise it will only increment the metric for the 188 advertising node in the pseudo-node LSP for this interface."; 189 } 190 leaf allow-unreachable { 191 type boolean; 192 description 193 "The 'allow-unreachable' or U-bit. If true it allows the 194 neighbor to increment the overall metric up to 2^24-1 rather 195 than the lesser maximum of 2^24-2, and if done will cause 196 traffic to stop using rather than avoid using the interface."; 197 } 198 } 199 } 201 grouping reverse-metric-if-config-data { 202 description "IS-IS reverse metric config data."; 203 container reverse-metric { 204 description "IS-IS reverse metric data."; 205 uses reverse-metric-data; 206 leaf exclude-te-metric { 207 type boolean; 208 default false; 209 description 210 "If true and there is a TE metric defined for this 211 interface then do not send the TE metric sub-TLV in the 212 reverse metric TLV."; 213 } 214 } 215 } 217 grouping tlv16-reverse-metric { 218 description "IS-IS reverse metric TLV data."; 219 container reverse-metric { 220 description "IS-IS reverse metric TLV data."; 221 uses reverse-metric-data; 222 leaf te-metric { 223 type uint32; 224 description "The TE metric value from the sub-TLV if present."; 225 } 226 } 227 } 229 augment "/rt:routing/rt:control-plane-protocols/" 230 +"rt:control-plane-protocol/" 231 +"isis:isis" { 232 when "../rt:type = 'isis:isis'" { 233 description 234 "This augment is only valid when routing protocol instance 235 type is 'isis'."; 236 } 238 description 239 "The reverse metric configuration for an IS-IS instance."; 241 container reverse-metric { 242 description "Global reverse metric configuration."; 243 leaf enable-receive { 244 type boolean; 245 default false; 246 description 247 "Enable handling of reverse metric announcements from 248 neighbors. By default reverse metric handling is disabled 249 and must be explicitly enabled through this configuration."; 250 } 251 } 252 } 254 augment "/rt:routing/rt:control-plane-protocols/" 255 +"rt:control-plane-protocol/" 256 +"isis:isis/isis:interfaces/isis:interface" { 257 when "../../../rt:type = 'isis:isis'" { 258 description 259 "This augment is only valid when routing protocol instance 260 type is 'isis'."; 261 } 263 description 264 "The reverse metric configuration for an interface."; 266 container reverse-metric { 267 description "Announce a reverse metric to neighbors."; 268 uses reverse-metric-if-config-data; 269 container level-1 { 270 description "Announce a reverse metric to level-1 neighbors."; 271 uses reverse-metric-if-config-data; 272 } 273 container level-2 { 274 description "Announce a reverse metric to level-2 neighbors."; 275 uses reverse-metric-if-config-data; 276 } 277 } 278 } 279 augment "/rt:routing/rt:control-plane-protocols/" 280 +"rt:control-plane-protocol/" 281 +"isis:isis/isis:interfaces/isis:interface/" 282 +"isis:adjacencies/isis:adjacency" { 283 when "../../../../../rt:type = 'isis:isis'" { 284 description 285 "This augment is only valid when routing protocol instance 286 type is 'isis'"; 287 } 289 description 290 "The reverse metric state advertised by an adjacency."; 291 uses tlv16-reverse-metric; 292 } 293 } 294 296 3. IANA Considerations 298 3.1. Updates to the IETF XML Registry 300 This document registers a URI in the "IETF XML Registry" [RFC3688]. 301 Following the format in [RFC3688], the following registration has 302 been made: 304 URI urn:ietf:params:xml:ns:yang:ietf-isis-reverse- 305 metric 307 Registrant Contact The IESG. 309 XML N/A; the requested URI is an XML namespace. 311 3.2. Updates to the YANG Module Names Registry 313 This document registers one YANG module in the "YANG Module Names" 314 registry [RFC6020]. Following the format in [RFC6020], the following 315 registration has been made: 317 name ietf-isis-reverse-metric 318 namespace urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric 320 prefix isis-rmetric 322 reference RFC XXXX (RFC Ed.: replace XXX with actual RFC number and 323 remove this note.) 325 4. Security Considerations 327 The YANG module specified in this document defines a schema for data 328 that is designed to be accessed via network management protocols such 329 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 330 is the secure transport layer, and the mandatory-to-implement secure 331 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 332 is HTTPS, and the mandatory-to-implement secure transport is TLS 333 [RFC8446]. 335 The Network Configuration Access Control Model (NACM) [RFC8341] 336 provides the means to restrict access for particular NETCONF or 337 RESTCONF users to a preconfigured subset of all available NETCONF or 338 RESTCONF protocol operations and content. 340 The YANG module defined in this document can enable, disable and 341 modify the behavior of metrics used by routing. For the security 342 implications regarding these types of changes consult the [RFC8500] 343 which defines the functionality. 345 5. Normative References 347 [ISO10589] International Organization for Standardization, 348 "Intermediate system to intermediate system intra-domain- 349 routing routine information exchange protocol for use in 350 conjunction with the protocol for providing the 351 connectionless-mode Network Service (ISO 8473)", 352 ISO Standard 10589, 1992. 354 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 355 DOI 10.17487/RFC3688, January 2004, 356 . 358 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 359 the Network Configuration Protocol (NETCONF)", RFC 6020, 360 DOI 10.17487/RFC6020, October 2010, 361 . 363 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 364 and A. Bierman, Ed., "Network Configuration Protocol 365 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 366 . 368 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 369 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 370 . 372 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 373 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 374 . 376 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 377 Access Control Model", STD 91, RFC 8341, 378 DOI 10.17487/RFC8341, March 2018, 379 . 381 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 382 and R. Wilton, "Network Management Datastore Architecture 383 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 384 . 386 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 387 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 388 . 390 [RFC8500] Shen, N., Amante, S., and M. Abrahamsson, "IS-IS Routing 391 with Reverse Metric", RFC 8500, DOI 10.17487/RFC8500, 392 February 2019, . 394 6. Informative References 396 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 397 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 398 . 400 Appendix A. Examples 402 A.1. Example Enable XML 404 Below is an example of YANG XML data to enable reverse metric 405 processing. 407 411 412 413 isis:isis 414 default 415 416 00 417 418 true 419 420 421 422 423 425 Figure 1: Example XML data to enable reverse metric processing. 427 A.2. Example Use XML 429 Below is an example of YANG XML data for the ietf-isis-reverse-metric 430 module. 432 435 436 eth0 437 ianaift:ethernetCsmacd 438 439 440 444 445 446 isis:isis 447 default 448 449 00 450 451 452 eth0 453 454 455 456 65535 457 458 459 460 461 462 463 464 465 467 Figure 2: Example XML data for ietf-isis-reverse-metric module. 469 A.3. Example JSON 471 Below is an example of YANG XML data for the ietf-isis-reverse-metric 472 module. 474 { 475 "ietf-interfaces:interfaces": { 476 "interface": [ 477 { 478 "name": "eth0", 479 "type": "iana-if-type:ethernetCsmacd" 480 } 481 ] 482 }, 483 "ietf-routing:routing": { 484 "control-plane-protocols": { 485 "control-plane-protocol": [ 486 { 487 "type": "ietf-isis:isis", 488 "name": "default", 489 "ietf-isis:isis": { 490 "area-address": [ 491 "00" 492 ], 493 "interfaces": { 494 "interface": [ 495 { 496 "name": "eth0", 497 "ietf-isis-reverse-metric:reverse-metric": { 498 "level-1": { 499 "reverse-metric": { 500 "metric": 65535, 501 "exclude-te-metric": true 502 } 503 } 504 } 505 } 506 ] 507 } 508 } 509 } 510 ] 511 } 512 } 513 } 515 Figure 3: Example JSON data for level-1 only reverse metric. 517 Author's Address 519 Christian Hopps 520 LabN Consulting, L.L.C. 522 Email: chopps@chopps.org