idnits 2.17.1 draft-ietf-spring-sr-yang-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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 151 has weird spacing: '...terface if:...' == Line 181 has weird spacing: '...r-bound uin...' == Line 182 has weird spacing: '...r-bound uin...' == Line 185 has weird spacing: '...r-bound uin...' == Line 186 has weird spacing: '...r-bound uin...' == (1 more instance...) -- The document date (January 9, 2020) is 1569 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: 4 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: July 12, 2020 Futurewei 6 A. Lindem 7 Cisco Systems 8 P. Sarkar 9 Individual 10 J. Tantsura 11 Apstra 12 January 9, 2020 14 YANG Data Model for Segment Routing 15 draft-ietf-spring-sr-yang-15 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 July 12, 2020. 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 . . . . . . . . . . . . . . . . . . . 26 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 78 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 79 12.2. Informative References . . . . . . . . . . . . . . . . . 29 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 82 1. Introduction 84 This document defines a YANG data model for segment routing 85 configuration and operation. This document does not define the IGP 86 extensions to support segment routing but defines generic groupings 87 that SHOULD be reused by IGP extension modules. The reason of this 88 design choice is to not require implementations to support all IGP 89 extensions. For example, an implementation may support IS-IS 90 extension but not OSPF. 92 The YANG modules in this document conform to the Network Management 93 Datastore Architecture (NMDA) [RFC8342]. 95 2. Terminology and Notation 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2.1. Tree diagram 105 Tree diagrams used in this document follow the notation defined in 106 [RFC8340]. 108 2.2. Prefixes in Data Node Names 110 In this document, names of data nodes, actions, and other data model 111 objects are often used without a prefix, as long as it is clear from 112 the context in which YANG module each name is defined. Otherwise, 113 names are prefixed using the standard prefix associated with the 114 corresponding YANG module, as shown in Table 1. 116 +----------+--------------------+-----------+ 117 | Prefix | YANG module | Reference | 118 +----------+--------------------+-----------+ 119 | if | ietf-interfaces | [RFC8343] | 120 | rt | ietf-routing | [RFC8349] | 121 | rt-types | ietf-routing-types | [RFC8294] | 122 | yang | ietf-yang-types | [RFC6991] | 123 | inet | ietf-inet-types | [RFC6991] | 124 +----------+--------------------+-----------+ 126 Table 1: Prefixes and Corresponding YANG Modules 128 3. Design of the Data Model 130 Module ietf-segment-routing augments the routing container in the 131 ietf-routing model [RFC8349], and defines generic segment routing 132 configuration and operational state. This module is augmented by 133 modules supporting different data planes. 135 Module ietf-segment-routing-mpls augments ietf-segment-routing, and 136 supports SR MPLS data plane configuration and operational state. 138 module: ietf-segment-routing 139 augment /rt:routing: 140 +--rw segment-routing 142 module: ietf-segment-routing-mpls 143 augment /rt:routing/sr:segment-routing: 144 +--rw sr-mpls 145 +--ro node-capabilities 146 | +--ro entropy-readable-label-depth? uint8 147 +--rw msd {max-sid-depth}? 148 | +--rw node-msd? uint8 149 | +--rw link-msd 150 | +--rw link-msds* [interface] 151 | +--rw interface if:interface-ref 152 | +--rw msd? uint8 153 +--rw bindings 154 | +--rw mapping-server {mapping-server}? 155 | | +--rw policy* [name] 156 | | +--rw name string 157 | | +--rw entries 158 | | +--rw mapping-entry* [prefix algorithm] 159 | | +--rw prefix inet:ip-prefix 160 | | +--rw value-type? enumeration 161 | | +--rw start-sid uint32 162 | | +--rw range? uint32 163 | | +--rw algorithm identityref 164 | +--rw connected-prefix-sid-map 165 | | +--rw connected-prefix-sid* [prefix algorithm] 166 | | +--rw prefix inet:ip-prefix 167 | | +--rw value-type? enumeration 168 | | +--rw start-sid uint32 169 | | +--rw range? uint32 170 | | +--rw algorithm identityref 171 | | +--rw last-hop-behavior? enumeration {sid-last-hop-behavior}? 172 | +--rw local-prefix-sid 173 | +--rw local-prefix-sid* [prefix algorithm] 174 | +--rw prefix inet:ip-prefix 175 | +--rw value-type? enumeration 176 | +--rw start-sid uint32 177 | +--rw range? uint32 178 | +--rw algorithm identityref 179 +--rw global-srgb 180 | +--rw srgb* [lower-bound upper-bound] 181 | +--rw lower-bound uint32 182 | +--rw upper-bound uint32 183 +--rw srlb 184 | +--rw srlb* [lower-bound upper-bound] 185 | +--rw lower-bound uint32 186 | +--rw upper-bound uint32 187 +--ro label-blocks* [] 188 | +--ro lower-bound? uint32 189 | +--ro upper-bound? uint32 190 | +--ro size? uint32 191 | +--ro free? uint32 192 | +--ro used? uint32 193 | +--ro scope? enumeration 194 +--ro sid-db 195 +--ro sid* [target sid source source-protocol binding-type] 196 +--ro target string 197 +--ro sid uint32 198 +--ro algorithm? uint8 199 +--ro source inet:ip-address 200 +--ro used? boolean 201 +--ro source-protocol -> /rt:routing 202 /control-plane-protocols 203 /control-plane-protocol/name 204 +--ro binding-type enumeration 205 +--ro scope? enumeration 207 notifications: 208 +---n segment-routing-global-srgb-collision 209 | +--ro srgb-collisions* [] 210 | +--ro lower-bound? uint32 211 | +--ro upper-bound? uint32 212 | +--ro routing-protocol? -> /rt:routing 213 | /control-plane-protocols 214 | /control-plane-protocol/name 215 | +--ro originating-rtr-id? router-id 216 +---n segment-routing-global-sid-collision 217 | +--ro received-target? string 218 | +--ro new-sid-rtr-id? router-id 219 | +--ro original-target? string 220 | +--ro original-sid-rtr-id? router-id 221 | +--ro index? uint32 222 | +--ro routing-protocol? -> /rt:routing 223 | /control-plane-protocols 224 | /control-plane-protocol/name 225 +---n segment-routing-index-out-of-range 226 +--ro received-target? string 227 +--ro received-index? uint32 228 +--ro routing-protocol? -> /rt:routing 229 /control-plane-protocols 230 /control-plane-protocol/name 232 4. Configuration 234 The module ietf-segment-routing-mpls augments the "/rt:routing/ 235 sr:segment-routing:" with a sr-mpls container. This container 236 defines all the configuration parameters related to segment-routing 237 MPLS data plane. 239 The sr-mpls configuration is split in global configuration and 240 interface configuration. 242 The global configuration includes : 244 o bindings : Defines prefix to SID mappings. The operator can 245 control advertisement of Prefix-SID independently for IPv4 and 246 IPv6. Two types of mappings are available: 248 * Mapping-server : maps non local prefixes to a segment ID. 249 Configuration of bindings does not automatically allow 250 advertisement of those bindings. Advertisement must be 251 controlled by each routing-protocol instance (see Section 5). 252 Multiple mapping policies may be defined. 254 * Connected prefixes : maps connected prefixes to a segment ID. 255 Advertisement of the mapping will be done by IGP when enabled 256 for segment routing (see Section 5). The SID value can be 257 expressed as an index (default), or an absolute value. The 258 "last-hop-behavior" configuration dictates the PHP behavior: 259 "explicit-null", "php", or "non-php". 261 o SRGB (Segment Routing Global Block): Defines a list of label 262 blocks represented by a pair of lower-bound/upper-bound labels. 263 The SRGB is also agnostic to the control plane used. So all 264 routing-protocol instance will have to advertise the same SRGB. 266 o SRLB (Segment Routing Local Block): Defines a list of label blocks 267 represented by a pair of lower-bound/upper-bound labels, reserved 268 for lcoal SIDs. 270 5. IGP Control plane configuration 272 Support of segment-routing extensions for a particular IGP control 273 plane is done by augmenting routing-protocol configuration with 274 segment-routing extensions. This augmentation SHOULD be part of 275 separate YANG modules in order to not create any dependency for 276 implementations to support all protocol extensions. 278 This module defines groupings that SHOULD be used by IGP segment 279 routing modules. 281 The "controlplane-cfg" grouping defines the generic global 282 configuration for the IGP. 284 The "enabled" leaf enables segment-routing extensions for the 285 routing-protocol instance. 287 The "bindings" container controls the routing-protocol instance's 288 advertisement of local bindings and the processing of received 289 bindings. 291 5.1. IGP interface configuration 293 The interface configuration is part of the "igp-interface-cfg" 294 grouping and includes Adjacency SID properties. 296 5.1.1. Adjacency SID properties 298 5.1.1.1. Bundling 300 This section is a first proposal on how to use S-bit in Adj-SID to 301 create bundles. Authors would like to trigger discussion based on 302 this first proposal. 304 In case of parallel IP links between routers, an additional Adjacency 305 SID may be advertised representing more than one adjacency (i.e., a 306 bundle of adjacencies). The "advertise-adj-group-sid" configuration 307 controls whether or not an additional adjacency SID is advertised. 309 The "advertise-adj-group-sid" would be a list of "group-id". The 310 "group-id" will permit to identify interfaces that must be bundled 311 together. 313 +-------+ +------+ 314 | | ------- L1 ---- | | 315 | R1 | ------- L2 ---- | R2 | 316 | | ------- L3 ---- | | 317 | | ------- L4 ---- | | 318 +-------+ +------+ 320 In the figure above, R1 and R2 are interconnected by four links. A 321 routing protocol adjacency is established on each link. Operator 322 would like to create segment-routing Adj-SID that represent some 323 bundles of links. We can imagine two different bundles : L1/L2 and 324 L2/L3. To achieve this behavior, the service provider will configure 325 a "group-id" X for both interfaces L1 and L2 and a "group-id" Y for 326 both interfaces L3 and L3. This will result in R1 advertising an 327 additional Adj-SID for each adjacency, for example a Adj-SID with S 328 flag set and value of 400 will be added to L1 and L2. A Adj-SID with 329 S flag set and value of 500 will be added to L3 and L4. As L1/L2 and 330 L3/L4 does not share the same "group-id", a different SID value will 331 be allocated. 333 5.1.1.2. Protection 335 The "advertise-protection" defines how protection for an interface is 336 advertised. It does not control the activation or deactivation of 337 protection. If the "single" option is used, a single Adj-SID will be 338 advertised for the interface. If the interface is protected, the 339 B-Flag for the Adj-SID advertisement will be set. If the "dual" 340 option is used and if the interface is protected, two Adj-SIDs will 341 be advertised for the interface adjacencies. One Adj-SID will always 342 have the B-Flag set and the other will have the B-Flag clear. This 343 option is intended to be used in the case of traffic engineering 344 where a path must use either protected segments or non-protected 345 segments. 347 6. States 349 The operational states contains information reflecting the usage of 350 allocated SRGB labels. 352 It also includes a list of all global SIDs, their associated 353 bindings, and other information such as the source protocol and 354 algorithm. 356 7. Notifications 358 The model defines the following notifications for segment-routing. 360 o segment-routing-global-srgb-collision: Rasied when a control plan 361 advertised SRGB blocks have conflicts. 363 o segment-routing-global-sid-collision: Raised when a control plane 364 advertised index is already associated with another target (in 365 this version, the only defined targets are IPv4 and IPv6 366 prefixes). 368 o segment-routing-index-out-of-range: Raised when a control plane 369 advertised index fall outside the range of SRGBs configured for 370 the network device. 372 8. YANG Module 374 The following RFCs and drafts are not referenced in the document text 375 but are referenced in the ietf-segment-rouuting-common.yang and/or 376 ietf-segment-routing.yang module: [RFC6991], [RFC8294], [RFC8476], 377 and [RFC8491]. 379 file "ietf-segment-routing@2020-01-09.yang" 380 module ietf-segment-routing { 381 yang-version 1.1; 382 namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing"; 383 prefix sr; 385 import ietf-routing { 386 prefix rt; 387 } 389 organization 390 "IETF SPRING - SPRING Working Group"; 391 contact 392 "WG Web: 393 WG List: 395 Editor: Stephane Litkowski 396 397 Editor: Yingzhen Qu 398 400 Author: Acee Lindem 401 402 Author: Pushpasis Sarkar 403 404 Author: Jeff Tantsura 405 407 "; 408 description 409 "The YANG module defines a generic configuration model for 410 Segment Routing common across all of the vendor 411 implementations. It's to be augmented by different SR data 412 planes. 414 Copyright (c) 2020 IETF Trust and the persons identified as 415 authors of the code. All rights reserved. 417 Redistribution and use in source and binary forms, with or 418 without modification, is permitted pursuant to, and subject 419 to the license terms contained in, the Simplified BSD License 420 set forth in Section 4.c of the IETF Trust's Legal Provisions 421 Relating to IETF Documents 422 (http://trustee.ietf.org/license-info). 424 This version of this YANG module is part of RFC XXXX; 425 see the RFC itself for full legal notices."; 427 reference "RFC XXXX"; 428 revision 2020-01-09 { 429 description 430 "Initial Version"; 431 reference "RFC XXXX: YANG Data Model for Segment Routing."; 432 } 434 augment "/rt:routing" { 435 description 436 "This augments routing data model (RFC 8349) 437 with Segment Routing (SR)."; 438 container segment-routing { 439 description 440 "Segment Routing configuration. This container 441 is to be augmented by different SR data planes."; 442 } 443 } 444 } 445 446 file "ietf-segment-routing-common@2020-01-09.yang" 447 module ietf-segment-routing-common { 448 yang-version 1.1; 449 namespace 450 "urn:ietf:params:xml:ns:yang:ietf-segment-routing-common"; 451 prefix sr-cmn; 453 import ietf-inet-types { 454 prefix inet; 455 } 457 organization 458 "IETF SPRING - SPRING Working Group"; 460 contact 461 "WG Web: 462 WG List: 464 Editor: Stephane Litkowski 465 466 Editor: Yingzhen Qu 467 469 Author: Acee Lindem 470 471 Author: Pushpasis Sarkar 472 473 Author: Jeff Tantsura 474 476 "; 477 description 478 "The YANG module defines a collection of generic types and 479 grouping for Segment Routing (SR) as described in RFC 8402. 481 Copyright (c) 2020 IETF Trust and the persons identified as 482 authors of the code. All rights reserved. 484 Redistribution and use in source and binary forms, with or 485 without modification, is permitted pursuant to, and subject 486 to the license terms contained in, the Simplified BSD License 487 set forth in Section 4.c of the IETF Trust's Legal Provisions 488 Relating to IETF Documents 489 (http://trustee.ietf.org/license-info). 491 This version of this YANG module is part of RFC XXXX; 492 see the RFC itself for full legal notices."; 494 reference "RFC XXXX"; 496 revision 2020-01-09 { 497 description 498 "Initial version"; 499 reference "RFC XXXX: YANG Data Model for Segment Routing."; 500 } 502 feature sid-last-hop-behavior { 503 description 504 "Configurable last hop behavior."; 505 } 507 identity prefix-sid-algorithm { 508 description 509 "Base identity for prefix-sid algorithm."; 510 } 512 identity prefix-sid-algorithm-shortest-path { 513 base prefix-sid-algorithm; 514 description 515 "Shortest Path First (SPF) prefix-sid algorithm. This 516 is the default algorthm."; 517 } 519 identity prefix-sid-algorithm-strict-spf { 520 base prefix-sid-algorithm; 521 description 522 "This algorithm mandates that the packet is forwarded 523 according to ECMP-aware SPF algorithm."; 525 } 527 grouping srlr { 528 description 529 "Grouping for SR Label Range configuration."; 530 leaf lower-bound { 531 type uint32; 532 description 533 "Lower value in the label range."; 534 } 535 leaf upper-bound { 536 type uint32; 537 must "../lower-bound < ../upper-bound" { 538 error-message 539 "The upper-bound must be larger than the lower-bound."; 540 description 541 "The value must be greater than 'lower-bound'."; 542 } 543 description 544 "Upper value in the label range."; 545 } 546 } 548 grouping srgb { 549 description 550 "Grouping for SR Global Label range."; 551 list srgb { 552 key "lower-bound upper-bound"; 553 ordered-by user; 554 description 555 "List of global blocks to be advertised."; 556 uses srlr; 557 } 558 } 560 grouping srlb { 561 description 562 "Grouping for SR Local Block range."; 563 list srlb { 564 key "lower-bound upper-bound"; 565 ordered-by user; 566 description 567 "List of SRLBs."; 568 uses srlr; 569 } 570 } 572 grouping sid-value-type { 573 description 574 "Defines how the SID value is expressed."; 575 leaf value-type { 576 type enumeration { 577 enum "index" { 578 description 579 "The value will be interpreted as an index."; 580 } 581 enum "absolute" { 582 description 583 "The value will become interpreted as an absolute 584 value."; 585 } 586 } 587 default "index"; 588 description 589 "This leaf defines how value must be interpreted."; 590 } 591 } 593 grouping prefix-sid { 594 description 595 "This grouping defines cfg of prefix SID."; 596 leaf prefix { 597 type inet:ip-prefix; 598 description 599 "connected prefix sid."; 600 } 601 uses prefix-sid-attributes; 602 } 604 grouping ipv4-sid { 605 description 606 "Grouping for an IPv4 prefix SID."; 607 leaf prefix { 608 type inet:ipv4-prefix; 609 description 610 "Connected IPv4 prefix sid."; 611 } 612 uses prefix-sid-attributes; 613 } 614 grouping ipv6-sid { 615 description 616 "Grouping for an IPv6 prefix SID."; 617 leaf prefix { 618 type inet:ipv6-prefix; 619 description 620 "Connected ipv6 prefix sid."; 622 } 623 uses prefix-sid-attributes; 624 } 626 grouping last-hop-behavior { 627 description 628 "Defines last hop behavior"; 629 leaf last-hop-behavior { 630 if-feature "sid-last-hop-behavior"; 631 type enumeration { 632 enum "explicit-null" { 633 description 634 "Use explicit-null for the SID."; 635 } 636 enum "no-php" { 637 description 638 "Do not use Penultimate Hop Popping (PHP) 639 for the SID."; 640 } 641 enum "php" { 642 description 643 "Use PHP for the SID."; 644 } 645 } 646 description 647 "Configure last hop behavior."; 648 } 649 } 651 grouping node-capabilities { 652 description 653 "Containing SR node capabilities."; 654 container node-capabilities { 655 config false; 656 description 657 "Shows the SR capability of the node."; 658 leaf entropy-readable-label-depth { 659 type uint8; 660 description 661 "Maximum label stack depth that a router can read."; 662 } 663 } 664 } 666 grouping prefix-sid-attributes { 667 description 668 "Grouping for Segment Routing (SR) prefix attributes."; 669 uses sid-value-type; 670 leaf start-sid { 671 type uint32; 672 mandatory true; 673 description 674 "Value associated with prefix. The value must be 675 interpreted in the context of value-type."; 676 } 677 leaf range { 678 type uint32; 679 description 680 "Indicates how many SIDs can be allocated."; 681 } 682 leaf algorithm { 683 type identityref { 684 base prefix-sid-algorithm; 685 } 686 description 687 "Prefix-sid algorithm."; 688 } 689 } 690 } 691 692 file "ietf-segment-routing-mpls@2020-01-09.yang" 693 module ietf-segment-routing-mpls { 694 yang-version 1.1; 695 namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls"; 696 prefix sr-mpls; 698 import ietf-inet-types { 699 prefix inet; 700 } 701 import ietf-routing { 702 prefix rt; 703 } 704 import ietf-interfaces { 705 prefix if; 706 } 707 import ietf-routing-types { 708 prefix rt-types; 709 } 710 import ietf-segment-routing { 711 prefix sr; 712 } 713 import ietf-segment-routing-common { 714 prefix sr-cmn; 715 } 717 organization 718 "IETF SPRING - SPRING Working Group"; 719 contact 720 "WG Web: 721 WG List: 723 Editor: Stephane Litkowski 724 725 Editor: Yingzhen Qu 726 728 Author: Acee Lindem 729 730 Author: Pushpasis Sarkar 731 732 Author: Jeff Tantsura 733 735 "; 736 description 737 "The YANG module defines a generic configuration model for 738 Segment Routing MPLS data plane. 740 Copyright (c) 2020 IETF Trust and the persons identified as 741 authors of the code. All rights reserved. 743 Redistribution and use in source and binary forms, with or 744 without modification, is permitted pursuant to, and subject 745 to the license terms contained in, the Simplified BSD License 746 set forth in Section 4.c of the IETF Trust's Legal Provisions 747 Relating to IETF Documents 748 (http://trustee.ietf.org/license-info). 750 This version of this YANG module is part of RFC XXXX; 751 see the RFC itself for full legal notices."; 753 reference "RFC XXXX"; 755 revision 2020-01-09 { 756 description 757 "Initial Version"; 758 reference "RFC XXXX: YANG Data Model for Segment Routing."; 759 } 761 feature mapping-server { 762 description 763 "Support for Segment Routing Mapping Server (SRMS)."; 764 } 765 feature protocol-srgb { 766 description 767 "Support for per-protocol Segment Routing Global Block 768 (SRGB) configuration."; 769 } 771 feature max-sid-depth { 772 description 773 "Support for signaling MSD (Maximum SID Depth) in IGP."; 774 } 776 typedef system-id { 777 type string { 778 pattern 779 '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}'; 780 } 781 description 782 "This type defines IS-IS system-id using pattern, 783 An example system-id is 0143.0438.AEF0"; 784 } 786 typedef router-id { 787 type union { 788 type system-id; 789 type rt-types:router-id; 790 } 791 description 792 "OSPF/BGP router-id or ISIS system ID."; 793 } 795 grouping sr-controlplane { 796 description 797 "Defines protocol configuration."; 798 container segment-routing { 799 description 800 "Segment Routing global configuration."; 801 leaf enabled { 802 type boolean; 803 default "false"; 804 description 805 "Enables segment-routing protocol extensions."; 806 } 807 container bindings { 808 description 809 "Control of binding advertisement and reception."; 810 container advertise { 811 description 812 "Control advertisement of local mappings 813 in binding TLVs."; 814 leaf-list policies { 815 type string; 816 description 817 "List of binding advertisement policies."; 818 } 819 } 820 leaf receive { 821 type boolean; 822 default "true"; 823 description 824 "Allow the reception and usage of binding TLVs."; 825 } 826 } 827 } 828 } 830 grouping igp-interface { 831 description 832 "Grouping for IGP interface configuration."; 833 container segment-routing { 834 description 835 "Container for SR interface configuration."; 836 container adjacency-sid { 837 description 838 "Adjacency SID configuration."; 839 list adj-sids { 840 key "value"; 841 uses sr-cmn:sid-value-type; 842 leaf value { 843 type uint32; 844 description 845 "Value of the Adj-SID."; 846 } 847 leaf protected { 848 type boolean; 849 default false; 850 description 851 "It is used to protect the mannual adj-SID."; 852 } 853 description 854 "List of adj-sid configuration."; 855 } 856 list advertise-adj-group-sid { 857 key "group-id"; 858 description 859 "Control advertisement of S flag. Enable advertisement 860 of a common Adj-SID for parallel links."; 862 leaf group-id { 863 type uint32; 864 description 865 "The value is an internal value to identify a 866 group-ID. Interfaces with the same group-ID will be 867 bundled together."; 868 } 869 } 870 leaf advertise-protection { 871 type enumeration { 872 enum "single" { 873 description 874 "A single Adj-SID is associated with the adjacency 875 and reflects the protection configuration."; 876 } 877 enum "dual" { 878 description 879 "Two Adj-SIDs will be associated with the adjacency 880 if the interface is protected. In this case, will 881 be advertised with backup flag set, the other will 882 be advertised with theo backup flag clear. In case 883 protection is not configured, single Adj-SID will 884 be advertised with the backup flag clear."; 885 } 886 } 887 description 888 "If set, the Adj-SID refers to a protected adjacency."; 889 } 890 } 891 } 892 } 894 grouping max-sid-depth { 895 description 896 "Maximum SID Depth (MSD)D configuration grouping."; 897 leaf node-msd { 898 type uint8; 899 description 900 "Node MSD is the lowest MSD supported by the node."; 901 } 902 container link-msd { 903 description 904 "MSD supported by an individual interface."; 905 list link-msds { 906 key "interface"; 907 description 908 "List of link MSDs."; 909 leaf interface { 910 type if:interface-ref; 911 description 912 "Reference to device interface."; 913 } 914 leaf msd { 915 type uint8; 916 description 917 "MSD supported by the interface."; 918 } 919 } 920 } 921 } 923 augment "/rt:routing/sr:segment-routing" { 924 description 925 "This augments routing data model (RFC 8349) 926 with Segment Routing (SR)."; 927 container sr-mpls { 928 description 929 "Segment Routing global configuration."; 930 uses sr-cmn:node-capabilities; 931 container msd { 932 if-feature "max-sid-depth"; 933 description 934 "MSD configuration."; 935 uses max-sid-depth; 936 } 937 container bindings { 938 description 939 "List of bindings."; 940 container mapping-server { 941 if-feature "mapping-server"; 942 description 943 "Configuration of mapping-server local entries."; 944 list policy { 945 key "name"; 946 description 947 "List mapping-server policies."; 948 leaf name { 949 type string; 950 description 951 "Name of the mapping policy."; 952 } 953 container entries { 954 description 955 "IPv4/IPv6 mapping entries."; 956 list mapping-entry { 957 key "prefix algorithm"; 958 description 959 "Mapping entries."; 960 uses sr-cmn:prefix-sid; 961 } 962 } 963 } 964 } 965 container connected-prefix-sid-map { 966 description 967 "Prefix SID configuration."; 968 list connected-prefix-sid { 969 key "prefix algorithm"; 970 description 971 "List of prefix SID mapped to IPv4/IPv6 972 local prefixes."; 973 uses sr-cmn:prefix-sid; 974 uses sr-cmn:last-hop-behavior; 975 } 976 } 977 container local-prefix-sid { 978 description 979 "Local sid configuration."; 980 list local-prefix-sid { 981 key "prefix algorithm"; 982 description 983 "List of local IPv4/IPv6 prefix-sids."; 984 uses sr-cmn:prefix-sid; 985 } 986 } 987 } 988 container global-srgb { 989 description 990 "Global SRGB configuration."; 991 uses sr-cmn:srgb; 992 } 993 container srlb { 994 description 995 "Segment Routing Local Block (SRLB) configuration."; 996 uses sr-cmn:srlb; 997 } 999 list label-blocks { 1000 config false; 1001 description 1002 "List of label blocks currently in use."; 1003 leaf lower-bound { 1004 type uint32; 1005 description 1006 "Lower bound of the label block."; 1007 } 1008 leaf upper-bound { 1009 type uint32; 1010 description 1011 "Upper bound of the label block."; 1012 } 1013 leaf size { 1014 type uint32; 1015 description 1016 "Number of indexes in the block."; 1017 } 1018 leaf free { 1019 type uint32; 1020 description 1021 "Number of free indexes in the block."; 1022 } 1023 leaf used { 1024 type uint32; 1025 description 1026 "Number of indexes in use in the block."; 1027 } 1028 leaf scope { 1029 type enumeration { 1030 enum "global" { 1031 description 1032 "Global SID."; 1033 } 1034 enum "local" { 1035 description 1036 "Local SID."; 1037 } 1038 } 1039 description 1040 "Scope of this label block."; 1041 } 1042 } 1043 container sid-db { 1044 config false; 1045 description 1046 "List of prefix and SID associations."; 1047 list sid { 1048 key "target sid source source-protocol binding-type"; 1049 ordered-by system; 1050 description 1051 "SID Binding."; 1052 leaf target { 1053 type string; 1054 description 1055 "Defines the target of the binding. It can be a 1056 prefix or something else."; 1057 } 1058 leaf sid { 1059 type uint32; 1060 description 1061 "Index associated with the prefix."; 1062 } 1063 leaf algorithm { 1064 type uint8; 1065 description 1066 "Algorithm to be used for the prefix SID."; 1067 } 1068 leaf source { 1069 type inet:ip-address; 1070 description 1071 "IP address of the router that owns the binding."; 1072 } 1073 leaf used { 1074 type boolean; 1075 description 1076 "Indicates if the binding is install in the 1077 forwarding plane."; 1078 } 1079 leaf source-protocol { 1080 type leafref { 1081 path "/rt:routing/rt:control-plane-protocols/" 1082 + "rt:control-plane-protocol/rt:name"; 1083 } 1084 description 1085 "Routing protocol that owns the binding"; 1086 } 1087 leaf binding-type { 1088 type enumeration { 1089 enum "prefix-sid" { 1090 description 1091 "Binding is learned from a prefix SID."; 1092 } 1093 enum "binding-tlv" { 1094 description 1095 "Binding is learned from a binding TLV."; 1096 } 1097 } 1098 description 1099 "Type of binding."; 1100 } 1101 leaf scope { 1102 type enumeration { 1103 enum "global" { 1104 description 1105 "Global SID."; 1106 } 1107 enum "local" { 1108 description 1109 "Local SID."; 1110 } 1111 } 1112 description 1113 "SID scoping."; 1114 } 1115 } 1116 } 1117 } 1118 } 1120 notification segment-routing-global-srgb-collision { 1121 description 1122 "This notification is sent when SRGB blocks received from 1123 routers conflict."; 1124 list srgb-collisions { 1125 description 1126 "List of SRGB blocks that conflict."; 1127 leaf lower-bound { 1128 type uint32; 1129 description 1130 "Lower value in the block."; 1131 } 1132 leaf upper-bound { 1133 type uint32; 1134 description 1135 "Upper value in the block."; 1136 } 1137 leaf routing-protocol { 1138 type leafref { 1139 path "/rt:routing/rt:control-plane-protocols/" 1140 + "rt:control-plane-protocol/rt:name"; 1141 } 1142 description 1143 "Routing protocol reference for SRGB collision."; 1144 } 1145 leaf originating-rtr-id { 1146 type router-id; 1147 description 1148 "Originating Router ID of this SRGB block."; 1149 } 1151 } 1152 } 1153 notification segment-routing-global-sid-collision { 1154 description 1155 "This notification is sent when a new mapping is learned 1156 containing s mapping where the SID is already used. 1157 The notification generation must be throttled with at least 1158 a 5 second gap between notifications."; 1159 leaf received-target { 1160 type string; 1161 description 1162 "Target received in the router advertisement that caused 1163 the SID collision."; 1164 } 1165 leaf new-sid-rtr-id { 1166 type router-id; 1167 description 1168 "Router ID that advertised the conflicting SID."; 1169 } 1170 leaf original-target { 1171 type string; 1172 description 1173 "Target already available in the database with the same SID 1174 as the received target."; 1175 } 1176 leaf original-sid-rtr-id { 1177 type router-id; 1178 description 1179 "Router-ID for the router that originally advertised the 1180 conflicting SID, i.e., the instance in the database."; 1181 } 1182 leaf index { 1183 type uint32; 1184 description 1185 "Value of the index used by two different prefixes."; 1186 } 1187 leaf routing-protocol { 1188 type leafref { 1189 path "/rt:routing/rt:control-plane-protocols/" 1190 + "rt:control-plane-protocol/rt:name"; 1191 } 1192 description 1193 "Routing protocol reference for conflicting SID."; 1194 } 1195 } 1196 notification segment-routing-index-out-of-range { 1197 description 1198 "This notification is sent when a binding is received 1199 containing a segment index which is out of the local 1200 configured ranges. The notification generation must be 1201 throttled with at least a 5 second gap between 1202 notifications."; 1203 leaf received-target { 1204 type string; 1205 description 1206 "Target received in the router advertisement with 1207 the out-of-range index."; 1208 } 1209 leaf received-index { 1210 type uint32; 1211 description 1212 "Value of the index received."; 1213 } 1214 leaf routing-protocol { 1215 type leafref { 1216 path "/rt:routing/rt:control-plane-protocols/" 1217 + "rt:control-plane-protocol/rt:name"; 1218 } 1219 description 1220 "Routing protocol reference for out-of-range indexd."; 1221 } 1222 } 1223 } 1224 1226 9. Security Considerations 1228 The YANG modules specified in this document define a schema for data 1229 that is designed to be accessed via network management protocols such 1230 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1231 is the secure transport layer, and the mandatory-to-implement secure 1232 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1233 is HTTPS, and the mandatory-to-implement secure transport is TLS 1234 [RFC5246]. 1236 The NETCONF access control model [RFC6536] provides the means to 1237 restrict access for particular NETCONF or RESTCONF users to a pre- 1238 configured subset of all available NETCONF or RESTCONF protocol 1239 operations and content. 1241 There are a number of data nodes defined in the modules that are 1242 writable/creatable/deletable (i.e., config true, which is the 1243 default). These data nodes may be considered sensitive or vulnerable 1244 in some network environments. Write operations (e.g., edit-config) 1245 to these data nodes without proper protection can have a negative 1246 effect on network operations. 1248 Some of the readable data nodes in the modules may be considered 1249 sensitive or vulnerable in some network environments. It is thus 1250 important to control read access (e.g., via get, get-config, or 1251 notification) to these data nodes. 1253 10. Acknowledgements 1255 Authors would like to thank Derek Yeung, Greg Hankins, Hannes 1256 Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge, Les Ginsberg for 1257 their contributions. 1259 11. IANA Considerations 1261 This document registers a URI in the IETF XML registry [RFC3688]. 1262 Following the format in [RFC3688], the following registration is 1263 requested to be made: 1265 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing-commmon 1266 Registrant Contact: The IESG. 1267 XML: N/A, the requested URI is an XML namespace. 1269 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing 1270 Registrant Contact: The IESG. 1271 XML: N/A, the requested URI is an XML namespace. 1273 This document registers a YANG module in the YANG Module Names 1274 registry [RFC6020]. 1276 name: ietf-segment-routing-common 1277 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common 1278 prefix: sr-cmn 1279 reference: RFC XXXX 1281 name: ietf-segment-routing 1282 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing 1283 prefix: sr 1284 reference: RFC XXXX 1286 12. References 1288 12.1. Normative References 1290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1291 Requirement Levels", BCP 14, RFC 2119, 1292 DOI 10.17487/RFC2119, March 1997, 1293 . 1295 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1296 DOI 10.17487/RFC3688, January 2004, 1297 . 1299 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1300 (TLS) Protocol Version 1.2", RFC 5246, 1301 DOI 10.17487/RFC5246, August 2008, 1302 . 1304 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1305 the Network Configuration Protocol (NETCONF)", RFC 6020, 1306 DOI 10.17487/RFC6020, October 2010, 1307 . 1309 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1310 and A. Bierman, Ed., "Network Configuration Protocol 1311 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1312 . 1314 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1315 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1316 . 1318 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1319 Protocol (NETCONF) Access Control Model", RFC 6536, 1320 DOI 10.17487/RFC6536, March 2012, 1321 . 1323 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1324 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1325 . 1327 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1328 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1329 . 1331 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1332 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1333 . 1335 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1336 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1337 May 2017, . 1339 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1340 "Common YANG Data Types for the Routing Area", RFC 8294, 1341 DOI 10.17487/RFC8294, December 2017, 1342 . 1344 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1345 and R. Wilton, "Network Management Datastore Architecture 1346 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1347 . 1349 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1350 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1351 . 1353 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1354 Routing Management (NMDA Version)", RFC 8349, 1355 DOI 10.17487/RFC8349, March 2018, 1356 . 1358 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1359 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1360 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1361 July 2018, . 1363 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1364 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1365 DOI 10.17487/RFC8476, December 2018, 1366 . 1368 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1369 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1370 DOI 10.17487/RFC8491, November 2018, 1371 . 1373 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1374 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1375 Routing with the MPLS Data Plane", RFC 8660, 1376 DOI 10.17487/RFC8660, December 2019, 1377 . 1379 12.2. Informative References 1381 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1382 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1383 . 1385 Authors' Addresses 1387 Stephane Litkowski 1388 Cisco Systems 1390 Email: slitkows.ietf@gmail.com 1391 Yingzhen Qu 1392 Futurewei 1394 Email: yingzhen.qu@futurewei.com 1396 Acee Lindem 1397 Cisco Systems 1398 301 Mindenhall Way 1399 Cary, NC 27513 1400 US 1402 Email: acee@cisco.com 1404 Pushpasis Sarkar 1405 Individual 1407 Email: pushpasis.ietf@gmail.com 1409 Jeff Tantsura 1410 Apstra 1412 Email: jefftant.ietf@gmail.com