idnits 2.17.1 draft-ietf-spring-sr-yang-16.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8402], [RFC7950], [RFC8660], [RFC6020]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 152 has weird spacing: '...terface if:...' == Line 182 has weird spacing: '...r-bound uin...' == Line 183 has weird spacing: '...r-bound uin...' == Line 186 has weird spacing: '...r-bound uin...' == Line 187 has weird spacing: '...r-bound uin...' == (1 more instance...) -- The document date (July 9, 2020) is 1386 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: 3 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-16 17 Abstract 19 This document defines a YANG data model ([RFC6020], [RFC7950]) for 20 segment routing ([RFC8402]) configuration and operation. This YANG 21 model is intended to be used on network elements to configure or 22 operate segment routing MPLS data plane [RFC8660]. This document 23 defines also generic containers that SHOULD be reused by IGP protocol 24 modules to support segment routing. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 10, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 62 2.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 64 3. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 65 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. IGP Control plane configuration . . . . . . . . . . . . . . . 6 67 5.1. IGP interface configuration . . . . . . . . . . . . . . . 7 68 5.1.1. Adjacency SID properties . . . . . . . . . . . . . . 7 69 5.1.1.1. Bundling . . . . . . . . . . . . . . . . . . . . 7 70 5.1.1.2. Protection . . . . . . . . . . . . . . . . . . . 8 71 6. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 78 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 79 12.2. Informative References . . . . . . . . . . . . . . . . . 30 80 Appendix A. Configuration example . . . . . . . . . . . . . . . 30 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 83 1. Introduction 85 This document defines a YANG data model for segment routing 86 configuration and operation. This document does not define the IGP 87 extensions to support segment routing but defines generic groupings 88 that SHOULD be reused by IGP extension modules. The reason of this 89 design choice is to not require implementations to support all IGP 90 extensions. For example, an implementation may support IS-IS 91 extension but not OSPF. 93 The YANG modules in this document conform to the Network Management 94 Datastore Architecture (NMDA) [RFC8342]. 96 2. Terminology and Notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 2.1. Tree diagram 106 Tree diagrams used in this document follow the notation defined in 107 [RFC8340]. 109 2.2. Prefixes in Data Node Names 111 In this document, names of data nodes, actions, and other data model 112 objects are often used without a prefix, as long as it is clear from 113 the context in which YANG module each name is defined. Otherwise, 114 names are prefixed using the standard prefix associated with the 115 corresponding YANG module, as shown in Table 1. 117 +----------+--------------------+-----------+ 118 | Prefix | YANG module | Reference | 119 +----------+--------------------+-----------+ 120 | if | ietf-interfaces | [RFC8343] | 121 | rt | ietf-routing | [RFC8349] | 122 | rt-types | ietf-routing-types | [RFC8294] | 123 | yang | ietf-yang-types | [RFC6991] | 124 | inet | ietf-inet-types | [RFC6991] | 125 +----------+--------------------+-----------+ 127 Table 1: Prefixes and Corresponding YANG Modules 129 3. Design of the Data Model 131 Module ietf-segment-routing augments the routing container in the 132 ietf-routing model [RFC8349], and defines generic segment routing 133 configuration and operational state. This module is augmented by 134 modules supporting different data planes. 136 Module ietf-segment-routing-mpls augments ietf-segment-routing, and 137 supports SR MPLS data plane configuration and operational state. 139 module: ietf-segment-routing 140 augment /rt:routing: 141 +--rw segment-routing 143 module: ietf-segment-routing-mpls 144 augment /rt:routing/sr:segment-routing: 145 +--rw sr-mpls 146 +--ro node-capabilities 147 | +--ro entropy-readable-label-depth? uint8 148 +--rw msd {max-sid-depth}? 149 | +--rw node-msd? uint8 150 | +--rw link-msd 151 | +--rw link-msds* [interface] 152 | +--rw interface if:interface-ref 153 | +--rw msd? uint8 154 +--rw bindings 155 | +--rw mapping-server {mapping-server}? 156 | | +--rw policy* [name] 157 | | +--rw name string 158 | | +--rw entries 159 | | +--rw mapping-entry* [prefix algorithm] 160 | | +--rw prefix inet:ip-prefix 161 | | +--rw value-type? enumeration 162 | | +--rw start-sid uint32 163 | | +--rw range? uint32 164 | | +--rw algorithm identityref 165 | +--rw connected-prefix-sid-map 166 | | +--rw connected-prefix-sid* [prefix algorithm] 167 | | +--rw prefix inet:ip-prefix 168 | | +--rw value-type? enumeration 169 | | +--rw start-sid uint32 170 | | +--rw range? uint32 171 | | +--rw algorithm identityref 172 | | +--rw last-hop-behavior? enumeration 173 | +--rw local-prefix-sid 174 | +--rw local-prefix-sid* [prefix algorithm] 175 | +--rw prefix inet:ip-prefix 176 | +--rw value-type? enumeration 177 | +--rw start-sid uint32 178 | +--rw range? uint32 179 | +--rw algorithm identityref 180 +--rw global-srgb 181 | +--rw srgb* [lower-bound upper-bound] 182 | +--rw lower-bound uint32 183 | +--rw upper-bound uint32 184 +--rw srlb 185 | +--rw srlb* [lower-bound upper-bound] 186 | +--rw lower-bound uint32 187 | +--rw upper-bound uint32 188 +--ro label-blocks* [] 189 | +--ro lower-bound? uint32 190 | +--ro upper-bound? uint32 191 | +--ro size? uint32 192 | +--ro free? uint32 193 | +--ro used? uint32 194 | +--ro scope? enumeration 195 +--ro sid-db 196 +--ro sid* [target sid source source-protocol binding-type] 197 +--ro target string 198 +--ro sid uint32 199 +--ro algorithm? uint8 200 +--ro source inet:ip-address 201 +--ro used? boolean 202 +--ro source-protocol -> /rt:routing 203 /control-plane-protocols 204 /control-plane-protocol/name 205 +--ro binding-type enumeration 206 +--ro scope? enumeration 208 notifications: 209 +---n segment-routing-global-srgb-collision 210 | +--ro srgb-collisions* [] 211 | +--ro lower-bound? uint32 212 | +--ro upper-bound? uint32 213 | +--ro routing-protocol? -> /rt:routing 214 | /control-plane-protocols 215 | /control-plane-protocol/name 216 | +--ro originating-rtr-id? router-id 217 +---n segment-routing-global-sid-collision 218 | +--ro received-target? string 219 | +--ro new-sid-rtr-id? router-id 220 | +--ro original-target? string 221 | +--ro original-sid-rtr-id? router-id 222 | +--ro index? uint32 223 | +--ro routing-protocol? -> /rt:routing 224 | /control-plane-protocols 225 | /control-plane-protocol/name 226 +---n segment-routing-index-out-of-range 227 +--ro received-target? string 228 +--ro received-index? uint32 229 +--ro routing-protocol? -> /rt:routing 230 /control-plane-protocols 231 /control-plane-protocol/name 233 4. Configuration 235 The module ietf-segment-routing-mpls augments the "/rt:routing/ 236 sr:segment-routing:" with a sr-mpls container. This container 237 defines all the configuration parameters related to segment-routing 238 MPLS data plane. 240 The sr-mpls configuration is split in global configuration and 241 interface configuration. 243 The global configuration includes : 245 o bindings : Defines prefix to SID mappings. The operator can 246 control advertisement of Prefix-SID independently for IPv4 and 247 IPv6. Two types of mappings are available: 249 * Mapping-server : maps non local prefixes to a segment ID. 250 Configuration of bindings does not automatically allow 251 advertisement of those bindings. Advertisement must be 252 controlled by each routing-protocol instance (see Section 5). 253 Multiple mapping policies may be defined. 255 * Connected prefixes : maps connected prefixes to a segment ID. 256 Advertisement of the mapping will be done by IGP when enabled 257 for segment routing (see Section 5). The SID value can be 258 expressed as an index (default), or an absolute value. The 259 "last-hop-behavior" configuration dictates the PHP behavior: 260 "explicit-null", "php", or "non-php". 262 o SRGB (Segment Routing Global Block): Defines a list of label 263 blocks represented by a pair of lower-bound/upper-bound labels. 264 The SRGB is also agnostic to the control plane used. So all 265 routing-protocol instance will have to advertise the same SRGB. 267 o SRLB (Segment Routing Local Block): Defines a list of label blocks 268 represented by a pair of lower-bound/upper-bound labels, reserved 269 for lcoal SIDs. 271 5. IGP Control plane configuration 273 Support of segment-routing extensions for a particular IGP control 274 plane is done by augmenting routing-protocol configuration with 275 segment-routing extensions. This augmentation SHOULD be part of 276 separate YANG modules in order to not create any dependency for 277 implementations to support all protocol extensions. 279 This module defines groupings that SHOULD be used by IGP segment 280 routing modules. 282 The "controlplane-cfg" grouping defines the generic global 283 configuration for the IGP. 285 The "enabled" leaf enables segment-routing extensions for the 286 routing-protocol instance. 288 The "bindings" container controls the routing-protocol instance's 289 advertisement of local bindings and the processing of received 290 bindings. 292 5.1. IGP interface configuration 294 The interface configuration is part of the "igp-interface-cfg" 295 grouping and includes Adjacency SID properties. 297 5.1.1. Adjacency SID properties 299 5.1.1.1. Bundling 301 This section is a first proposal on how to use S-bit in Adj-SID to 302 create bundles. Authors would like to trigger discussion based on 303 this first proposal. 305 In case of parallel IP links between routers, an additional Adjacency 306 SID may be advertised representing more than one adjacency (i.e., a 307 bundle of adjacencies). The "advertise-adj-group-sid" configuration 308 controls whether or not an additional adjacency SID is advertised. 310 The "advertise-adj-group-sid" would be a list of "group-id". The 311 "group-id" will permit to identify interfaces that must be bundled 312 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 L2/L3. 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 L3. 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 plan 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-09.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 Editor: Stephane Litkowski 399 400 Editor: Yingzhen Qu 401 403 Author: Acee Lindem 404 405 Author: Pushpasis Sarkar 406 407 Author: Jeff Tantsura 408 410 "; 411 description 412 "The YANG module defines a generic configuration model for 413 Segment Routing common across all of the vendor 414 implementations. It's to be augmented by different SR data 415 planes. 417 This YANG model conforms to the Network Management 418 Datastore Architecture (NMDA) as described in RFC 8242. 420 Copyright (c) 2020 IETF Trust and the persons identified as 421 authors of the code. All rights reserved. 423 Redistribution and use in source and binary forms, with or 424 without modification, is permitted pursuant to, and subject 425 to the license terms contained in, the Simplified BSD License 426 set forth in Section 4.c of the IETF Trust's Legal Provisions 427 Relating to IETF Documents 428 (http://trustee.ietf.org/license-info). 429 This version of this YANG module is part of RFC XXXX; 430 see the RFC itself for full legal notices. 432 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 433 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 434 'MAY', and 'OPTIONAL' in this document are to be interpreted as 435 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 436 they appear in all capitals, as shown here."; 438 reference "RFC XXXX"; 440 revision 2020-07-09 { 441 description 442 "Initial Version"; 443 reference "RFC XXXX: YANG Data Model for Segment Routing."; 444 } 446 augment "/rt:routing" { 447 description 448 "This module augments routing data model (RFC 8349) 449 with Segment Routing (SR)."; 450 container segment-routing { 451 description 452 "Segment Routing configuration. This container 453 is to be augmented by different SR data planes."; 454 reference "RFC 8402: Segment Routing Architecture"; 455 } 456 } 457 } 458 459 file "ietf-segment-routing-common@2020-07-09.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: 478 Editor: Stephane Litkowski 479 480 Editor: Yingzhen Qu 481 483 Author: Acee Lindem 484 485 Author: Pushpasis Sarkar 486 487 Author: Jeff Tantsura 488 490 "; 491 description 492 "The YANG module defines a collection of generic types and 493 grouping for Segment Routing (SR) as described in RFC 8402. 495 This YANG model conforms to the Network Management 496 Datastore Architecture (NMDA) as described in RFC 8242. 498 Copyright (c) 2020 IETF Trust and the persons identified as 499 authors of the code. All rights reserved. 501 Redistribution and use in source and binary forms, with or 502 without modification, is permitted pursuant to, and subject 503 to the license terms contained in, the Simplified BSD License 504 set forth in Section 4.c of the IETF Trust's Legal Provisions 505 Relating to IETF Documents 506 (http://trustee.ietf.org/license-info). 508 This version of this YANG module is part of RFC XXXX; 509 see the RFC itself for full legal notices. 511 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 512 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 513 'MAY', and 'OPTIONAL' in this document are to be interpreted as 514 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 515 they appear in all capitals, as shown here."; 517 reference "RFC XXXX"; 519 revision 2020-07-09 { 520 description 521 "Initial version"; 522 reference "RFC XXXX: YANG Data Model for Segment Routing."; 523 } 524 feature sid-last-hop-behavior { 525 description 526 "Configurable last hop behavior."; 527 reference "RFC 8660: Segment Routing with the MPLS Data Plane"; 528 } 530 identity prefix-sid-algorithm { 531 description 532 "Base identity for prefix-sid algorithm."; 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."; 573 list srgb { 574 key "lower-bound upper-bound"; 575 ordered-by user; 576 description 577 "List of global blocks to be advertised."; 578 uses srlr; 579 } 580 } 582 grouping srlb { 583 description 584 "Grouping for SR Local Block range."; 585 list srlb { 586 key "lower-bound upper-bound"; 587 ordered-by user; 588 description 589 "List of SRLBs."; 590 uses srlr; 591 } 592 } 594 grouping sid-value-type { 595 description 596 "Defines how the SID value is expressed."; 597 leaf value-type { 598 type enumeration { 599 enum "index" { 600 description 601 "The value will be interpreted as an index."; 602 } 603 enum "absolute" { 604 description 605 "The value will become interpreted as an absolute 606 value."; 607 } 608 } 609 default "index"; 610 description 611 "This leaf defines how value must be interpreted."; 612 } 613 } 615 grouping prefix-sid { 616 description 617 "This grouping defines cfg of prefix SID."; 618 leaf prefix { 619 type inet:ip-prefix; 620 description 621 "connected prefix sid."; 622 } 623 uses prefix-sid-attributes; 624 } 626 grouping ipv4-sid { 627 description 628 "Grouping for an IPv4 prefix SID."; 629 leaf prefix { 630 type inet:ipv4-prefix; 631 description 632 "Connected IPv4 prefix sid."; 633 } 634 uses prefix-sid-attributes; 635 } 636 grouping ipv6-sid { 637 description 638 "Grouping for an IPv6 prefix SID."; 639 leaf prefix { 640 type inet:ipv6-prefix; 641 description 642 "Connected ipv6 prefix sid."; 643 } 644 uses prefix-sid-attributes; 645 } 647 grouping last-hop-behavior { 648 description 649 "Defines last hop behavior"; 650 leaf last-hop-behavior { 651 if-feature "sid-last-hop-behavior"; 652 type enumeration { 653 enum "explicit-null" { 654 description 655 "Use explicit-null for the SID."; 656 } 657 enum "no-php" { 658 description 659 "Do not use Penultimate Hop Popping (PHP) 660 for the SID."; 661 } 662 enum "php" { 663 description 664 "Use PHP for the SID."; 665 } 666 } 667 description 668 "Configure last hop behavior."; 669 } 670 } 672 grouping node-capabilities { 673 description 674 "Containing SR node capabilities."; 675 container node-capabilities { 676 config false; 677 description 678 "Shows the SR capability of the node."; 679 leaf entropy-readable-label-depth { 680 type uint8; 681 description 682 "Maximum label stack depth that a router can read."; 683 } 684 } 685 } 687 grouping prefix-sid-attributes { 688 description 689 "Grouping for Segment Routing (SR) prefix attributes."; 690 uses sid-value-type; 691 leaf start-sid { 692 type uint32; 693 mandatory true; 694 description 695 "Value associated with prefix. The value must be 696 interpreted in the context of value-type."; 697 } 698 leaf range { 699 type uint32; 700 description 701 "Indicates how many SIDs can be allocated."; 702 } 703 leaf algorithm { 704 type identityref { 705 base prefix-sid-algorithm; 706 } 707 description 708 "Prefix-sid algorithm."; 709 } 710 } 711 } 712 713 file "ietf-segment-routing-mpls@2020-07-09.yang" 714 module ietf-segment-routing-mpls { 715 yang-version 1.1; 716 namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls"; 717 prefix sr-mpls; 719 import ietf-inet-types { 720 prefix inet; 721 reference "RFC 6991: Common YANG Data Types"; 722 } 723 import ietf-routing { 724 prefix rt; 725 reference "RFC 8349: A YANG Data Model for Routing 726 Management (NMDA Version)"; 727 } 728 import ietf-interfaces { 729 prefix if; 730 reference "RFC 8343: A YANG Data Model for Interface 731 Management (NMDA Version)"; 732 } 733 import ietf-routing-types { 734 prefix rt-types; 735 reference "RFC 8294: Common YANG Data Types for the 736 Routing Area"; 737 } 738 import ietf-segment-routing { 739 prefix sr; 740 } 741 import ietf-segment-routing-common { 742 prefix sr-cmn; 743 } 745 organization 746 "IETF SPRING - SPRING Working Group"; 747 contact 748 "WG Web: 749 WG List: 751 Editor: Stephane Litkowski 752 753 Editor: Yingzhen Qu 754 756 Author: Acee Lindem 757 758 Author: Pushpasis Sarkar 759 760 Author: Jeff Tantsura 761 763 "; 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-09 { 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 string; 861 description 862 "List of binding advertisement policies."; 863 } 864 } 865 leaf receive { 866 type boolean; 867 default "true"; 868 description 869 "Allow the reception and usage of binding TLVs."; 870 } 871 } 872 } 873 } 875 grouping igp-interface { 876 description 877 "Grouping for IGP interface configuration."; 878 container segment-routing { 879 description 880 "Container for SR interface configuration."; 881 container adjacency-sid { 882 description 883 "Adjacency SID configuration."; 884 list adj-sids { 885 key "value"; 886 uses sr-cmn:sid-value-type; 887 leaf value { 888 type uint32; 889 description 890 "Value of the Adj-SID."; 891 } 892 leaf protected { 893 type boolean; 894 default false; 895 description 896 "It is used to protect the mannual adj-SID."; 897 } 898 description 899 "List of adj-sid configuration."; 900 } 901 list advertise-adj-group-sid { 902 key "group-id"; 903 description 904 "Control advertisement of S flag. Enable advertisement 905 of a common Adj-SID for parallel links."; 906 leaf group-id { 907 type uint32; 908 description 909 "The value is an internal value to identify a 910 group-ID. Interfaces with the same group-ID will be 911 bundled together."; 912 } 913 } 914 leaf advertise-protection { 915 type enumeration { 916 enum "single" { 917 description 918 "A single Adj-SID is associated with the adjacency 919 and reflects the protection configuration."; 920 } 921 enum "dual" { 922 description 923 "Two Adj-SIDs will be associated with the adjacency 924 if the interface is protected. In this case, will 925 be advertised with backup flag set, the other will 926 be advertised with theo backup flag clear. In case 927 protection is not configured, single Adj-SID will 928 be advertised with the backup flag clear."; 929 } 930 } 931 description 932 "If set, the Adj-SID refers to a protected adjacency."; 933 } 934 } 935 } 936 } 938 grouping max-sid-depth { 939 description 940 "Maximum SID Depth (MSD)D configuration grouping."; 941 leaf node-msd { 942 type uint8; 943 description 944 "Node MSD is the lowest MSD supported by the node."; 945 } 946 container link-msd { 947 description 948 "MSD supported by an individual interface."; 949 list link-msds { 950 key "interface"; 951 description 952 "List of link MSDs."; 953 leaf interface { 954 type if:interface-ref; 955 description 956 "Reference to device interface."; 958 } 959 leaf msd { 960 type uint8; 961 description 962 "MSD supported by the interface."; 963 } 964 } 965 } 966 } 968 augment "/rt:routing/sr:segment-routing" { 969 description 970 "This augments routing data model (RFC 8349) 971 with Segment Routing (SR)."; 972 container sr-mpls { 973 description 974 "Segment Routing global configuration."; 975 uses sr-cmn:node-capabilities; 976 container msd { 977 if-feature "max-sid-depth"; 978 description 979 "MSD configuration."; 980 uses max-sid-depth; 981 } 982 container bindings { 983 description 984 "List of bindings."; 985 container mapping-server { 986 if-feature "mapping-server"; 987 description 988 "Configuration of mapping-server local entries."; 989 list policy { 990 key "name"; 991 description 992 "List mapping-server policies."; 993 leaf name { 994 type string; 995 description 996 "Name of the mapping policy."; 997 } 998 container entries { 999 description 1000 "IPv4/IPv6 mapping entries."; 1001 list mapping-entry { 1002 key "prefix algorithm"; 1003 description 1004 "Mapping entries."; 1005 uses sr-cmn:prefix-sid; 1007 } 1008 } 1009 } 1010 } 1011 container connected-prefix-sid-map { 1012 description 1013 "Prefix SID configuration."; 1014 list connected-prefix-sid { 1015 key "prefix algorithm"; 1016 description 1017 "List of prefix SID mapped to IPv4/IPv6 1018 local prefixes."; 1019 uses sr-cmn:prefix-sid; 1020 uses sr-cmn:last-hop-behavior; 1021 } 1022 } 1023 container local-prefix-sid { 1024 description 1025 "Local sid configuration."; 1026 list local-prefix-sid { 1027 key "prefix algorithm"; 1028 description 1029 "List of local IPv4/IPv6 prefix-sids."; 1030 uses sr-cmn:prefix-sid; 1031 } 1032 } 1033 } 1034 container global-srgb { 1035 description 1036 "Global SRGB configuration."; 1037 uses sr-cmn:srgb; 1038 } 1039 container srlb { 1040 description 1041 "Segment Routing Local Block (SRLB) configuration."; 1042 uses sr-cmn:srlb; 1043 } 1045 list label-blocks { 1046 config false; 1047 description 1048 "List of label blocks currently in use."; 1049 leaf lower-bound { 1050 type uint32; 1051 description 1052 "Lower bound of the label block."; 1053 } 1054 leaf upper-bound { 1055 type uint32; 1056 description 1057 "Upper bound of the label block."; 1058 } 1059 leaf size { 1060 type uint32; 1061 description 1062 "Number of indexes in the block."; 1063 } 1064 leaf free { 1065 type uint32; 1066 description 1067 "Number of free indexes in the block."; 1068 } 1069 leaf used { 1070 type uint32; 1071 description 1072 "Number of indexes in use in the block."; 1073 } 1074 leaf scope { 1075 type enumeration { 1076 enum "global" { 1077 description 1078 "Global SID."; 1079 } 1080 enum "local" { 1081 description 1082 "Local SID."; 1083 } 1084 } 1085 description 1086 "Scope of this label block."; 1087 } 1088 } 1089 container sid-db { 1090 config false; 1091 description 1092 "List of prefix and SID associations."; 1093 list sid { 1094 key "target sid source source-protocol binding-type"; 1095 ordered-by system; 1096 description 1097 "SID Binding."; 1098 leaf target { 1099 type string; 1100 description 1101 "Defines the target of the binding. It can be a 1102 prefix or something else."; 1104 } 1105 leaf sid { 1106 type uint32; 1107 description 1108 "Index associated with the prefix."; 1109 } 1110 leaf algorithm { 1111 type uint8; 1112 description 1113 "Algorithm to be used for the prefix SID."; 1114 } 1115 leaf source { 1116 type inet:ip-address; 1117 description 1118 "IP address of the router that owns the binding."; 1119 } 1120 leaf used { 1121 type boolean; 1122 description 1123 "Indicates if the binding is install in the 1124 forwarding plane."; 1125 } 1126 leaf source-protocol { 1127 type leafref { 1128 path "/rt:routing/rt:control-plane-protocols/" 1129 + "rt:control-plane-protocol/rt:name"; 1130 } 1131 description 1132 "Routing protocol that owns the binding"; 1133 } 1134 leaf binding-type { 1135 type enumeration { 1136 enum "prefix-sid" { 1137 description 1138 "Binding is learned from a prefix SID."; 1139 } 1140 enum "binding-tlv" { 1141 description 1142 "Binding is learned from a binding TLV."; 1143 } 1144 } 1145 description 1146 "Type of binding."; 1147 } 1148 leaf scope { 1149 type enumeration { 1150 enum "global" { 1151 description 1152 "Global SID."; 1153 } 1154 enum "local" { 1155 description 1156 "Local SID."; 1157 } 1158 } 1159 description 1160 "SID scoping."; 1161 } 1162 } 1163 } 1164 } 1165 } 1167 notification segment-routing-global-srgb-collision { 1168 description 1169 "This notification is sent when SRGB blocks received from 1170 routers conflict."; 1171 list srgb-collisions { 1172 description 1173 "List of SRGB blocks that conflict."; 1174 leaf lower-bound { 1175 type uint32; 1176 description 1177 "Lower value in the block."; 1178 } 1179 leaf upper-bound { 1180 type uint32; 1181 description 1182 "Upper value in the block."; 1183 } 1184 leaf routing-protocol { 1185 type leafref { 1186 path "/rt:routing/rt:control-plane-protocols/" 1187 + "rt:control-plane-protocol/rt:name"; 1188 } 1189 description 1190 "Routing protocol reference for SRGB collision."; 1191 } 1192 leaf originating-rtr-id { 1193 type router-id; 1194 description 1195 "Originating Router ID of this SRGB block."; 1196 } 1197 } 1198 } 1199 notification segment-routing-global-sid-collision { 1200 description 1201 "This notification is sent when a new mapping is learned 1202 containing s mapping where the SID is already used. 1203 The notification generation must be throttled with at least 1204 a 5 second gap between notifications."; 1205 leaf received-target { 1206 type string; 1207 description 1208 "Target received in the router advertisement that caused 1209 the SID collision."; 1210 } 1211 leaf new-sid-rtr-id { 1212 type router-id; 1213 description 1214 "Router ID that advertised the conflicting SID."; 1215 } 1216 leaf original-target { 1217 type string; 1218 description 1219 "Target already available in the database with the same SID 1220 as the received target."; 1221 } 1222 leaf original-sid-rtr-id { 1223 type router-id; 1224 description 1225 "Router-ID for the router that originally advertised the 1226 conflicting SID, i.e., the instance in the database."; 1227 } 1228 leaf index { 1229 type uint32; 1230 description 1231 "Value of the index used by two different prefixes."; 1232 } 1233 leaf routing-protocol { 1234 type leafref { 1235 path "/rt:routing/rt:control-plane-protocols/" 1236 + "rt:control-plane-protocol/rt:name"; 1237 } 1238 description 1239 "Routing protocol reference for conflicting SID."; 1240 } 1241 } 1242 notification segment-routing-index-out-of-range { 1243 description 1244 "This notification is sent when a binding is received 1245 containing a segment index which is out of the local 1246 configured ranges. The notification generation must be 1247 throttled with at least a 5 second gap between 1248 notifications."; 1249 leaf received-target { 1250 type string; 1251 description 1252 "Target received in the router advertisement with 1253 the out-of-range index."; 1254 } 1255 leaf received-index { 1256 type uint32; 1257 description 1258 "Value of the index received."; 1259 } 1260 leaf routing-protocol { 1261 type leafref { 1262 path "/rt:routing/rt:control-plane-protocols/" 1263 + "rt:control-plane-protocol/rt:name"; 1264 } 1265 description 1266 "Routing protocol reference for out-of-range indexd."; 1267 } 1268 } 1269 } 1270 1272 9. Security Considerations 1274 The YANG modules specified in this document define a schema for data 1275 that is designed to be accessed via network management protocols such 1276 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1277 is the secure transport layer, and the mandatory-to-implement secure 1278 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1279 is HTTPS, and the mandatory-to-implement secure transport is TLS 1280 [RFC5246]. 1282 The NETCONF access control model [RFC6536] provides the means to 1283 restrict access for particular NETCONF or RESTCONF users to a pre- 1284 configured subset of all available NETCONF or RESTCONF protocol 1285 operations and content. 1287 There are a number of data nodes defined in the modules that are 1288 writable/creatable/deletable (i.e., config true, which is the 1289 default). These data nodes may be considered sensitive or vulnerable 1290 in some network environments. Write operations (e.g., edit-config) 1291 to these data nodes without proper protection can have a negative 1292 effect on network operations. 1294 Some of the readable data nodes in the modules may be considered 1295 sensitive or vulnerable in some network environments. It is thus 1296 important to control read access (e.g., via get, get-config, or 1297 notification) to these data nodes. 1299 10. Acknowledgements 1301 Authors would like to thank Derek Yeung, Greg Hankins, Hannes 1302 Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge, Les Ginsberg for 1303 their contributions. 1305 11. IANA Considerations 1307 This document registers a URI in the IETF XML registry [RFC3688]. 1308 Following the format in [RFC3688], the following registration is 1309 requested to be made: 1311 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing-commmon 1312 Registrant Contact: The IESG. 1313 XML: N/A, the requested URI is an XML namespace. 1315 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing 1316 Registrant Contact: The IESG. 1317 XML: N/A, the requested URI is an XML namespace. 1319 This document registers a YANG module in the YANG Module Names 1320 registry [RFC6020]. 1322 name: ietf-segment-routing-common 1323 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common 1324 prefix: sr-cmn 1325 reference: RFC XXXX 1327 name: ietf-segment-routing 1328 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing 1329 prefix: sr 1330 reference: RFC XXXX 1332 12. References 1334 12.1. Normative References 1336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1337 Requirement Levels", BCP 14, RFC 2119, 1338 DOI 10.17487/RFC2119, March 1997, 1339 . 1341 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1342 DOI 10.17487/RFC3688, January 2004, 1343 . 1345 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1346 (TLS) Protocol Version 1.2", RFC 5246, 1347 DOI 10.17487/RFC5246, August 2008, 1348 . 1350 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1351 the Network Configuration Protocol (NETCONF)", RFC 6020, 1352 DOI 10.17487/RFC6020, October 2010, 1353 . 1355 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1356 and A. Bierman, Ed., "Network Configuration Protocol 1357 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1358 . 1360 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1361 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1362 . 1364 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1365 Protocol (NETCONF) Access Control Model", RFC 6536, 1366 DOI 10.17487/RFC6536, March 2012, 1367 . 1369 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1370 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1371 . 1373 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1374 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1375 . 1377 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1378 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1379 . 1381 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1382 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1383 May 2017, . 1385 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1386 "Common YANG Data Types for the Routing Area", RFC 8294, 1387 DOI 10.17487/RFC8294, December 2017, 1388 . 1390 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1391 and R. Wilton, "Network Management Datastore Architecture 1392 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1393 . 1395 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1396 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1397 . 1399 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1400 Routing Management (NMDA Version)", RFC 8349, 1401 DOI 10.17487/RFC8349, March 2018, 1402 . 1404 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1405 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1406 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1407 July 2018, . 1409 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1410 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1411 DOI 10.17487/RFC8476, December 2018, 1412 . 1414 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1415 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1416 DOI 10.17487/RFC8491, November 2018, 1417 . 1419 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1420 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1421 Routing with the MPLS Data Plane", RFC 8660, 1422 DOI 10.17487/RFC8660, December 2019, 1423 . 1425 12.2. Informative References 1427 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1428 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1429 . 1431 Appendix A. Configuration example 1433 The following is an XML example using the SR MPLS YANG modules. 1435 1436 1438 1440 1441 5 1442 1443 1444 1445 1446 mapping 1 1447 1448 1449 198.51.100.0/24 1450 1453 sr-cmn:prefix-sid-algorithm-shortest-path 1454 200 1455 100 1456 1457 1458 1459 1460 1461 1462 192.0.2.0/24 1463 1465 sr-cmn:prefix-sid-algorithm-strict-spf 1466 100 1467 1 1468 php 1469 1470 1471 1472 1473 1474 45000 1475 55000 1476 1477 1478 1479 1480 1481 Authors' Addresses 1483 Stephane Litkowski 1484 Cisco Systems 1486 Email: slitkows.ietf@gmail.com 1488 Yingzhen Qu 1489 Futurewei 1491 Email: yingzhen.qu@futurewei.com 1493 Acee Lindem 1494 Cisco Systems 1495 301 Mindenhall Way 1496 Cary, NC 27513 1497 US 1499 Email: acee@cisco.com 1501 Pushpasis Sarkar 1502 Individual 1504 Email: pushpasis.ietf@gmail.com 1506 Jeff Tantsura 1507 Apstra 1509 Email: jefftant.ietf@gmail.com