idnits 2.17.00 (12 Aug 2021) /tmp/idnits50944/draft-ietf-spring-sr-yang-17.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...) -- The document date (July 9, 2020) is 681 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 (~~), 7 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 10, 2021 Futurewei 6 A. Lindem 7 Cisco Systems 8 P. Sarkar 9 Individual 10 J. Tantsura 11 Apstra 12 July 9, 2020 14 YANG Data Model for Segment Routing 15 draft-ietf-spring-sr-yang-17 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 10, 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" would be a list of "group-id". The 312 "group-id" will permit to identify interfaces that must be bundled 313 together. 315 +-------+ +------+ 316 | | ------- L1 ---- | | 317 | R1 | ------- L2 ---- | R2 | 318 | | ------- L3 ---- | | 319 | | ------- L4 ---- | | 320 +-------+ +------+ 322 In the figure above, R1 and R2 are interconnected by four links. A 323 routing protocol adjacency is established on each link. Operator 324 would like to create segment-routing Adj-SID that represent some 325 bundles of links. We can imagine two different bundles : L1/L2 and 326 L2/L3. To achieve this behavior, the service provider will configure 327 a "group-id" X for both interfaces L1 and L2 and a "group-id" Y for 328 both interfaces L3 and L3. This will result in R1 advertising an 329 additional Adj-SID for each adjacency, for example a Adj-SID with S 330 flag set and value of 400 will be added to L1 and L2. A Adj-SID with 331 S flag set and value of 500 will be added to L3 and L4. As L1/L2 and 332 L3/L4 does not share the same "group-id", a different SID value will 333 be allocated. 335 5.1.1.2. Protection 337 The "advertise-protection" defines how protection for an interface is 338 advertised. It does not control the activation or deactivation of 339 protection. If the "single" option is used, a single Adj-SID will be 340 advertised for the interface. If the interface is protected, the 341 B-Flag for the Adj-SID advertisement will be set. If the "dual" 342 option is used and if the interface is protected, two Adj-SIDs will 343 be advertised for the interface adjacencies. One Adj-SID will always 344 have the B-Flag set and the other will have the B-Flag clear. This 345 option is intended to be used in the case of traffic engineering 346 where a path must use either protected segments or non-protected 347 segments. 349 6. States 351 The operational states contains information reflecting the usage of 352 allocated SRGB labels. 354 It also includes a list of all global SIDs, their associated 355 bindings, and other information such as the source protocol and 356 algorithm. 358 7. Notifications 360 The model defines the following notifications for segment-routing. 362 o segment-routing-global-srgb-collision: Rasied when a control plan 363 advertised SRGB blocks have conflicts. 365 o segment-routing-global-sid-collision: Raised when a control plane 366 advertised index is already associated with another target (in 367 this version, the only defined targets are IPv4 and IPv6 368 prefixes). 370 o segment-routing-index-out-of-range: Raised when a control plane 371 advertised index fall outside the range of SRGBs configured for 372 the network device. 374 8. YANG Module 376 The following RFCs and drafts are not referenced in the document text 377 but are referenced in the ietf-segment-rouuting-common.yang and/or 378 ietf-segment-routing.yang module: [RFC6991], [RFC8294], [RFC8476], 379 and [RFC8491]. 381 file "ietf-segment-routing@2020-07-09.yang" 382 module ietf-segment-routing { 383 yang-version 1.1; 384 namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing"; 385 prefix sr; 387 import ietf-routing { 388 prefix rt; 389 reference "RFC 8349: A YANG Data Model for Routing 390 Management (NMDA Version)"; 391 } 393 organization 394 "IETF SPRING - SPRING Working Group"; 395 contact 396 "WG Web: 397 WG List: 399 Editor: Stephane Litkowski 400 401 Editor: Yingzhen Qu 402 404 Author: Acee Lindem 405 406 Author: Pushpasis Sarkar 407 408 Author: Jeff Tantsura 409 411 "; 412 description 413 "The YANG module defines a generic configuration model for 414 Segment Routing common across all of the vendor 415 implementations. It's to be augmented by different SR data 416 planes. 418 This YANG model conforms to the Network Management 419 Datastore Architecture (NMDA) as described in RFC 8242. 421 Copyright (c) 2020 IETF Trust and the persons identified as 422 authors of the code. All rights reserved. 424 Redistribution and use in source and binary forms, with or 425 without modification, is permitted pursuant to, and subject 426 to the license terms contained in, the Simplified BSD License 427 set forth in Section 4.c of the IETF Trust's Legal Provisions 428 Relating to IETF Documents 429 (http://trustee.ietf.org/license-info). 431 This version of this YANG module is part of RFC XXXX; 432 see the RFC itself for full legal notices. 434 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 435 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 436 'MAY', and 'OPTIONAL' in this document are to be interpreted as 437 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 438 they appear in all capitals, as shown here."; 440 reference "RFC XXXX"; 442 revision 2020-07-09 { 443 description 444 "Initial Version"; 445 reference "RFC XXXX: YANG Data Model for Segment Routing."; 446 } 448 augment "/rt:routing" { 449 description 450 "This module augments routing data model (RFC 8349) 451 with Segment Routing (SR)."; 452 container segment-routing { 453 description 454 "Segment Routing configuration. This container 455 is to be augmented by different SR data planes."; 456 reference "RFC 8402: Segment Routing Architecture"; 457 } 458 } 459 } 460 461 file "ietf-segment-routing-common@2020-07-09.yang" 462 module ietf-segment-routing-common { 463 yang-version 1.1; 464 namespace 465 "urn:ietf:params:xml:ns:yang:ietf-segment-routing-common"; 466 prefix sr-cmn; 468 import ietf-inet-types { 469 prefix inet; 470 reference "RFC 6991: Common YANG Data Types"; 471 } 473 organization 474 "IETF SPRING - SPRING Working Group"; 476 contact 477 "WG Web: 478 WG List: 480 Editor: Stephane Litkowski 481 482 Editor: Yingzhen Qu 483 485 Author: Acee Lindem 486 487 Author: Pushpasis Sarkar 488 489 Author: Jeff Tantsura 490 492 "; 493 description 494 "The YANG module defines a collection of generic types and 495 grouping for Segment Routing (SR) as described in RFC 8402. 497 This YANG model conforms to the Network Management 498 Datastore Architecture (NMDA) as described in RFC 8242. 500 Copyright (c) 2020 IETF Trust and the persons identified as 501 authors of the code. All rights reserved. 503 Redistribution and use in source and binary forms, with or 504 without modification, is permitted pursuant to, and subject 505 to the license terms contained in, the Simplified BSD License 506 set forth in Section 4.c of the IETF Trust's Legal Provisions 507 Relating to IETF Documents 508 (http://trustee.ietf.org/license-info). 510 This version of this YANG module is part of RFC XXXX; 511 see the RFC itself for full legal notices. 513 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 514 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 515 'MAY', and 'OPTIONAL' in this document are to be interpreted as 516 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 517 they appear in all capitals, as shown here."; 519 reference "RFC XXXX"; 521 revision 2020-07-09 { 522 description 523 "Initial version"; 525 reference "RFC XXXX: YANG Data Model for Segment Routing."; 526 } 528 feature sid-last-hop-behavior { 529 description 530 "Configurable last hop behavior."; 531 reference "RFC 8660: Segment Routing with the MPLS Data Plane"; 532 } 534 identity prefix-sid-algorithm { 535 description 536 "Base identity for prefix-sid algorithm."; 537 } 539 identity prefix-sid-algorithm-shortest-path { 540 base prefix-sid-algorithm; 541 description 542 "Shortest Path First (SPF) prefix-sid algorithm. This 543 is the default algorithm."; 544 } 546 identity prefix-sid-algorithm-strict-spf { 547 base prefix-sid-algorithm; 548 description 549 "This algorithm mandates that the packet is forwarded 550 according to ECMP-aware SPF algorithm."; 551 } 553 grouping srlr { 554 description 555 "Grouping for SR Label Range configuration."; 556 leaf lower-bound { 557 type uint32; 558 description 559 "Lower value in the label range."; 560 } 561 leaf upper-bound { 562 type uint32; 563 must "../lower-bound < ../upper-bound" { 564 error-message 565 "The upper-bound must be larger than the lower-bound."; 566 description 567 "The value must be greater than 'lower-bound'."; 568 } 569 description 570 "Upper value in the label range."; 571 } 572 } 573 grouping srgb { 574 description 575 "Grouping for SR Global Label range."; 576 list srgb { 577 key "lower-bound upper-bound"; 578 ordered-by user; 579 description 580 "List of global blocks to be advertised."; 581 uses srlr; 582 } 583 } 585 grouping srlb { 586 description 587 "Grouping for SR Local Block range."; 588 list srlb { 589 key "lower-bound upper-bound"; 590 ordered-by user; 591 description 592 "List of SRLBs."; 593 uses srlr; 594 } 595 } 597 grouping sid-value-type { 598 description 599 "Defines how the SID value is expressed."; 600 leaf value-type { 601 type enumeration { 602 enum "index" { 603 description 604 "The value will be interpreted as an index."; 605 } 606 enum "absolute" { 607 description 608 "The value will become interpreted as an absolute 609 value."; 610 } 611 } 612 default "index"; 613 description 614 "This leaf defines how value must be interpreted."; 615 } 616 } 618 grouping prefix-sid { 619 description 620 "This grouping defines cfg of prefix SID."; 622 leaf prefix { 623 type inet:ip-prefix; 624 description 625 "connected prefix sid."; 626 } 627 uses prefix-sid-attributes; 628 } 630 grouping ipv4-sid { 631 description 632 "Grouping for an IPv4 prefix SID."; 633 leaf prefix { 634 type inet:ipv4-prefix; 635 description 636 "Connected IPv4 prefix sid."; 637 } 638 uses prefix-sid-attributes; 639 } 640 grouping ipv6-sid { 641 description 642 "Grouping for an IPv6 prefix SID."; 643 leaf prefix { 644 type inet:ipv6-prefix; 645 description 646 "Connected ipv6 prefix sid."; 647 } 648 uses prefix-sid-attributes; 649 } 651 grouping last-hop-behavior { 652 description 653 "Defines last hop behavior"; 654 leaf last-hop-behavior { 655 if-feature "sid-last-hop-behavior"; 656 type enumeration { 657 enum "explicit-null" { 658 description 659 "Use explicit-null for the SID."; 660 } 661 enum "no-php" { 662 description 663 "Do not use Penultimate Hop Popping (PHP) 664 for the SID."; 665 } 666 enum "php" { 667 description 668 "Use PHP for the SID."; 669 } 671 } 672 description 673 "Configure last hop behavior."; 674 } 675 } 677 grouping node-capabilities { 678 description 679 "Containing SR node capabilities."; 680 container node-capabilities { 681 config false; 682 description 683 "Shows the SR capability of the node."; 684 leaf entropy-readable-label-depth { 685 type uint8; 686 description 687 "Maximum label stack depth that a router can read."; 688 } 689 } 690 } 692 grouping prefix-sid-attributes { 693 description 694 "Grouping for Segment Routing (SR) prefix attributes."; 695 uses sid-value-type; 696 leaf start-sid { 697 type uint32; 698 mandatory true; 699 description 700 "Value associated with prefix. The value must be 701 interpreted in the context of value-type."; 702 } 703 leaf range { 704 type uint32; 705 description 706 "Indicates how many SIDs can be allocated."; 707 } 708 leaf algorithm { 709 type identityref { 710 base prefix-sid-algorithm; 711 } 712 description 713 "Prefix-sid algorithm."; 714 } 715 } 716 } 717 718 file "ietf-segment-routing-mpls@2020-07-09.yang" 719 module ietf-segment-routing-mpls { 720 yang-version 1.1; 721 namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls"; 722 prefix sr-mpls; 724 import ietf-inet-types { 725 prefix inet; 726 reference "RFC 6991: Common YANG Data Types"; 727 } 728 import ietf-routing { 729 prefix rt; 730 reference "RFC 8349: A YANG Data Model for Routing 731 Management (NMDA Version)"; 732 } 733 import ietf-interfaces { 734 prefix if; 735 reference "RFC 8343: A YANG Data Model for Interface 736 Management (NMDA Version)"; 737 } 738 import ietf-routing-types { 739 prefix rt-types; 740 reference "RFC 8294: Common YANG Data Types for the 741 Routing Area"; 742 } 743 import ietf-segment-routing { 744 prefix sr; 745 } 746 import ietf-segment-routing-common { 747 prefix sr-cmn; 748 } 750 organization 751 "IETF SPRING - SPRING Working Group"; 752 contact 753 "WG Web: 754 WG List: 756 Editor: Stephane Litkowski 757 758 Editor: Yingzhen Qu 759 761 Author: Acee Lindem 762 763 Author: Pushpasis Sarkar 764 765 Author: Jeff Tantsura 766 768 "; 769 description 770 "The YANG module defines a generic configuration model for 771 Segment Routing MPLS data plane. 773 This YANG model conforms to the Network Management 774 Datastore Architecture (NMDA) as described in RFC 8242. 776 Copyright (c) 2020 IETF Trust and the persons identified as 777 authors of the code. All rights reserved. 779 Redistribution and use in source and binary forms, with or 780 without modification, is permitted pursuant to, and subject 781 to the license terms contained in, the Simplified BSD License 782 set forth in Section 4.c of the IETF Trust's Legal Provisions 783 Relating to IETF Documents 784 (http://trustee.ietf.org/license-info). 786 This version of this YANG module is part of RFC XXXX; 787 see the RFC itself for full legal notices. 789 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 790 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 791 'MAY', and 'OPTIONAL' in this document are to be interpreted as 792 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 793 they appear in all capitals, as shown here."; 795 reference "RFC XXXX"; 797 revision 2020-07-09 { 798 description 799 "Initial Version"; 800 reference "RFC XXXX: YANG Data Model for Segment Routing."; 801 } 803 feature mapping-server { 804 description 805 "Support for Segment Routing Mapping Server (SRMS)."; 806 reference "RFC 8661: Segment Routing MPLS Interworking with LDP"; 807 } 809 feature protocol-srgb { 810 description 811 "Support for per-protocol Segment Routing Global Block 812 (SRGB) configuration."; 813 reference "RFC 8660: Segment Routing with the MPLS Data Plane"; 814 } 815 feature max-sid-depth { 816 description 817 "Support for signaling MSD (Maximum SID Depth) in IGP."; 818 reference "RFC 8476: Signaling Maximum SID Depth (MSD) 819 Using OSPF 820 RFC 8491: Signaling Maximum SID Depth (MSD) 821 Using IS-IS"; 822 } 824 typedef system-id { 825 type string { 826 pattern 827 '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}'; 828 } 829 description 830 "This type defines IS-IS system-id using pattern, 831 An example system-id is 0143.0438.AEF0"; 832 } 834 typedef router-id { 835 type union { 836 type system-id; 837 type rt-types:router-id; 838 } 839 description 840 "OSPF/BGP router-id or ISIS system ID."; 841 } 843 grouping sr-controlplane { 844 description 845 "Defines protocol configuration."; 846 container segment-routing { 847 description 848 "Segment Routing global configuration."; 849 leaf enabled { 850 type boolean; 851 default "false"; 852 description 853 "Enables segment-routing protocol extensions."; 854 } 855 container bindings { 856 description 857 "Control of binding advertisement and reception."; 858 container advertise { 859 description 860 "Control advertisement of local mappings 861 in binding TLVs."; 862 leaf-list policies { 863 type string; 864 description 865 "List of binding advertisement policies."; 866 } 867 } 868 leaf receive { 869 type boolean; 870 default "true"; 871 description 872 "Allow the reception and usage of binding TLVs."; 873 } 874 } 875 } 876 } 878 grouping igp-interface { 879 description 880 "Grouping for IGP interface configuration."; 881 container segment-routing { 882 description 883 "Container for SR interface configuration."; 884 container adjacency-sid { 885 description 886 "Adjacency SID configuration."; 887 list adj-sids { 888 key "value"; 889 uses sr-cmn:sid-value-type; 890 leaf value { 891 type uint32; 892 description 893 "Value of the Adj-SID."; 894 } 895 leaf protected { 896 type boolean; 897 default false; 898 description 899 "It is used to protect the mannual adj-SID."; 900 } 901 description 902 "List of adj-sid configuration."; 903 } 904 list advertise-adj-group-sid { 905 key "group-id"; 906 description 907 "Control advertisement of S flag. Enable advertisement 908 of a common Adj-SID for parallel links."; 909 leaf group-id { 910 type uint32; 911 description 912 "The value is an internal value to identify a 913 group-ID. Interfaces with the same group-ID will be 914 bundled together."; 915 } 916 } 917 leaf advertise-protection { 918 type enumeration { 919 enum "single" { 920 description 921 "A single Adj-SID is associated with the adjacency 922 and reflects the protection configuration."; 923 } 924 enum "dual" { 925 description 926 "Two Adj-SIDs will be associated with the adjacency 927 if the interface is protected. In this case, will 928 be advertised with backup flag set, the other will 929 be advertised with theo backup flag clear. In case 930 protection is not configured, single Adj-SID will 931 be advertised with the backup flag clear."; 932 } 933 } 934 description 935 "If set, the Adj-SID refers to a protected adjacency."; 936 } 937 } 938 } 939 } 941 grouping max-sid-depth { 942 description 943 "Maximum SID Depth (MSD)D configuration grouping."; 944 leaf node-msd { 945 type uint8; 946 description 947 "Node MSD is the lowest MSD supported by the node."; 948 } 949 container link-msd { 950 description 951 "MSD supported by an individual interface."; 952 list link-msds { 953 key "interface"; 954 description 955 "List of link MSDs."; 956 leaf interface { 957 type if:interface-ref; 958 description 959 "Reference to device interface."; 960 } 961 leaf msd { 962 type uint8; 963 description 964 "MSD supported by the interface."; 965 } 966 } 967 } 968 } 970 augment "/rt:routing/sr:segment-routing" { 971 description 972 "This augments routing data model (RFC 8349) 973 with Segment Routing (SR)."; 974 container sr-mpls { 975 description 976 "Segment Routing global configuration."; 977 uses sr-cmn:node-capabilities; 978 container msd { 979 if-feature "max-sid-depth"; 980 description 981 "MSD configuration."; 982 uses max-sid-depth; 983 } 984 container bindings { 985 description 986 "List of bindings."; 987 container mapping-server { 988 if-feature "mapping-server"; 989 description 990 "Configuration of mapping-server local entries."; 991 list policy { 992 key "name"; 993 description 994 "List mapping-server policies."; 995 leaf name { 996 type string; 997 description 998 "Name of the mapping policy."; 999 } 1000 container entries { 1001 description 1002 "IPv4/IPv6 mapping entries."; 1003 list mapping-entry { 1004 key "prefix algorithm"; 1005 description 1006 "Mapping entries."; 1008 uses sr-cmn:prefix-sid; 1009 } 1010 } 1011 } 1012 } 1013 container connected-prefix-sid-map { 1014 description 1015 "Prefix SID configuration."; 1016 list connected-prefix-sid { 1017 key "prefix algorithm"; 1018 description 1019 "List of prefix SID mapped to IPv4/IPv6 1020 local prefixes."; 1021 uses sr-cmn:prefix-sid; 1022 uses sr-cmn:last-hop-behavior; 1023 } 1024 } 1025 container local-prefix-sid { 1026 description 1027 "Local sid configuration."; 1028 list local-prefix-sid { 1029 key "prefix algorithm"; 1030 description 1031 "List of local IPv4/IPv6 prefix-sids."; 1032 uses sr-cmn:prefix-sid; 1033 } 1034 } 1035 } 1036 container global-srgb { 1037 description 1038 "Global SRGB configuration."; 1039 uses sr-cmn:srgb; 1040 } 1041 container srlb { 1042 description 1043 "Segment Routing Local Block (SRLB) configuration."; 1044 uses sr-cmn:srlb; 1045 } 1047 list label-blocks { 1048 config false; 1049 description 1050 "List of label blocks currently in use."; 1051 leaf lower-bound { 1052 type uint32; 1053 description 1054 "Lower bound of the label block."; 1055 } 1056 leaf upper-bound { 1057 type uint32; 1058 description 1059 "Upper bound of the label block."; 1060 } 1061 leaf size { 1062 type uint32; 1063 description 1064 "Number of indexes in the block."; 1065 } 1066 leaf free { 1067 type uint32; 1068 description 1069 "Number of free indexes in the block."; 1070 } 1071 leaf used { 1072 type uint32; 1073 description 1074 "Number of indexes in use in the block."; 1075 } 1076 leaf scope { 1077 type enumeration { 1078 enum "global" { 1079 description 1080 "Global SID."; 1081 } 1082 enum "local" { 1083 description 1084 "Local SID."; 1085 } 1086 } 1087 description 1088 "Scope of this label block."; 1089 } 1090 } 1091 container sid-db { 1092 config false; 1093 description 1094 "List of prefix and SID associations."; 1095 list sid { 1096 key "target sid source source-protocol binding-type"; 1097 ordered-by system; 1098 description 1099 "SID Binding."; 1100 leaf target { 1101 type string; 1102 description 1103 "Defines the target of the binding. It can be a 1104 prefix or something else."; 1105 } 1106 leaf sid { 1107 type uint32; 1108 description 1109 "Index associated with the prefix."; 1110 } 1111 leaf algorithm { 1112 type uint8; 1113 description 1114 "Algorithm to be used for the prefix SID."; 1115 } 1116 leaf source { 1117 type inet:ip-address; 1118 description 1119 "IP address of the router that owns the binding."; 1120 } 1121 leaf used { 1122 type boolean; 1123 description 1124 "Indicates if the binding is install in the 1125 forwarding plane."; 1126 } 1127 leaf source-protocol { 1128 type leafref { 1129 path "/rt:routing/rt:control-plane-protocols/" 1130 + "rt:control-plane-protocol/rt:name"; 1131 } 1132 description 1133 "Routing protocol that owns the binding"; 1134 } 1135 leaf binding-type { 1136 type enumeration { 1137 enum "prefix-sid" { 1138 description 1139 "Binding is learned from a prefix SID."; 1140 } 1141 enum "binding-tlv" { 1142 description 1143 "Binding is learned from a binding TLV."; 1144 } 1145 } 1146 description 1147 "Type of binding."; 1148 } 1149 leaf scope { 1150 type enumeration { 1151 enum "global" { 1152 description 1153 "Global SID."; 1154 } 1155 enum "local" { 1156 description 1157 "Local SID."; 1158 } 1159 } 1160 description 1161 "SID scoping."; 1162 } 1163 } 1164 } 1165 } 1166 } 1168 notification segment-routing-global-srgb-collision { 1169 description 1170 "This notification is sent when SRGB blocks received from 1171 routers conflict."; 1172 list srgb-collisions { 1173 description 1174 "List of SRGB blocks that conflict."; 1175 leaf lower-bound { 1176 type uint32; 1177 description 1178 "Lower value in the block."; 1179 } 1180 leaf upper-bound { 1181 type uint32; 1182 description 1183 "Upper value in the block."; 1184 } 1185 leaf routing-protocol { 1186 type leafref { 1187 path "/rt:routing/rt:control-plane-protocols/" 1188 + "rt:control-plane-protocol/rt:name"; 1189 } 1190 description 1191 "Routing protocol reference for SRGB collision."; 1192 } 1193 leaf originating-rtr-id { 1194 type router-id; 1195 description 1196 "Originating Router ID of this SRGB block."; 1197 } 1198 } 1199 } 1200 notification segment-routing-global-sid-collision { 1201 description 1202 "This notification is sent when a new mapping is learned 1203 containing s mapping where the SID is already used. 1204 The notification generation must be throttled with at least 1205 a 5 second gap between notifications."; 1206 leaf received-target { 1207 type string; 1208 description 1209 "Target received in the router advertisement that caused 1210 the SID collision."; 1211 } 1212 leaf new-sid-rtr-id { 1213 type router-id; 1214 description 1215 "Router ID that advertised the conflicting SID."; 1216 } 1217 leaf original-target { 1218 type string; 1219 description 1220 "Target already available in the database with the same SID 1221 as the received target."; 1222 } 1223 leaf original-sid-rtr-id { 1224 type router-id; 1225 description 1226 "Router-ID for the router that originally advertised the 1227 conflicting SID, i.e., the instance in the database."; 1228 } 1229 leaf index { 1230 type uint32; 1231 description 1232 "Value of the index used by two different prefixes."; 1233 } 1234 leaf routing-protocol { 1235 type leafref { 1236 path "/rt:routing/rt:control-plane-protocols/" 1237 + "rt:control-plane-protocol/rt:name"; 1238 } 1239 description 1240 "Routing protocol reference for conflicting SID."; 1241 } 1242 } 1243 notification segment-routing-index-out-of-range { 1244 description 1245 "This notification is sent when a binding is received 1246 containing a segment index which is out of the local 1247 configured ranges. The notification generation must be 1248 throttled with at least a 5 second gap between 1249 notifications."; 1250 leaf received-target { 1251 type string; 1252 description 1253 "Target received in the router advertisement with 1254 the out-of-range index."; 1255 } 1256 leaf received-index { 1257 type uint32; 1258 description 1259 "Value of the index received."; 1260 } 1261 leaf routing-protocol { 1262 type leafref { 1263 path "/rt:routing/rt:control-plane-protocols/" 1264 + "rt:control-plane-protocol/rt:name"; 1265 } 1266 description 1267 "Routing protocol reference for out-of-range indexd."; 1268 } 1269 } 1270 } 1271 1273 9. Security Considerations 1275 The YANG modules specified in this document define a schema for data 1276 that is designed to be accessed via network management protocols such 1277 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1278 is the secure transport layer, and the mandatory-to-implement secure 1279 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1280 is HTTPS, and the mandatory-to-implement secure transport is TLS 1281 [RFC5246]. 1283 The NETCONF access control model [RFC6536] provides the means to 1284 restrict access for particular NETCONF or RESTCONF users to a pre- 1285 configured subset of all available NETCONF or RESTCONF protocol 1286 operations and content. 1288 There are a number of data nodes defined in the modules that are 1289 writable/creatable/deletable (i.e., config true, which is the 1290 default). These data nodes may be considered sensitive or vulnerable 1291 in some network environments. Write operations (e.g., edit-config) 1292 to these data nodes without proper protection can have a negative 1293 effect on network operations. 1295 Some of the readable data nodes in the modules may be considered 1296 sensitive or vulnerable in some network environments. It is thus 1297 important to control read access (e.g., via get, get-config, or 1298 notification) to these data nodes. 1300 10. Acknowledgements 1302 Authors would like to thank Derek Yeung, Greg Hankins, Hannes 1303 Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge, Les Ginsberg for 1304 their contributions. 1306 11. IANA Considerations 1308 This document registers a URI in the IETF XML registry [RFC3688]. 1309 Following the format in [RFC3688], the following registration is 1310 requested to be made: 1312 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing-commmon 1313 Registrant Contact: The IESG. 1314 XML: N/A, the requested URI is an XML namespace. 1316 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing 1317 Registrant Contact: The IESG. 1318 XML: N/A, the requested URI is an XML namespace. 1320 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls 1321 Registrant Contact: The IESG. 1322 XML: N/A, the requested URI is an XML namespace. 1324 This document registers a YANG module in the YANG Module Names 1325 registry [RFC6020]. 1327 name: ietf-segment-routing-common 1328 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common 1329 prefix: sr-cmn 1330 reference: RFC XXXX 1332 name: ietf-segment-routing 1333 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing 1334 prefix: sr 1335 reference: RFC XXXX 1337 name: ietf-segment-routing 1338 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls 1339 prefix: sr-mpls 1340 reference: RFC XXXX 1342 12. References 1344 12.1. Normative References 1346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1347 Requirement Levels", BCP 14, RFC 2119, 1348 DOI 10.17487/RFC2119, March 1997, 1349 . 1351 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1352 DOI 10.17487/RFC3688, January 2004, 1353 . 1355 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1356 (TLS) Protocol Version 1.2", RFC 5246, 1357 DOI 10.17487/RFC5246, August 2008, 1358 . 1360 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1361 the Network Configuration Protocol (NETCONF)", RFC 6020, 1362 DOI 10.17487/RFC6020, October 2010, 1363 . 1365 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1366 and A. Bierman, Ed., "Network Configuration Protocol 1367 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1368 . 1370 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1371 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1372 . 1374 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1375 Protocol (NETCONF) Access Control Model", RFC 6536, 1376 DOI 10.17487/RFC6536, March 2012, 1377 . 1379 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1380 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1381 . 1383 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1384 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1385 . 1387 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1388 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1389 . 1391 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1392 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1393 May 2017, . 1395 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1396 "Common YANG Data Types for the Routing Area", RFC 8294, 1397 DOI 10.17487/RFC8294, December 2017, 1398 . 1400 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1401 and R. Wilton, "Network Management Datastore Architecture 1402 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1403 . 1405 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1406 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1407 . 1409 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1410 Routing Management (NMDA Version)", RFC 8349, 1411 DOI 10.17487/RFC8349, March 2018, 1412 . 1414 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1415 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1416 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1417 July 2018, . 1419 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1420 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1421 DOI 10.17487/RFC8476, December 2018, 1422 . 1424 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1425 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1426 DOI 10.17487/RFC8491, November 2018, 1427 . 1429 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1430 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1431 Routing with the MPLS Data Plane", RFC 8660, 1432 DOI 10.17487/RFC8660, December 2019, 1433 . 1435 12.2. Informative References 1437 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1438 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1439 . 1441 Appendix A. Configuration example 1443 The following is an XML example using the SR MPLS YANG modules. 1445 1446 1448 1450 1451 5 1452 1453 1454 1455 1456 mapping 1 1457 1458 1459 198.51.100.0/24 1460 1463 sr-cmn:prefix-sid-algorithm-shortest-path 1464 200 1465 100 1466 1467 1468 1469 1470 1471 1472 192.0.2.0/24 1473 1475 sr-cmn:prefix-sid-algorithm-strict-spf 1476 100 1477 1 1478 php 1479 1480 1481 1482 1483 1484 45000 1485 55000 1486 1487 1488 1489 1490 1491 Authors' Addresses 1493 Stephane Litkowski 1494 Cisco Systems 1496 Email: slitkows.ietf@gmail.com 1498 Yingzhen Qu 1499 Futurewei 1501 Email: yingzhen.qu@futurewei.com 1503 Acee Lindem 1504 Cisco Systems 1505 301 Mindenhall Way 1506 Cary, NC 27513 1507 US 1509 Email: acee@cisco.com 1511 Pushpasis Sarkar 1512 Individual 1514 Email: pushpasis.ietf@gmail.com 1516 Jeff Tantsura 1517 Apstra 1519 Email: jefftant.ietf@gmail.com