idnits 2.17.1 draft-ietf-spring-sr-yang-13.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 (July 7, 2019) is 1754 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 Orange Business Service 4 Intended status: Standards Track Y. Qu 5 Expires: January 8, 2020 Futurewei 6 A. Lindem 7 Cisco 8 P. Sarkar 9 Individual 10 J. Tantsura 11 Apstra 12 July 7, 2019 14 YANG Data Model for Segment Routing 15 draft-ietf-spring-sr-yang-13 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 January 8, 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 . . . . . . . . . . . . . . . . . . . . . . . 28 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-07-06.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-07-06 { 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 description 486 "Upper value in the label range."; 487 } 488 } 490 grouping srgb { 491 description 492 "Grouping for SR Global Label range."; 493 list srgb { 494 key "lower-bound upper-bound"; 495 ordered-by user; 496 description 497 "List of global blocks to be advertised."; 498 uses srlr; 499 } 500 } 502 grouping srlb { 503 description 504 "Grouping for SR Local Block range."; 505 list srlb { 506 key "lower-bound upper-bound"; 507 ordered-by user; 508 description 509 "List of SRLBs."; 510 uses srlr; 511 } 512 } 514 grouping sid-value-type { 515 description 516 "Defines how the SID value is expressed."; 517 leaf value-type { 518 type enumeration { 519 enum "index" { 520 description 521 "The value will be interpreted as an index."; 522 } 523 enum "absolute" { 524 description 525 "The value will become interpreted as an absolute 526 value."; 527 } 528 } 529 default "index"; 530 description 531 "This leaf defines how value must be interpreted."; 532 } 533 } 535 grouping prefix-sid { 536 description 537 "This grouping defines cfg of prefix SID."; 538 leaf prefix { 539 type inet:ip-prefix; 540 description 541 "connected prefix sid."; 542 } 543 uses prefix-sid-attributes; 544 } 546 grouping ipv4-sid { 547 description 548 "Grouping for an IPv4 prefix SID."; 549 leaf prefix { 550 type inet:ipv4-prefix; 551 description 552 "Connected IPv4 prefix sid."; 553 } 554 uses prefix-sid-attributes; 555 } 556 grouping ipv6-sid { 557 description 558 "Grouping for an IPv6 prefix SID."; 559 leaf prefix { 560 type inet:ipv6-prefix; 561 description 562 "Connected ipv6 prefix sid."; 563 } 564 uses prefix-sid-attributes; 565 } 567 grouping last-hop-behavior { 568 description 569 "Defines last hop behavior"; 570 leaf last-hop-behavior { 571 if-feature "sid-last-hop-behavior"; 572 type enumeration { 573 enum "explicit-null" { 574 description 575 "Use explicit-null for the SID."; 576 } 577 enum "no-php" { 578 description 579 "Do not use Penultimate Hop Popping (PHP) 580 for the SID."; 581 } 582 enum "php" { 583 description 584 "Use PHP for the SID."; 585 } 586 } 587 description 588 "Configure last hop behavior."; 589 } 590 } 592 grouping node-capabilities { 593 description 594 "Containing SR node capabilities."; 595 container node-capabilities { 596 config false; 597 description 598 "Shows the SR capability of the node."; 599 list transport-planes { 600 key "transport-plane"; 601 description 602 "List of supported transport planes."; 603 leaf transport-plane { 604 type identityref { 605 base segment-routing-transport; 606 } 607 description 608 "Transport plane supported"; 609 } 610 } 611 leaf entropy-readable-label-depth { 612 type uint8; 613 description 614 "Maximum label stack depth that a router can read."; 615 } 616 } 617 } 618 grouping prefix-sid-attributes { 619 description 620 "Grouping for Segment Routing (SR) prefix attributes."; 621 uses sid-value-type; 622 leaf start-sid { 623 type uint32; 624 mandatory true; 625 description 626 "Value associated with prefix. The value must be 627 interpreted in the context of value-type."; 628 } 629 leaf range { 630 type uint32; 631 description 632 "Indicates how many SIDs can be allocated."; 633 } 634 leaf algorithm { 635 type identityref { 636 base prefix-sid-algorithm; 637 } 638 description 639 "Prefix-sid algorithm."; 640 } 641 } 642 } 643 644 file "ietf-segment-routing@2019-07-06.yang" 645 module ietf-segment-routing { 646 yang-version 1.1; 647 namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing"; 648 prefix sr; 650 import ietf-inet-types { 651 prefix inet; 652 } 653 import ietf-routing { 654 prefix rt; 655 } 656 import ietf-interfaces { 657 prefix if; 658 } 659 import ietf-routing-types { 660 prefix rt-types; 661 } 662 import ietf-segment-routing-common { 663 prefix sr-cmn; 664 } 665 organization 666 "IETF SPRING - SPRING Working Group"; 667 contact 668 "WG Web: 669 WG List: 671 Editor: Stephane Litkowski 672 673 Editor: Yingzhen Qu 674 676 Author: Acee Lindem 677 678 Author: Pushpasis Sarkar 679 680 Author: Jeff Tantsura 681 683 "; 684 description 685 "The YANG module defines a generic configuration model for 686 Segment routing common across all of the vendor 687 implementations. 689 Copyright (c) 2019 IETF Trust and the persons identified as 690 authors of the code. All rights reserved. 692 Redistribution and use in source and binary forms, with or 693 without modification, is permitted pursuant to, and subject 694 to the license terms contained in, the Simplified BSD License 695 set forth in Section 4.c of the IETF Trust's Legal Provisions 696 Relating to IETF Documents 697 (http://trustee.ietf.org/license-info). 699 This version of this YANG module is part of RFC XXXX; 700 see the RFC itself for full legal notices."; 702 reference "RFC XXXX"; 704 revision 2019-07-06 { 705 description 706 "Initial Version"; 707 reference "RFC XXXX: YANG Data Model for Segment Routing."; 708 } 709 feature mapping-server { 710 description 711 "Support for Segment Routing Mapping Server (SRMS)."; 712 } 713 feature protocol-srgb { 714 description 715 "Support for per-protocol Segment Routing Global Block 716 (SRGB) configuration."; 717 } 719 feature max-sid-depth { 720 description 721 "Support for signaling MSD (Maximum SID Depth) in IGP."; 722 } 724 typedef system-id { 725 type string { 726 pattern 727 '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}'; 728 } 729 description 730 "This type defines IS-IS system-id using pattern, 731 An example system-id is 0143.0438.AEF0"; 732 } 734 typedef router-id { 735 type union { 736 type system-id; 737 type rt-types:router-id; 738 } 739 description 740 "OSPF/BGP router-id or ISIS system ID."; 741 } 743 grouping sr-controlplane { 744 description 745 "Defines protocol configuration."; 746 container segment-routing { 747 description 748 "Segment Routing global configuration."; 749 leaf enabled { 750 type boolean; 751 default "false"; 752 description 753 "Enables segment-routing protocol extensions."; 754 } 755 container bindings { 756 description 757 "Control of binding advertisement and reception."; 758 container advertise { 759 description 760 "Control advertisement of local mappings 761 in binding TLVs."; 762 leaf-list policies { 763 type string; 764 description 765 "List of binding advertisement policies."; 766 } 767 } 768 leaf receive { 769 type boolean; 770 default "true"; 771 description 772 "Allow the reception and usage of binding TLVs."; 773 } 774 } 775 } 776 } 778 grouping igp-interface { 779 description 780 "Grouping for IGP interface configuration."; 781 container segment-routing { 782 description 783 "Container for SR interface configuration."; 784 container adjacency-sid { 785 description 786 "Adjacency SID configuration."; 787 list adj-sids { 788 key "value"; 789 uses sr-cmn:sid-value-type; 790 leaf value { 791 type uint32; 792 description 793 "Value of the Adj-SID."; 794 } 795 leaf protected { 796 type boolean; 797 default false; 798 description 799 "It is used to protect the mannual adj-SID."; 800 } 801 description 802 "List of adj-sid configuration."; 803 } 804 list advertise-adj-group-sid { 805 key "group-id"; 806 description 807 "Control advertisement of S flag. Enable advertisement 808 of a common Adj-SID for parallel links."; 810 leaf group-id { 811 type uint32; 812 description 813 "The value is an internal value to identify a 814 group-ID. Interfaces with the same group-ID will be 815 bundled together."; 816 } 817 } 818 leaf advertise-protection { 819 type enumeration { 820 enum "single" { 821 description 822 "A single Adj-SID is associated with the adjacency 823 and reflects the protection configuration."; 824 } 825 enum "dual" { 826 description 827 "Two Adj-SIDs will be associated with the adjacency 828 if the interface is protected. In this case, will 829 be advertised with backup flag set, the other will 830 be advertised with theo backup flag clear. In case 831 protection is not configured, single Adj-SID will 832 be advertised with the backup flag clear."; 833 } 834 } 835 description 836 "If set, the Adj-SID refers to a protected adjacency."; 837 } 838 } 839 } 840 } 842 grouping max-sid-depth { 843 description 844 "Maximum SID Depth (MSD)D configuration grouping."; 845 leaf node-msd { 846 type uint8; 847 description 848 "Node MSD is the lowest MSD supported by the node."; 849 } 850 container link-msd { 851 description 852 "MSD supported by an individual interface."; 853 list link-msds { 854 key "interface"; 855 description 856 "List of link MSDs."; 857 leaf interface { 858 type if:interface-ref; 859 description 860 "Reference to device interface."; 861 } 862 leaf msd { 863 type uint8; 864 description 865 "MSD supported by the interface."; 866 } 867 } 868 } 869 } 871 augment "/rt:routing" { 872 description 873 "This augments routing data model (RFC 8349) 874 with Segment Routing (SR)."; 875 container segment-routing { 876 description 877 "Segment Routing global configuration."; 878 leaf transport-type { 879 type identityref { 880 base sr-cmn:segment-routing-transport; 881 } 882 default "sr-cmn:segment-routing-transport-mpls"; 883 description 884 "Dataplane to be used."; 885 } 886 uses sr-cmn:node-capabilities; 887 container msd { 888 if-feature "max-sid-depth"; 889 description 890 "MSD configuration."; 891 uses max-sid-depth; 892 } 893 container bindings { 894 description 895 "List of bindings."; 896 container mapping-server { 897 if-feature "mapping-server"; 898 description 899 "Configuration of mapping-server local entries."; 900 list policy { 901 key "name"; 902 description 903 "List mapping-server policies."; 904 leaf name { 905 type string; 906 description 907 "Name of the mapping policy."; 908 } 909 container entries { 910 description 911 "IPv4/IPv6 mapping entries."; 912 list mapping-entry { 913 key "prefix algorithm"; 914 description 915 "Mapping entries."; 916 uses sr-cmn:prefix-sid; 917 } 918 } 919 } 920 } 921 container connected-prefix-sid-map { 922 description 923 "Prefix SID configuration."; 924 list connected-prefix-sid { 925 key "prefix algorithm"; 926 description 927 "List of prefix SID mapped to IPv4/IPv6 928 local prefixes."; 929 uses sr-cmn:prefix-sid; 930 uses sr-cmn:last-hop-behavior; 931 } 932 } 933 container local-prefix-sid { 934 description 935 "Local sid configuration."; 936 list local-prefix-sid { 937 key "prefix algorithm"; 938 description 939 "List of local IPv4/IPv6 prefix-sids."; 940 uses sr-cmn:prefix-sid; 941 } 942 } 943 } 944 container global-srgb { 945 description 946 "Global SRGB configuration."; 947 uses sr-cmn:srgb; 948 } 949 container srlb { 950 description 951 "Segment Routing Local Block (SRLB) configuration."; 952 uses sr-cmn:srlb; 953 } 954 list label-blocks { 955 config false; 956 description 957 "List of label blocks currently in use."; 958 leaf lower-bound { 959 type uint32; 960 description 961 "Lower bound of the label block."; 962 } 963 leaf upper-bound { 964 type uint32; 965 description 966 "Upper bound of the label block."; 967 } 968 leaf size { 969 type uint32; 970 description 971 "Number of indexes in the block."; 972 } 973 leaf free { 974 type uint32; 975 description 976 "Number of free indexes in the block."; 977 } 978 leaf used { 979 type uint32; 980 description 981 "Number of indexes in use in the block."; 982 } 983 leaf scope { 984 type enumeration { 985 enum "global" { 986 description 987 "Global SID."; 988 } 989 enum "local" { 990 description 991 "Local SID."; 992 } 993 } 994 description 995 "Scope of this label block."; 996 } 997 } 998 container sid-list { 999 config false; 1000 description 1001 "List of prefix and SID associations."; 1003 list sid { 1004 key "target sid source source-protocol binding-type"; 1005 ordered-by system; 1006 description 1007 "SID Binding."; 1008 leaf target { 1009 type string; 1010 description 1011 "Defines the target of the binding. It can be a 1012 prefix or something else."; 1013 } 1014 leaf sid { 1015 type uint32; 1016 description 1017 "Index associated with the prefix."; 1018 } 1019 leaf algorithm { 1020 type uint8; 1021 description 1022 "Algorithm to be used for the prefix SID."; 1023 } 1024 leaf source { 1025 type inet:ip-address; 1026 description 1027 "IP address of the router that owns the binding."; 1028 } 1029 leaf used { 1030 type boolean; 1031 description 1032 "Indicates if the binding is install in the 1033 forwarding plane."; 1034 } 1035 leaf source-protocol { 1036 type leafref { 1037 path "/rt:routing/rt:control-plane-protocols/" 1038 + "rt:control-plane-protocol/rt:name"; 1039 } 1040 description 1041 "Routing protocol that owns the binding"; 1042 } 1043 leaf binding-type { 1044 type enumeration { 1045 enum "prefix-sid" { 1046 description 1047 "Binding is learned from a prefix SID."; 1048 } 1049 enum "binding-tlv" { 1050 description 1051 "Binding is learned from a binding TLV."; 1052 } 1053 } 1054 description 1055 "Type of binding."; 1056 } 1057 leaf scope { 1058 type enumeration { 1059 enum "global" { 1060 description 1061 "Global SID."; 1062 } 1063 enum "local" { 1064 description 1065 "Local SID."; 1066 } 1067 } 1068 description 1069 "SID scoping."; 1070 } 1071 } 1072 } 1073 } 1074 } 1076 notification segment-routing-global-srgb-collision { 1077 description 1078 "This notification is sent when SRGB blocks received from 1079 routers conflict."; 1080 list srgb-collisions { 1081 description 1082 "List of SRGB blocks that conflict."; 1083 leaf lower-bound { 1084 type uint32; 1085 description 1086 "Lower value in the block."; 1087 } 1088 leaf upper-bound { 1089 type uint32; 1090 description 1091 "Upper value in the block."; 1092 } 1093 leaf routing-protocol { 1094 type leafref { 1095 path "/rt:routing/rt:control-plane-protocols/" 1096 + "rt:control-plane-protocol/rt:name"; 1097 } 1098 description 1099 "Routing protocol reference for SRGB collision."; 1100 } 1101 leaf originating-rtr-id { 1102 type router-id; 1103 description 1104 "Originating Router ID of this SRGB block."; 1105 } 1106 } 1107 } 1108 notification segment-routing-global-sid-collision { 1109 description 1110 "This notification is sent when a new mapping is learned 1111 containing s mapping where the SID is already used. 1112 The notification generation must be throttled with at least 1113 a 5 second gap between notifications."; 1114 leaf received-target { 1115 type string; 1116 description 1117 "Target received in the router advertisement that caused 1118 the SID collision."; 1119 } 1120 leaf new-sid-rtr-id { 1121 type router-id; 1122 description 1123 "Router ID that advertised the conflicting SID."; 1124 } 1125 leaf original-target { 1126 type string; 1127 description 1128 "Target already available in the database with the same SID 1129 as the received target."; 1130 } 1131 leaf original-sid-rtr-id { 1132 type router-id; 1133 description 1134 "Router-ID for the router that originally advertised the 1135 conflicting SID, i.e., the instance in the database."; 1136 } 1137 leaf index { 1138 type uint32; 1139 description 1140 "Value of the index used by two different prefixes."; 1141 } 1142 leaf routing-protocol { 1143 type leafref { 1144 path "/rt:routing/rt:control-plane-protocols/" 1145 + "rt:control-plane-protocol/rt:name"; 1146 } 1147 description 1148 "Routing protocol reference for conflicting SID."; 1149 } 1150 } 1151 notification segment-routing-index-out-of-range { 1152 description 1153 "This notification is sent when a binding is received 1154 containing a segment index which is out of the local 1155 configured ranges. The notification generation must be 1156 throttled with at least a 5 second gap between 1157 notifications."; 1158 leaf received-target { 1159 type string; 1160 description 1161 "Target received in the router advertisement with 1162 the out-of-range index."; 1163 } 1164 leaf received-index { 1165 type uint32; 1166 description 1167 "Value of the index received."; 1168 } 1169 leaf routing-protocol { 1170 type leafref { 1171 path "/rt:routing/rt:control-plane-protocols/" 1172 + "rt:control-plane-protocol/rt:name"; 1173 } 1174 description 1175 "Routing protocol reference for out-of-range indexd."; 1176 } 1177 } 1178 } 1179 1181 9. Security Considerations 1183 The YANG modules specified in this document define a schema for data 1184 that is designed to be accessed via network management protocols such 1185 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1186 is the secure transport layer, and the mandatory-to-implement secure 1187 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1188 is HTTPS, and the mandatory-to-implement secure transport is TLS 1189 [RFC5246]. 1191 The NETCONF access control model [RFC6536] provides the means to 1192 restrict access for particular NETCONF or RESTCONF users to a pre- 1193 configured subset of all available NETCONF or RESTCONF protocol 1194 operations and content. 1196 There are a number of data nodes defined in the modules that are 1197 writable/creatable/deletable (i.e., config true, which is the 1198 default). These data nodes may be considered sensitive or vulnerable 1199 in some network environments. Write operations (e.g., edit-config) 1200 to these data nodes without proper protection can have a negative 1201 effect on network operations. 1203 Some of the readable data nodes in the modules may be considered 1204 sensitive or vulnerable in some network environments. It is thus 1205 important to control read access (e.g., via get, get-config, or 1206 notification) to these data nodes. 1208 10. Acknowledgements 1210 Authors would like to thank Derek Yeung, Greg Hankins, Hannes 1211 Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge, Les Ginsberg for 1212 their contributions. 1214 11. IANA Considerations 1216 This document registers a URI in the IETF XML registry [RFC3688]. 1217 Following the format in [RFC3688], the following registration is 1218 requested to be made: 1220 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing-commmon 1221 Registrant Contact: The IESG. 1222 XML: N/A, the requested URI is an XML namespace. 1224 URI: urn:ietf:params:xml:ns:yang:ietf-segment-routing 1225 Registrant Contact: The IESG. 1226 XML: N/A, the requested URI is an XML namespace. 1228 This document registers a YANG module in the YANG Module Names 1229 registry [RFC6020]. 1231 name: ietf-segment-routing-common 1232 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common 1233 prefix: sr-cmn 1234 reference: RFC XXXX 1236 name: ietf-segment-routing 1237 namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing 1238 prefix: sr 1239 reference: RFC XXXX 1241 12. References 1243 12.1. Normative References 1245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1246 Requirement Levels", BCP 14, RFC 2119, 1247 DOI 10.17487/RFC2119, March 1997, 1248 . 1250 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1251 DOI 10.17487/RFC3688, January 2004, 1252 . 1254 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1255 (TLS) Protocol Version 1.2", RFC 5246, 1256 DOI 10.17487/RFC5246, August 2008, 1257 . 1259 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1260 the Network Configuration Protocol (NETCONF)", RFC 6020, 1261 DOI 10.17487/RFC6020, October 2010, 1262 . 1264 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1265 and A. Bierman, Ed., "Network Configuration Protocol 1266 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1267 . 1269 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1270 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1271 . 1273 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1274 Protocol (NETCONF) Access Control Model", RFC 6536, 1275 DOI 10.17487/RFC6536, March 2012, 1276 . 1278 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1279 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1280 . 1282 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1283 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1284 . 1286 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1287 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1288 . 1290 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1291 "Common YANG Data Types for the Routing Area", RFC 8294, 1292 DOI 10.17487/RFC8294, December 2017, 1293 . 1295 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1296 and R. Wilton, "Network Management Datastore Architecture 1297 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1298 . 1300 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1301 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1302 . 1304 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1305 Routing Management (NMDA Version)", RFC 8349, 1306 DOI 10.17487/RFC8349, March 2018, 1307 . 1309 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1310 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1311 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1312 July 2018, . 1314 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 1315 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 1316 DOI 10.17487/RFC8476, December 2018, 1317 . 1319 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1320 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1321 DOI 10.17487/RFC8491, November 2018, 1322 . 1324 12.2. Informative References 1326 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1327 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1328 . 1330 Authors' Addresses 1332 Stephane Litkowski 1333 Orange Business Service 1335 Email: stephane.litkowski@orange.com 1336 Yingzhen Qu 1337 Futurewei 1339 Email: yingzhen.qu@futurewei.com 1341 Acee Lindem 1342 Cisco 1343 301 Mindenhall Way 1344 Cary, NC 27513 1345 US 1347 Email: acee@cisco.com 1349 Pushpasis Sarkar 1350 Individual 1352 Email: pushpasis.ietf@gmail.com 1354 Jeff Tantsura 1355 Apstra 1357 Email: jefftant.ietf@gmail.com