idnits 2.17.1 draft-ietf-spring-sr-yang-18.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 156 has weird spacing: '...terface if:...' == Line 186 has weird spacing: '...r-bound uin...' == Line 187 has weird spacing: '...r-bound uin...' == Line 190 has weird spacing: '...r-bound uin...' == Line 191 has weird spacing: '...r-bound uin...' == (1 more instance...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 26, 2020) is 1341 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group S. Litkowski 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track Y. Qu 5 Expires: January 27, 2021 Futurewei 6 A. Lindem 7 Cisco Systems 8 P. Sarkar 9 Individual 10 J. Tantsura 11 Apstra 12 July 26, 2020 14 YANG Data Model for Segment Routing 15 draft-ietf-spring-sr-yang-18 17 Abstract 19 This document defines a YANG data model for segment routing 20 configuration and operation, which is to be augmented by different 21 segment routing data planes. The document also defines a YANG model 22 that is intended to be used on network elements to configure or 23 operate segment routing MPLS data plane, as well as some generic 24 containers to be reused by IGP protocol modules to support segment 25 routing. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 27, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 63 2.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 65 3. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 66 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. IGP Control plane configuration . . . . . . . . . . . . . . . 6 68 5.1. IGP interface configuration . . . . . . . . . . . . . . . 7 69 5.1.1. Adjacency SID properties . . . . . . . . . . . . . . 7 70 5.1.1.1. Bundling . . . . . . . . . . . . . . . . . . . . 7 71 5.1.1.2. Protection . . . . . . . . . . . . . . . . . . . 8 72 6. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 80 12.2. Informative References . . . . . . . . . . . . . . . . . 31 81 Appendix A. Configuration example . . . . . . . . . . . . . . . 31 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 84 1. Introduction 86 This document defines a YANG data model [RFC7950] for segment routing 87 [RFC8402] configuration and operation. The document also defines a 88 YANG model that is intended to be used on network elements to 89 configure or operate segment routing MPLS data plane [RFC8660] This 90 document does not define the IGP extensions to support segment 91 routing but defines generic groupings that SHOULD be reused by IGP 92 extension modules. The reason of this design choice is to not 93 require implementations to support all IGP extensions. For example, 94 an implementation may support IS-IS extension but not OSPF. 96 The YANG modules in this document conform to the Network Management 97 Datastore Architecture (NMDA) [RFC8342]. 99 2. Terminology and Notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2.1. Tree diagram 109 Tree diagrams used in this document follow the notation defined in 110 [RFC8340]. 112 2.2. Prefixes in Data Node Names 114 In this document, names of data nodes, actions, and other data model 115 objects are often used without a prefix, as long as it is clear from 116 the context in which YANG module each name is defined. Otherwise, 117 names are prefixed using the standard prefix associated with the 118 corresponding YANG module, as shown in Table 1. 120 +----------+--------------------+-----------+ 121 | Prefix | YANG module | Reference | 122 +----------+--------------------+-----------+ 123 | if | ietf-interfaces | [RFC8343] | 124 | rt | ietf-routing | [RFC8349] | 125 | rt-types | ietf-routing-types | [RFC8294] | 126 | yang | ietf-yang-types | [RFC6991] | 127 | inet | ietf-inet-types | [RFC6991] | 128 +----------+--------------------+-----------+ 130 Table 1: Prefixes and Corresponding YANG Modules 132 3. Design of the Data Model 134 Module ietf-segment-routing augments the routing container in the 135 ietf-routing model [RFC8349], and defines generic segment routing 136 configuration and operational state. This module is augmented by 137 modules supporting different data planes. 139 Module ietf-segment-routing-mpls augments ietf-segment-routing, and 140 supports SR MPLS data plane configuration and operational state. 142 module: ietf-segment-routing 143 augment /rt:routing: 145 +--rw segment-routing 147 module: ietf-segment-routing-mpls 148 augment /rt:routing/sr:segment-routing: 149 +--rw sr-mpls 150 +--ro node-capabilities 151 | +--ro entropy-readable-label-depth? uint8 152 +--rw msd {max-sid-depth}? 153 | +--rw node-msd? uint8 154 | +--rw link-msd 155 | +--rw link-msds* [interface] 156 | +--rw interface if:interface-ref 157 | +--rw msd? uint8 158 +--rw bindings 159 | +--rw mapping-server {mapping-server}? 160 | | +--rw policy* [name] 161 | | +--rw name string 162 | | +--rw entries 163 | | +--rw mapping-entry* [prefix algorithm] 164 | | +--rw prefix inet:ip-prefix 165 | | +--rw value-type? enumeration 166 | | +--rw start-sid uint32 167 | | +--rw range? uint32 168 | | +--rw algorithm identityref 169 | +--rw connected-prefix-sid-map 170 | | +--rw connected-prefix-sid* [prefix algorithm] 171 | | +--rw prefix inet:ip-prefix 172 | | +--rw value-type? enumeration 173 | | +--rw start-sid uint32 174 | | +--rw range? uint32 175 | | +--rw algorithm identityref 176 | | +--rw last-hop-behavior? enumeration 177 | +--rw local-prefix-sid 178 | +--rw local-prefix-sid* [prefix algorithm] 179 | +--rw prefix inet:ip-prefix 180 | +--rw value-type? enumeration 181 | +--rw start-sid uint32 182 | +--rw range? uint32 183 | +--rw algorithm identityref 184 +--rw global-srgb 185 | +--rw srgb* [lower-bound upper-bound] 186 | +--rw lower-bound uint32 187 | +--rw upper-bound uint32 188 +--rw srlb 189 | +--rw srlb* [lower-bound upper-bound] 190 | +--rw lower-bound uint32 191 | +--rw upper-bound uint32 192 +--ro label-blocks* [] 193 | +--ro lower-bound? uint32 194 | +--ro upper-bound? uint32 195 | +--ro size? uint32 196 | +--ro free? uint32 197 | +--ro used? uint32 198 | +--ro scope? enumeration 199 +--ro sid-db 200 +--ro sid* [target sid source source-protocol binding-type] 201 +--ro target string 202 +--ro sid uint32 203 +--ro algorithm? uint8 204 +--ro source inet:ip-address 205 +--ro used? boolean 206 +--ro source-protocol -> /rt:routing 207 /control-plane-protocols 208 /control-plane-protocol/name 209 +--ro binding-type enumeration 210 +--ro scope? enumeration 212 notifications: 213 +---n segment-routing-global-srgb-collision 214 | +--ro srgb-collisions* [] 215 | +--ro lower-bound? uint32 216 | +--ro upper-bound? uint32 217 | +--ro routing-protocol? -> /rt:routing 218 | /control-plane-protocols 219 | /control-plane-protocol/name 220 | +--ro originating-rtr-id? router-id 221 +---n segment-routing-global-sid-collision 222 | +--ro received-target? string 223 | +--ro new-sid-rtr-id? router-id 224 | +--ro original-target? string 225 | +--ro original-sid-rtr-id? router-id 226 | +--ro index? uint32 227 | +--ro routing-protocol? -> /rt:routing 228 | /control-plane-protocols 229 | /control-plane-protocol/name 230 +---n segment-routing-index-out-of-range 231 +--ro received-target? string 232 +--ro received-index? uint32 233 +--ro routing-protocol? -> /rt:routing 234 /control-plane-protocols 235 /control-plane-protocol/name 237 4. Configuration 239 The module ietf-segment-routing-mpls augments the "/rt:routing/ 240 sr:segment-routing:" with a sr-mpls container. This container 241 defines all the configuration parameters related to segment-routing 242 MPLS data plane. 244 The sr-mpls configuration is split in global configuration and 245 interface configuration. 247 The global configuration includes : 249 o bindings : Defines prefix to SID mappings. The operator can 250 control advertisement of Prefix-SID independently for IPv4 and 251 IPv6. Two types of mappings are available: 253 * Mapping-server : maps non local prefixes to a segment ID. 254 Configuration of bindings does not automatically allow 255 advertisement of those bindings. Advertisement must be 256 controlled by each routing-protocol instance (see Section 5). 257 Multiple mapping policies may be defined. 259 * Connected prefixes : maps connected prefixes to a segment ID. 260 Advertisement of the mapping will be done by IGP when enabled 261 for segment routing (see Section 5). The SID value can be 262 expressed as an index (default), or an absolute value. The 263 "last-hop-behavior" configuration dictates the PHP behavior: 264 "explicit-null", "php", or "non-php". 266 o SRGB (Segment Routing Global Block): Defines a list of label 267 blocks represented by a pair of lower-bound/upper-bound labels. 268 The SRGB is also agnostic to the control plane used. So all 269 routing-protocol instance will have to advertise the same SRGB. 271 o SRLB (Segment Routing Local Block): Defines a list of label blocks 272 represented by a pair of lower-bound/upper-bound labels, reserved 273 for lcoal SIDs. 275 5. IGP Control plane configuration 277 Support of segment-routing extensions for a particular IGP control 278 plane is done by augmenting routing-protocol configuration with 279 segment-routing extensions. This augmentation SHOULD be part of 280 separate YANG modules in order to not create any dependency for 281 implementations to support all protocol extensions. 283 This module defines groupings that SHOULD be used by IGP segment 284 routing modules. 286 The "controlplane-cfg" grouping defines the generic global 287 configuration for the IGP. 289 The "enabled" leaf enables segment-routing extensions for the 290 routing-protocol instance. 292 The "bindings" container controls the routing-protocol instance's 293 advertisement of local bindings and the processing of received 294 bindings. 296 5.1. IGP interface configuration 298 The interface configuration is part of the "igp-interface-cfg" 299 grouping and includes Adjacency SID properties. 301 5.1.1. Adjacency SID properties 303 5.1.1.1. Bundling 305 In case of parallel IP links between routers, an additional Adjacency 306 SID [RFC8402] may be advertised representing more than one adjacency 307 (i.e., a bundle of adjacencies). The "advertise-adj-group-sid" 308 configuration controls whether or not an additional adjacency SID is 309 advertised. 311 The "advertise-adj-group-sid" is a list of "group-id". The "group- 312 id" will identify interfaces that are bundled together. 314 +-------+ +------+ 315 | | ------- L1 ---- | | 316 | R1 | ------- L2 ---- | R2 | 317 | | ------- L3 ---- | | 318 | | ------- L4 ---- | | 319 +-------+ +------+ 321 In the figure above, R1 and R2 are interconnected by four links. A 322 routing protocol adjacency is established on each link. Operator 323 would like to create segment-routing Adj-SID that represent some 324 bundles of links. We can imagine two different bundles : L1/L2 and 325 L3/L4. To achieve this behavior, the service provider will configure 326 a "group-id" X for both interfaces L1 and L2 and a "group-id" Y for 327 both interfaces L3 and L4. This will result in R1 advertising an 328 additional Adj-SID for each adjacency, for example a Adj-SID with S 329 flag set and value of 400 will be added to L1 and L2. A Adj-SID with 330 S flag set and value of 500 will be added to L3 and L4. As L1/L2 and 331 L3/L4 does not share the same "group-id", a different SID value will 332 be allocated. 334 5.1.1.2. Protection 336 The "advertise-protection" defines how protection for an interface is 337 advertised. It does not control the activation or deactivation of 338 protection. If the "single" option is used, a single Adj-SID will be 339 advertised for the interface. If the interface is protected, the 340 B-Flag for the Adj-SID advertisement will be set. If the "dual" 341 option is used and if the interface is protected, two Adj-SIDs will 342 be advertised for the interface adjacencies. One Adj-SID will always 343 have the B-Flag set and the other will have the B-Flag clear. This 344 option is intended to be used in the case of traffic engineering 345 where a path must use either protected segments or non-protected 346 segments. 348 6. States 350 The operational states contains information reflecting the usage of 351 allocated SRGB labels. 353 It also includes a list of all global SIDs, their associated 354 bindings, and other information such as the source protocol and 355 algorithm. 357 7. Notifications 359 The model defines the following notifications for segment-routing. 361 o segment-routing-global-srgb-collision: Rasied when a control plane 362 advertised SRGB blocks have conflicts. 364 o segment-routing-global-sid-collision: Raised when a control plane 365 advertised index is already associated with another target (in 366 this version, the only defined targets are IPv4 and IPv6 367 prefixes). 369 o segment-routing-index-out-of-range: Raised when a control plane 370 advertised index fall outside the range of SRGBs configured for 371 the network device. 373 8. YANG Module 375 The following RFCs and drafts are not referenced in the document text 376 but are referenced in the ietf-segment-rouuting-common.yang and/or 377 ietf-segment-routing.yang module: [RFC6991], [RFC8294], [RFC8476], 378 and [RFC8491]. 380 file "ietf-segment-routing@2020-07-24.yang" 381 module ietf-segment-routing { 382 yang-version 1.1; 383 namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing"; 384 prefix sr; 386 import ietf-routing { 387 prefix rt; 388 reference "RFC 8349: A YANG Data Model for Routing 389 Management (NMDA Version)"; 390 } 392 organization 393 "IETF SPRING - SPRING Working Group"; 394 contact 395 "WG Web: 396 WG List: 398 Author: Stephane Litkowski 399 400 Author: Yingzhen Qu 401 402 Author: Acee Lindem 403 404 Author: Pushpasis Sarkar 405 406 Author: Jeff Tantsura 407 409 "; 410 description 411 "The YANG module defines a generic framework for Segment 412 Routing. It is to be augmented by models for different 413 SR data planes. 415 This YANG model conforms to the Network Management 416 Datastore Architecture (NMDA) as described in RFC 8242. 418 Copyright (c) 2020 IETF Trust and the persons identified as 419 authors of the code. All rights reserved. 421 Redistribution and use in source and binary forms, with or 422 without modification, is permitted pursuant to, and subject 423 to the license terms contained in, the Simplified BSD License 424 set forth in Section 4.c of the IETF Trust's Legal Provisions 425 Relating to IETF Documents 426 (http://trustee.ietf.org/license-info). 428 This version of this YANG module is part of RFC XXXX; 429 see the RFC itself for full legal notices. 431 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 432 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 433 'MAY', and 'OPTIONAL' in this document are to be interpreted as 434 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 435 they appear in all capitals, as shown here."; 437 reference "RFC XXXX"; 439 revision 2020-07-24 { 440 description 441 "Initial Version"; 442 reference "RFC XXXX: YANG Data Model for Segment Routing."; 443 } 445 augment "/rt:routing" { 446 description 447 "This module augments routing data model (RFC 8349) 448 with Segment Routing (SR)."; 449 container segment-routing { 450 description 451 "Segment Routing configuration. This container 452 is to be augmented by models for different SR 453 data planes."; 454 reference "RFC 8402: Segment Routing Architecture."; 455 } 456 } 457 } 458 459 file "ietf-segment-routing-common@2020-07-24.yang" 460 module ietf-segment-routing-common { 461 yang-version 1.1; 462 namespace 463 "urn:ietf:params:xml:ns:yang:ietf-segment-routing-common"; 464 prefix sr-cmn; 466 import ietf-inet-types { 467 prefix inet; 468 reference "RFC 6991: Common YANG Data Types"; 469 } 471 organization 472 "IETF SPRING - SPRING Working Group"; 474 contact 475 "WG Web: 476 WG List: 477 Author: Stephane Litkowski 478 479 Author: Yingzhen Qu 480 481 Author: Acee Lindem 482 483 Author: Pushpasis Sarkar 484 485 Author: Jeff Tantsura 486 488 "; 489 description 490 "The YANG module defines a collection of generic types and 491 groupings for Segment Routing (SR) as described in RFC 8402. 493 This YANG model conforms to the Network Management 494 Datastore Architecture (NMDA) as described in RFC 8242. 496 Copyright (c) 2020 IETF Trust and the persons identified as 497 authors of the code. All rights reserved. 499 Redistribution and use in source and binary forms, with or 500 without modification, is permitted pursuant to, and subject 501 to the license terms contained in, the Simplified BSD License 502 set forth in Section 4.c of the IETF Trust's Legal Provisions 503 Relating to IETF Documents 504 (http://trustee.ietf.org/license-info). 506 This version of this YANG module is part of RFC XXXX; 507 see the RFC itself for full legal notices. 509 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 510 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 511 'MAY', and 'OPTIONAL' in this document are to be interpreted as 512 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 513 they appear in all capitals, as shown here."; 515 reference "RFC XXXX"; 517 revision 2020-07-24 { 518 description 519 "Initial version"; 520 reference "RFC XXXX: YANG Data Model for Segment Routing."; 521 } 523 feature sid-last-hop-behavior { 524 description 525 "Configurable last hop behavior."; 526 reference "RFC 8660: Segment Routing with the MPLS Data Plane"; 527 } 529 identity prefix-sid-algorithm { 530 description 531 "Base identity for prefix-sid algorithm."; 532 reference "RFC 8402: Segment Routing Architecture"; 533 } 535 identity prefix-sid-algorithm-shortest-path { 536 base prefix-sid-algorithm; 537 description 538 "Shortest Path First (SPF) prefix-sid algorithm. This 539 is the default algorithm."; 540 } 542 identity prefix-sid-algorithm-strict-spf { 543 base prefix-sid-algorithm; 544 description 545 "This algorithm mandates that the packet is forwarded 546 according to ECMP-aware SPF algorithm."; 547 } 549 grouping srlr { 550 description 551 "Grouping for SR Label Range configuration."; 552 leaf lower-bound { 553 type uint32; 554 description 555 "Lower value in the label range."; 556 } 557 leaf upper-bound { 558 type uint32; 559 must "../lower-bound < ../upper-bound" { 560 error-message 561 "The upper-bound must be larger than the lower-bound."; 562 description 563 "The value must be greater than 'lower-bound'."; 564 } 565 description 566 "Upper value in the label range."; 567 } 568 } 570 grouping srgb { 571 description 572 "Grouping for SR Global Label range."; 574 list srgb { 575 key "lower-bound upper-bound"; 576 ordered-by user; 577 description 578 "List of global blocks to be advertised."; 579 uses srlr; 580 } 581 } 583 grouping srlb { 584 description 585 "Grouping for SR Local Block range."; 586 list srlb { 587 key "lower-bound upper-bound"; 588 ordered-by user; 589 description 590 "List of SRLBs."; 591 uses srlr; 592 } 593 } 595 grouping sid-value-type { 596 description 597 "Defines how the SID value is expressed."; 598 leaf value-type { 599 type enumeration { 600 enum "index" { 601 description 602 "The value will be interpreted as an index."; 603 } 604 enum "absolute" { 605 description 606 "The value will become interpreted as an absolute 607 value."; 608 } 609 } 610 default "index"; 611 description 612 "This leaf defines how value must be interpreted."; 613 } 614 } 616 grouping prefix-sid { 617 description 618 "This grouping defines cfg of prefix SID."; 619 leaf prefix { 620 type inet:ip-prefix; 621 description 622 "connected prefix sid."; 623 } 624 uses prefix-sid-attributes; 625 } 627 grouping ipv4-sid { 628 description 629 "Grouping for an IPv4 prefix SID."; 630 leaf prefix { 631 type inet:ipv4-prefix; 632 description 633 "Connected IPv4 prefix sid."; 634 } 635 uses prefix-sid-attributes; 636 } 637 grouping ipv6-sid { 638 description 639 "Grouping for an IPv6 prefix SID."; 640 leaf prefix { 641 type inet:ipv6-prefix; 642 description 643 "Connected ipv6 prefix sid."; 644 } 645 uses prefix-sid-attributes; 646 } 648 grouping last-hop-behavior { 649 description 650 "Defines last hop behavior"; 651 leaf last-hop-behavior { 652 if-feature "sid-last-hop-behavior"; 653 type enumeration { 654 enum "explicit-null" { 655 description 656 "Use explicit-null for the SID."; 657 } 658 enum "no-php" { 659 description 660 "Do not use Penultimate Hop Popping (PHP) 661 for the SID."; 662 } 663 enum "php" { 664 description 665 "Use PHP for the SID."; 666 } 667 } 668 description 669 "Configure last hop behavior."; 671 } 672 } 674 grouping node-capabilities { 675 description 676 "Containing SR node capabilities."; 677 container node-capabilities { 678 config false; 679 description 680 "Shows the SR capability of the node."; 681 leaf entropy-readable-label-depth { 682 type uint8; 683 description 684 "Maximum label stack depth that a router can read."; 685 } 686 } 687 } 689 grouping prefix-sid-attributes { 690 description 691 "Grouping for Segment Routing (SR) prefix attributes."; 692 uses sid-value-type; 693 leaf start-sid { 694 type uint32; 695 mandatory true; 696 description 697 "Value associated with prefix. The value must be 698 interpreted in the context of value-type."; 699 } 700 leaf range { 701 type uint32; 702 description 703 "Indicates how many SIDs can be allocated."; 704 } 705 leaf algorithm { 706 type identityref { 707 base prefix-sid-algorithm; 708 } 709 description 710 "Prefix-sid algorithm."; 711 } 712 } 713 } 714 715 file "ietf-segment-routing-mpls@2020-07-24.yang" 716 module ietf-segment-routing-mpls { 717 yang-version 1.1; 718 namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls"; 719 prefix sr-mpls; 721 import ietf-inet-types { 722 prefix inet; 723 reference "RFC 6991: Common YANG Data Types"; 724 } 725 import ietf-routing { 726 prefix rt; 727 reference "RFC 8349: A YANG Data Model for Routing 728 Management (NMDA Version)"; 729 } 730 import ietf-interfaces { 731 prefix if; 732 reference "RFC 8343: A YANG Data Model for Interface 733 Management (NMDA Version)"; 734 } 735 import ietf-routing-types { 736 prefix rt-types; 737 reference "RFC 8294: Common YANG Data Types for the 738 Routing Area"; 739 } 740 import ietf-segment-routing { 741 prefix sr; 742 } 743 import ietf-segment-routing-common { 744 prefix sr-cmn; 745 } 747 organization 748 "IETF SPRING - SPRING Working Group"; 749 contact 750 "WG Web: 751 WG List: 753 Author: Stephane Litkowski 754 755 Author: Yingzhen Qu 756 757 Author: Acee Lindem 758 759 Author: Pushpasis Sarkar 760 761 Author: Jeff Tantsura 762 764 "; 765 description 766 "The YANG module defines a generic configuration model for 767 Segment Routing MPLS data plane. 769 This YANG model conforms to the Network Management 770 Datastore Architecture (NMDA) as described in RFC 8242. 772 Copyright (c) 2020 IETF Trust and the persons identified as 773 authors of the code. All rights reserved. 775 Redistribution and use in source and binary forms, with or 776 without modification, is permitted pursuant to, and subject 777 to the license terms contained in, the Simplified BSD License 778 set forth in Section 4.c of the IETF Trust's Legal Provisions 779 Relating to IETF Documents 780 (http://trustee.ietf.org/license-info). 782 This version of this YANG module is part of RFC XXXX; 783 see the RFC itself for full legal notices. 785 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 786 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 787 'MAY', and 'OPTIONAL' in this document are to be interpreted as 788 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 789 they appear in all capitals, as shown here."; 791 reference "RFC XXXX"; 793 revision 2020-07-24 { 794 description 795 "Initial Version"; 796 reference "RFC XXXX: YANG Data Model for Segment Routing."; 797 } 799 feature mapping-server { 800 description 801 "Support for Segment Routing Mapping Server (SRMS)."; 802 reference "RFC 8661: Segment Routing MPLS Interworking with LDP"; 803 } 805 feature protocol-srgb { 806 description 807 "Support for per-protocol Segment Routing Global Block 808 (SRGB) configuration."; 809 reference "RFC 8660: Segment Routing with the MPLS Data Plane"; 810 } 812 feature max-sid-depth { 813 description 814 "Support for signaling MSD (Maximum SID Depth) in IGP."; 815 reference "RFC 8476: Signaling Maximum SID Depth (MSD) 816 Using OSPF 817 RFC 8491: Signaling Maximum SID Depth (MSD) 818 Using IS-IS"; 819 } 821 typedef system-id { 822 type string { 823 pattern 824 '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}'; 825 } 826 description 827 "This type defines IS-IS system-id using pattern, 828 An example system-id is 0143.0438.AEF0"; 829 } 831 typedef router-id { 832 type union { 833 type system-id; 834 type rt-types:router-id; 835 } 836 description 837 "OSPF/BGP router-id or ISIS system ID."; 838 } 840 grouping sr-controlplane { 841 description 842 "Defines protocol configuration."; 843 container segment-routing { 844 description 845 "Segment Routing global configuration."; 846 leaf enabled { 847 type boolean; 848 default "false"; 849 description 850 "Enables segment-routing protocol extensions."; 851 } 852 container bindings { 853 description 854 "Control of binding advertisement and reception."; 855 container advertise { 856 description 857 "Control advertisement of local mappings 858 in binding TLVs."; 859 leaf-list policies { 860 type leafref { 861 path "/rt:routing/sr:segment-routing/sr-mpls:sr-mpls" 862 + "/sr-mpls:bindings/sr-mpls:mapping-server" 863 + "/sr-mpls:policy/sr-mpls:name"; 864 } 865 description 866 "List of binding advertisement policies."; 867 } 868 } 869 leaf receive { 870 type boolean; 871 default "true"; 872 description 873 "Allow the reception and usage of binding TLVs."; 874 } 875 } 876 } 877 } 879 grouping igp-interface { 880 description 881 "Grouping for IGP interface configuration."; 882 container segment-routing { 883 description 884 "Container for SR interface configuration."; 885 container adjacency-sid { 886 description 887 "Adjacency SID configuration."; 888 reference "RFC 8660: Segment Routing with the MPLS 889 Data Plane"; 890 list adj-sids { 891 key "value"; 892 uses sr-cmn:sid-value-type; 893 leaf value { 894 type uint32; 895 description 896 "Value of the Adj-SID."; 897 } 898 leaf protected { 899 type boolean; 900 default false; 901 description 902 "It is used to protect the manual adj-SID."; 903 } 904 description 905 "List of adj-sid configuration."; 906 } 907 list advertise-adj-group-sid { 908 key "group-id"; 909 description 910 "Control advertisement of S flag. Enable advertisement 911 of a common Adj-SID for parallel links."; 912 leaf group-id { 913 type uint32; 914 description 915 "The value is an internal value to identify a 916 group-ID. Interfaces with the same group-ID will be 917 bundled together."; 918 } 919 } 920 leaf advertise-protection { 921 type enumeration { 922 enum "single" { 923 description 924 "A single Adj-SID is associated with the adjacency 925 and reflects the protection configuration."; 926 } 927 enum "dual" { 928 description 929 "Two Adj-SIDs will be associated with the adjacency 930 if the interface is protected. In this case, will 931 be advertised with backup flag set, the other will 932 be advertised with the backup flag clear. In case 933 protection is not configured, single Adj-SID will 934 be advertised with the backup flag clear."; 935 } 936 } 937 description 938 "If set, the Adj-SID refers to a protected adjacency."; 939 } 940 } 941 } 942 } 944 grouping max-sid-depth { 945 description 946 "Maximum SID Depth (MSD)D configuration grouping."; 947 leaf node-msd { 948 type uint8; 949 description 950 "Node MSD is the lowest MSD supported by the node."; 951 } 952 container link-msd { 953 description 954 "MSD supported by an individual interface."; 955 list link-msds { 956 key "interface"; 957 description 958 "List of link MSDs."; 960 leaf interface { 961 type if:interface-ref; 962 description 963 "Reference to device interface."; 964 } 965 leaf msd { 966 type uint8; 967 description 968 "MSD supported by the interface."; 969 } 970 } 971 } 972 } 974 augment "/rt:routing/sr:segment-routing" { 975 description 976 "This augments routing data model (RFC 8349) 977 with Segment Routing (SR)."; 978 container sr-mpls { 979 description 980 "Segment Routing global configuration."; 981 uses sr-cmn:node-capabilities; 982 container msd { 983 if-feature "max-sid-depth"; 984 description 985 "MSD configuration."; 986 uses max-sid-depth; 987 } 988 container bindings { 989 description 990 "List of bindings."; 991 container mapping-server { 992 if-feature "mapping-server"; 993 description 994 "Configuration of mapping-server local entries."; 995 list policy { 996 key "name"; 997 description 998 "List mapping-server policies."; 999 leaf name { 1000 type string; 1001 description 1002 "Name of the mapping policy."; 1003 } 1004 container entries { 1005 description 1006 "IPv4/IPv6 mapping entries."; 1007 list mapping-entry { 1008 key "prefix algorithm"; 1009 description 1010 "Mapping entries."; 1011 uses sr-cmn:prefix-sid; 1012 } 1013 } 1014 } 1015 } 1016 container connected-prefix-sid-map { 1017 description 1018 "Prefix SID configuration."; 1019 list connected-prefix-sid { 1020 key "prefix algorithm"; 1021 description 1022 "List of prefix SID mapped to IPv4/IPv6 1023 local prefixes."; 1024 uses sr-cmn:prefix-sid; 1025 uses sr-cmn:last-hop-behavior; 1026 } 1027 } 1028 container local-prefix-sid { 1029 description 1030 "Local sid configuration."; 1031 list local-prefix-sid { 1032 key "prefix algorithm"; 1033 description 1034 "List of local IPv4/IPv6 prefix-sids."; 1035 uses sr-cmn:prefix-sid; 1036 } 1037 } 1038 } 1039 container global-srgb { 1040 description 1041 "Global SRGB configuration."; 1042 uses sr-cmn:srgb; 1043 } 1044 container srlb { 1045 description 1046 "Segment Routing Local Block (SRLB) configuration."; 1047 uses sr-cmn:srlb; 1048 } 1050 list label-blocks { 1051 config false; 1052 description 1053 "List of label blocks currently in use."; 1054 leaf lower-bound { 1055 type uint32; 1056 description 1057 "Lower bound of the label block."; 1058 } 1059 leaf upper-bound { 1060 type uint32; 1061 description 1062 "Upper bound of the label block."; 1063 } 1064 leaf size { 1065 type uint32; 1066 description 1067 "Number of indexes in the block."; 1068 } 1069 leaf free { 1070 type uint32; 1071 description 1072 "Number of free indexes in the block."; 1073 } 1074 leaf used { 1075 type uint32; 1076 description 1077 "Number of indexes in use in the block."; 1078 } 1079 leaf scope { 1080 type enumeration { 1081 enum "global" { 1082 description 1083 "Global SID."; 1084 } 1085 enum "local" { 1086 description 1087 "Local SID."; 1088 } 1089 } 1090 description 1091 "Scope of this label block."; 1092 } 1093 } 1094 container sid-db { 1095 config false; 1096 description 1097 "List of prefix and SID associations."; 1098 list sid { 1099 key "target sid source source-protocol binding-type"; 1100 ordered-by system; 1101 description 1102 "SID Binding."; 1103 leaf target { 1104 type string; 1105 description 1106 "Defines the target of the binding. It can be a 1107 prefix or something else."; 1108 } 1109 leaf sid { 1110 type uint32; 1111 description 1112 "Index associated with the prefix."; 1113 } 1114 leaf algorithm { 1115 type uint8; 1116 description 1117 "Algorithm to be used for the prefix SID."; 1118 reference "RFC 8665: OSPF Extensions for Segment Routing 1119 RFC 8667: IS-IS Extensions for Segment Routing"; 1120 } 1121 leaf source { 1122 type inet:ip-address; 1123 description 1124 "IP address of the router that owns the binding."; 1125 } 1126 leaf used { 1127 type boolean; 1128 description 1129 "Indicates if the binding is install in the 1130 forwarding plane."; 1131 } 1132 leaf source-protocol { 1133 type leafref { 1134 path "/rt:routing/rt:control-plane-protocols/" 1135 + "rt:control-plane-protocol/rt:name"; 1136 } 1137 description 1138 "Routing protocol that owns the binding"; 1139 } 1140 leaf binding-type { 1141 type enumeration { 1142 enum "prefix-sid" { 1143 description 1144 "Binding is learned from a prefix SID."; 1145 } 1146 enum "binding-tlv" { 1147 description 1148 "Binding is learned from a binding TLV."; 1149 } 1150 } 1151 description 1152 "Type of binding."; 1153 } 1154 leaf scope { 1155 type enumeration { 1156 enum "global" { 1157 description 1158 "Global SID."; 1159 } 1160 enum "local" { 1161 description 1162 "Local SID."; 1163 } 1164 } 1165 description 1166 "SID scoping."; 1167 } 1168 } 1169 } 1170 } 1171 } 1173 notification segment-routing-global-srgb-collision { 1174 description 1175 "This notification is sent when SRGB blocks received from 1176 routers conflict."; 1177 list srgb-collisions { 1178 description 1179 "List of SRGB blocks that conflict."; 1180 leaf lower-bound { 1181 type uint32; 1182 description 1183 "Lower value in the block."; 1184 } 1185 leaf upper-bound { 1186 type uint32; 1187 description 1188 "Upper value in the block."; 1189 } 1190 leaf routing-protocol { 1191 type leafref { 1192 path "/rt:routing/rt:control-plane-protocols/" 1193 + "rt:control-plane-protocol/rt:name"; 1194 } 1195 description 1196 "Routing protocol reference for SRGB collision."; 1197 } 1198 leaf originating-rtr-id { 1199 type router-id; 1200 description 1201 "Originating Router ID of this SRGB block."; 1202 } 1203 } 1204 } 1205 notification segment-routing-global-sid-collision { 1206 description 1207 "This notification is sent when a new mapping is learned 1208 containing s mapping where the SID is already used. 1209 The notification generation must be throttled with at least 1210 a 5 second gap between notifications."; 1211 leaf received-target { 1212 type string; 1213 description 1214 "Target received in the router advertisement that caused 1215 the SID collision."; 1216 } 1217 leaf new-sid-rtr-id { 1218 type router-id; 1219 description 1220 "Router ID that advertised the conflicting SID."; 1221 } 1222 leaf original-target { 1223 type string; 1224 description 1225 "Target already available in the database with the same SID 1226 as the received target."; 1227 } 1228 leaf original-sid-rtr-id { 1229 type router-id; 1230 description 1231 "Router-ID for the router that originally advertised the 1232 conflicting SID, i.e., the instance in the database."; 1233 } 1234 leaf index { 1235 type uint32; 1236 description 1237 "Value of the index used by two different prefixes."; 1238 } 1239 leaf routing-protocol { 1240 type leafref { 1241 path "/rt:routing/rt:control-plane-protocols/" 1242 + "rt:control-plane-protocol/rt:name"; 1243 } 1244 description 1245 "Routing protocol reference for conflicting SID."; 1246 } 1247 } 1248 notification segment-routing-index-out-of-range { 1249 description 1250 "This notification is sent when a binding is received 1251 containing a segment index which is out of the local 1252 configured ranges. The notification generation must be 1253 throttled with at least a 5 second gap between 1254 notifications."; 1255 leaf received-target { 1256 type string; 1257 description 1258 "Target received in the router advertisement with 1259 the out-of-range index."; 1260 } 1261 leaf received-index { 1262 type uint32; 1263 description 1264 "Value of the index received."; 1265 } 1266 leaf routing-protocol { 1267 type leafref { 1268 path "/rt:routing/rt:control-plane-protocols/" 1269 + "rt:control-plane-protocol/rt:name"; 1270 } 1271 description 1272 "Routing protocol reference for out-of-range indexd."; 1273 } 1274 } 1275 } 1276 1278 9. Security Considerations 1280 The YANG modules specified in this document define a schema for data 1281 that is designed to be accessed via network management protocols such 1282 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1283 is the secure transport layer, and the mandatory-to-implement secure 1284 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1285 is HTTPS, and the mandatory-to-implement secure transport is TLS 1286 [RFC5246]. 1288 The NETCONF access control model [RFC6536] provides the means to 1289 restrict access for particular NETCONF or RESTCONF users to a pre- 1290 configured subset of all available NETCONF or RESTCONF protocol 1291 operations and content. 1293 There are a number of data nodes defined in the modules that are 1294 writable/creatable/deletable (i.e., config true, which is the 1295 default). These data nodes may be considered sensitive or vulnerable 1296 in some network environments. Write operations (e.g., edit-config) 1297 to these data nodes without proper protection can have a negative 1298 effect on network operations. 1300 Some of the readable data nodes in the modules may be considered 1301 sensitive or vulnerable in some network environments. It is thus 1302 important to control read access (e.g., via get, get-config, or 1303 notification) to these data nodes. 1305 10. Acknowledgements 1307 Authors would like to thank Derek Yeung, Greg Hankins, Hannes 1308 Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge, Les Ginsberg for 1309 their contributions. 1311 11. IANA Considerations 1313 This document registers a URI in the IETF XML registry [RFC3688]. 1314 Following the format in [RFC3688], the following registration is 1315 requested to be made: 1317 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing-commmon 1318 Registrant Contact: The IESG. 1319 XML: N/A, the requested URI is an XML namespace. 1321 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing 1322 Registrant Contact: The IESG. 1323 XML: N/A, the requested URI is an XML namespace. 1325 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls 1326 Registrant Contact: The IESG. 1327 XML: N/A, the requested URI is an XML namespace. 1329 This document registers a YANG module in the YANG Module Names 1330 registry [RFC6020]. 1332 name: ietf-segment-routing-common 1333 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common 1334 prefix: sr-cmn 1335 reference: RFC XXXX 1337 name: ietf-segment-routing 1338 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing 1339 prefix: sr 1340 reference: RFC XXXX 1341 name: ietf-segment-routing 1342 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls 1343 prefix: sr-mpls 1344 reference: RFC XXXX 1346 12. References 1348 12.1. Normative References 1350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1351 Requirement Levels", BCP 14, RFC 2119, 1352 DOI 10.17487/RFC2119, March 1997, 1353 . 1355 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1356 DOI 10.17487/RFC3688, January 2004, 1357 . 1359 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1360 (TLS) Protocol Version 1.2", RFC 5246, 1361 DOI 10.17487/RFC5246, August 2008, 1362 . 1364 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1365 the Network Configuration Protocol (NETCONF)", RFC 6020, 1366 DOI 10.17487/RFC6020, October 2010, 1367 . 1369 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1370 and A. Bierman, Ed., "Network Configuration Protocol 1371 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1372 . 1374 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1375 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1376 . 1378 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1379 Protocol (NETCONF) Access Control Model", RFC 6536, 1380 DOI 10.17487/RFC6536, March 2012, 1381 . 1383 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1384 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1385 . 1387 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1388 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1389 . 1391 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1392 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1393 . 1395 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1396 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1397 May 2017, . 1399 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1400 "Common YANG Data Types for the Routing Area", RFC 8294, 1401 DOI 10.17487/RFC8294, December 2017, 1402 . 1404 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1405 and R. Wilton, "Network Management Datastore Architecture 1406 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1407 . 1409 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1410 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1411 . 1413 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1414 Routing Management (NMDA Version)", RFC 8349, 1415 DOI 10.17487/RFC8349, March 2018, 1416 . 1418 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1419 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1420 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1421 July 2018, . 1423 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1424 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1425 DOI 10.17487/RFC8476, December 2018, 1426 . 1428 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1429 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1430 DOI 10.17487/RFC8491, November 2018, 1431 . 1433 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1434 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1435 Routing with the MPLS Data Plane", RFC 8660, 1436 DOI 10.17487/RFC8660, December 2019, 1437 . 1439 12.2. Informative References 1441 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1442 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1443 . 1445 Appendix A. Configuration example 1447 The following is an XML example using the SR MPLS YANG modules. 1449 1450 1452 1454 1455 5 1456 1457 1458 1459 1460 mapping 1 1461 1462 1463 198.51.100.0/24 1464 1467 sr-cmn:prefix-sid-algorithm-shortest-path 1468 200 1469 100 1470 1471 1472 1473 1474 1475 1476 192.0.2.0/24 1477 1479 sr-cmn:prefix-sid-algorithm-strict-spf 1480 100 1481 1 1482 php 1483 1484 1485 1486 1487 1488 45000 1489 55000 1490 1491 1492 1493 1494 1495 Authors' Addresses 1497 Stephane Litkowski 1498 Cisco Systems 1500 Email: slitkows.ietf@gmail.com 1502 Yingzhen Qu 1503 Futurewei 1505 Email: yingzhen.qu@futurewei.com 1507 Acee Lindem 1508 Cisco Systems 1509 301 Mindenhall Way 1510 Cary, NC 27513 1511 US 1513 Email: acee@cisco.com 1515 Pushpasis Sarkar 1516 Individual 1518 Email: pushpasis.ietf@gmail.com 1520 Jeff Tantsura 1521 Apstra 1523 Email: jefftant.ietf@gmail.com