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