idnits 2.17.1 draft-ietf-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 13 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 334 has weird spacing: '...mespace urn:i...' -- The document date (18 December 2020) is 1225 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 18 December 2020 5 Expires: 21 June 2021 7 YANG Module for IS-IS Reverse Metric 8 draft-ietf-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 21 June 2021. 33 Copyright Notice 35 Copyright (c) 2020 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 . . . . . . . . 8 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 5. Normative References . . . . . . . . . . . . . . . . . . . . 10 58 6. Informative References . . . . . . . . . . . . . . . . . . . 11 59 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 60 A.1. Example Enable XML . . . . . . . . . . . . . . . . . . . 11 61 A.2. Example Use XML . . . . . . . . . . . . . . . . . . . . . 12 62 A.3. Example JSON . . . . . . . . . . . . . . . . . . . . . . 13 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 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]. It imports modules from 126 the following RFCs: [RFC8349], [I-D.ietf-isis-yang-isis-cfg]. 128 file "ietf-isis-reverse-metric@2020-12-18.yang" 129 module ietf-isis-reverse-metric { 130 yang-version 1.1; 131 namespace "urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric"; 132 prefix isis-rmetric; 134 import ietf-routing { 135 prefix rt; 136 reference 137 "RFC8349: A YANG Data Model for Routing Management (NMDA Version)"; 138 } 139 import ietf-isis { 140 prefix isis; 141 reference 142 "draft-ietf-isis-yang-isis-cfg-42: 143 YANG Data Model for IS-IS Protocol"; 144 } 146 organization 147 "IETF LSR Working Group (LSR)"; 149 contact 150 "WG Web: 151 WG List: 153 Author: Christian Hopps 154 "; 156 // RFC Ed.: replace XXXX with actual RFC number and 157 // remove this note. 159 description 160 "This module defines the configuration and operational state for 161 managing the IS-IS reverse metric functionality [RFC8500]. 163 Copyright (c) 2019 IETF Trust and the persons identified as 164 authors of the code. All rights reserved. 166 Redistribution and use in source and binary forms, with or 167 without modification, is permitted pursuant to, and subject to 168 the license terms contained in, the Simplified BSD License set 169 forth in Section 4.c of the IETF Trust's Legal Provisions 170 Relating to IETF Documents 171 (https://trustee.ietf.org/license-info). 173 This version of this YANG module is part of RFC XXXX 174 (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for 175 full legal notices."; 177 revision 2020-12-18 { 178 description "Initial Revision"; 179 reference "RFC XXXX: YANG IS-IS Reverse Metric"; 180 } 182 grouping reverse-metric-data { 183 description "IS-IS reverse metric data."; 184 leaf metric { 185 type isis:wide-metric; 186 description "The reverse metric value."; 187 reference "RFC8500, Section 2"; 188 } 190 container flags { 191 description "The reverse metric flag values."; 192 leaf whole-lan { 193 type boolean; 194 description 195 "The 'whole LAN' or W-bit. If true then a DIS processing this 196 reverse metric will add the metric value to all the nodes it 197 advertises in the pseudo-node LSP for this interface. 198 Otherwise it will only increment the metric for the 199 advertising node in the pseudo-node LSP for this interface."; 200 reference "RFC8500, Section 2"; 201 } 202 leaf allow-unreachable { 203 type boolean; 204 description 205 "The 'allow-unreachable' or U-bit. If true it allows the 206 neighbor to increment the overall metric up to 2^24-1 rather 207 than the lesser maximum of 2^24-2, and if done will cause 208 traffic to stop using rather than avoid using the interface."; 209 reference "RFC8500, Section 2"; 210 } 211 } 212 } 214 grouping reverse-metric-if-config-data { 215 description "IS-IS reverse metric config data."; 216 container reverse-metric { 217 description "IS-IS reverse metric data."; 218 uses reverse-metric-data; 219 leaf exclude-te-metric { 220 type boolean; 221 default false; 222 description 223 "If true and there is a TE metric defined for this 224 interface then do not send the TE metric sub-TLV in the 225 reverse metric TLV."; 226 reference "RFC8500, Section 3.5"; 227 } 228 } 229 } 231 grouping tlv16-reverse-metric { 232 description "IS-IS reverse metric TLV data."; 233 container reverse-metric { 234 description "IS-IS reverse metric TLV data."; 235 uses reverse-metric-data; 236 leaf te-metric { 237 type uint32; 238 description "The TE metric value from the sub-TLV if present."; 239 reference "RFC8500, Section 3.5"; 240 } 241 } 242 } 244 augment "/rt:routing/rt:control-plane-protocols/" 245 +"rt:control-plane-protocol/" 246 +"isis:isis" { 247 when "derived-from-or-self(../rt:type, 'isis:isis')" { 248 description 249 "This augment is only valid when routing protocol instance 250 type is 'isis'."; 251 } 253 description 254 "The reverse metric configuration for an IS-IS instance."; 256 container reverse-metric { 257 description "Global reverse metric configuration."; 258 leaf enable-receive { 259 type boolean; 260 default false; 261 description 262 "Enable handling of reverse metric announcements from 263 neighbors. By default reverse metric handling is disabled 264 and must be explicitly enabled through this configuration."; 265 } 266 } 267 } 269 augment "/rt:routing/rt:control-plane-protocols/" 270 +"rt:control-plane-protocol/" 271 +"isis:isis/isis:interfaces/isis:interface" { 272 when "derived-from-or-self(../../../rt:type, 'isis:isis')" { 273 description 274 "This augment is only valid when routing protocol instance 275 type is 'isis'."; 276 } 278 description 279 "The reverse metric configuration for an interface."; 281 container reverse-metric { 282 description "Announce a reverse metric to neighbors."; 283 uses reverse-metric-if-config-data; 284 container level-1 { 285 description "Announce a reverse metric to level-1 neighbors."; 286 uses reverse-metric-if-config-data; 287 } 288 container level-2 { 289 description "Announce a reverse metric to level-2 neighbors."; 290 uses reverse-metric-if-config-data; 291 } 292 } 293 } 294 augment "/rt:routing/rt:control-plane-protocols/" 295 +"rt:control-plane-protocol/" 296 +"isis:isis/isis:interfaces/isis:interface/" 297 +"isis:adjacencies/isis:adjacency" { 298 when "derived-from-or-self(../../../../../rt:type, 'isis:isis')" { 299 description 300 "This augment is only valid when routing protocol instance 301 type is 'isis'"; 302 } 304 description 305 "The reverse metric state advertised by an adjacency."; 306 uses tlv16-reverse-metric; 307 } 308 } 309 311 3. IANA Considerations 313 3.1. Updates to the IETF XML Registry 315 This document registers a URI in the "IETF XML Registry" [RFC3688]. 316 Following the format in [RFC3688], the following registration has 317 been made: 319 URI urn:ietf:params:xml:ns:yang:ietf-isis-reverse- 320 metric 322 Registrant Contact The IESG. 324 XML N/A; the requested URI is an XML namespace. 326 3.2. Updates to the YANG Module Names Registry 328 This document registers one YANG module in the "YANG Module Names" 329 registry [RFC6020]. Following the format in [RFC6020], the following 330 registration has been made: 332 name ietf-isis-reverse-metric 334 namespace urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric 336 prefix isis-rmetric 338 reference RFC XXXX (RFC Ed.: replace XXX with actual RFC number and 339 remove this note.) 341 4. Security Considerations 343 The YANG module specified in this document defines a schema for data 344 that is designed to be accessed via network management protocols such 345 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 346 is the secure transport layer, and the mandatory-to-implement secure 347 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 348 is HTTPS, and the mandatory-to-implement secure transport is TLS 349 [RFC8446]. 351 The NETCONF access control model [RFC8341] provides the means to 352 restrict access for particular NETCONF or RESTCONF users to a 353 preconfigured subset of all available NETCONF or RESTCONF protocol 354 operations and content. 356 The YANG module defined in this document can enable, disable and 357 modify the behavior of metrics used by routing. For the security 358 implications regarding these types of changes consult the [RFC8500] 359 which defines the functionality. 361 There are a number of data nodes defined in this YANG module that are 362 writable/creatable/deletable (i.e., "config true", which is the 363 default). These data nodes may be considered sensitive or vulnerable 364 in some network environments. Write operations (e.g., edit-config) 365 to these data nodes without proper protection can have a negative 366 effect on network operations. 368 These are the subtrees and data nodes and their sensitivity/ 369 vulnerability: 371 Under "/rt:routing/rt:control-plane-protocols/" + 372 "rt:control-plane-protocol/isis:isis" 374 - /isis-rmetric:reverse-metric/isis-rmetric:enable-receive 376 Under "/rt:routing/rt:control-plane-protocols/" + 377 "rt:control-plane-protocol/isis:isis/" + 378 "isis:interfaces/isis:interface/" + 379 "isis-rmetric:reverse-metric" 381 - /isis-rmetric:metric 382 - /isis-rmetric:flags/isis-rmetric:whole-lan 383 - /isis-rmetric:flags/isis-rmetric:allow-unreachable 384 - /isis-rmetric:exclude-te-metric 386 Under "/rt:routing/rt:control-plane-protocols/" + 387 "rt:control-plane-protocol/isis:isis/" + 388 "isis:interfaces/isis:interface/" + 389 "isis:level-1/isis-rmetric:reverse-metric" 391 - /isis-rmetric:metric 392 - /isis-rmetric:flags/isis-rmetric:whole-lan 393 - /isis-rmetric:flags/isis-rmetric:allow-unreachable 394 - /isis-rmetric:exclude-te-metric 396 Under "/rt:routing/rt:control-plane-protocols/" + 397 "rt:control-plane-protocol/isis:isis/" + 398 "isis:interfaces/isis:interface/" + 399 "isis:level-2/isis-rmetric:reverse-metric" 401 - /isis-rmetric:metric 402 - /isis-rmetric:flags/isis-rmetric:whole-lan 403 - /isis-rmetric:flags/isis-rmetric:allow-unreachable 404 - /isis-rmetric:exclude-te-metric 406 Some of the readable data nodes in this YANG module may be considered 407 sensitive or vulnerable in some network environments. It is thus 408 important to control read access (e.g., via get, get-config, or 409 notification) to these data nodes. These are the subtrees and data 410 nodes and their sensitivity/vulnerability: 412 All nodes are under the following subtree, so that prefix will be 413 assume for each node description. 415 Under "/rt:routing/rt:control-plane-protocols/" + 416 "rt:control-plane-protocol/isis:isis/" + 417 "isis:interfaces/isis:interface/" + 418 "isis:adjacencies/isis:adjacency/" + 419 "isis-rmetric:reverse-metric" 421 - /isis-rmetric:metric 422 - /isis-rmetric:flags/isis-rmetric:whole-lan 423 - /isis-rmetric:flags/isis-rmetric:allow-unreachable 424 - /isis-rmetric:te-metric 426 5. Normative References 428 [I-D.ietf-isis-yang-isis-cfg] 429 Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L. 430 Lhotka, "YANG Data Model for IS-IS Protocol", draft-ietf- 431 isis-yang-isis-cfg-42 (work in progress), 15 October 2019, 432 . 435 [ISO10589] International Organization for Standardization, 436 "Intermediate system to intermediate system intra-domain- 437 routing routine information exchange protocol for use in 438 conjunction with the protocol for providing the 439 connectionless-mode Network Service (ISO 8473)", 440 ISO Standard 10589, 1992. 442 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 443 DOI 10.17487/RFC3688, January 2004, 444 . 446 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 447 the Network Configuration Protocol (NETCONF)", RFC 6020, 448 DOI 10.17487/RFC6020, October 2010, 449 . 451 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 452 and A. Bierman, Ed., "Network Configuration Protocol 453 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 454 . 456 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 457 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 458 . 460 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 461 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 462 . 464 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 465 Access Control Model", STD 91, RFC 8341, 466 DOI 10.17487/RFC8341, March 2018, 467 . 469 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 470 and R. Wilton, "Network Management Datastore Architecture 471 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 472 . 474 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 475 Routing Management (NMDA Version)", RFC 8349, 476 DOI 10.17487/RFC8349, March 2018, 477 . 479 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 480 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 481 . 483 [RFC8500] Shen, N., Amante, S., and M. Abrahamsson, "IS-IS Routing 484 with Reverse Metric", RFC 8500, DOI 10.17487/RFC8500, 485 February 2019, . 487 6. Informative References 489 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 490 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 491 . 493 Appendix A. Examples 495 A.1. Example Enable XML 497 Below is an example of XML instance data to enable reverse metric 498 processing. 500 504 505 506 isis:isis 507 default 508 509 00 510 511 true 512 513 514 515 516 518 Figure 1: Example XML data to enable reverse metric processing. 520 A.2. Example Use XML 522 Below is an example of XML instance data for the ietf-isis-reverse- 523 metric module. 525 528 529 eth0 530 ianaift:ethernetCsmacd 531 532 533 537 538 539 isis:isis 540 default 541 542 00 543 544 545 eth0 546 547 548 549 65535 550 551 552 553 554 555 556 557 558 560 Figure 2: Example XML data for ietf-isis-reverse-metric module. 562 A.3. Example JSON 564 Below is an example of JSON instance data for the ietf-isis-reverse- 565 metric module. 567 { 568 "ietf-interfaces:interfaces": { 569 "interface": [ 570 { 571 "name": "eth0", 572 "type": "iana-if-type:ethernetCsmacd" 573 } 574 ] 575 }, 576 "ietf-routing:routing": { 577 "control-plane-protocols": { 578 "control-plane-protocol": [ 579 { 580 "type": "ietf-isis:isis", 581 "name": "default", 582 "ietf-isis:isis": { 583 "area-address": [ 584 "00" 585 ], 586 "interfaces": { 587 "interface": [ 588 { 589 "name": "eth0", 590 "ietf-isis-reverse-metric:reverse-metric": { 591 "level-1": { 592 "reverse-metric": { 593 "metric": 65535, 594 "exclude-te-metric": true 595 } 596 } 597 } 598 } 599 ] 600 } 601 } 602 } 603 ] 604 } 605 } 606 } 608 Figure 3: Example JSON data for level-1 only reverse metric. 610 Author's Address 612 Christian Hopps 613 LabN Consulting, L.L.C. 615 Email: chopps@chopps.org