idnits 2.17.1 draft-ietf-spring-sr-yang-05.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 are 7 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([RFC7950], [I-D.ietf-spring-segment-routing], [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 128 has weird spacing: '...terface if:...' == Line 133 has weird spacing: '...rw name str...' == Line 167 has weird spacing: '...r-bound uin...' == Line 168 has weird spacing: '...r-bound uin...' == Line 173 has weird spacing: '...t-plane ide...' == (1 more instance...) -- The document date (October 28, 2016) is 2709 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) == Unused Reference: 'I-D.tantsura-isis-segment-routing-msd' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'I-D.tantsura-ospf-segment-routing-msd' is defined on line 1224, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 Summary: 2 errors (**), 0 flaws (~~), 10 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: May 1, 2017 Cisco Systems 6 P. Sarkar 7 J. Tantsura 8 Individual 9 October 28, 2016 11 YANG Data Model for Segment Routing 12 draft-ietf-spring-sr-yang-05 14 Abstract 16 This document defines a YANG data model ([RFC6020], [RFC7950]) for 17 segment routing ([I-D.ietf-spring-segment-routing]) configuration and 18 operation. This YANG model is intended to be used on network 19 elements to configure or operate segment routing. This document 20 defines also generic containers that SHOULD be reused by IGP protocol 21 modules to support segment routing. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 1, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 66 3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. IGP Control plane configuration . . . . . . . . . . . . . . . 6 68 4.1. IGP interface configuration . . . . . . . . . . . . . . . 7 69 4.1.1. Adjacency SID properties . . . . . . . . . . . . . . 7 70 4.1.1.1. Bundling . . . . . . . . . . . . . . . . . . . . 7 71 4.1.1.2. Protection . . . . . . . . . . . . . . . . . . . 7 72 5. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 78 11. Normative References . . . . . . . . . . . . . . . . . . . . 26 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 81 1. Introduction 83 This document defines a YANG data model for segment routing 84 configuration and operation. This document does not define the IGP 85 extensions to support segment routing but defines generic groupings 86 that SHOULD be reused by IGP extension modules. The reason of this 87 design choice is to not require implementations to support all IGP 88 extensions. For example, an implementation may support IS-IS 89 extension but not OSPF. 91 1.1. Tree diagram 93 A simplified graphical representation of the data model is presented 94 in Section 2. 96 The meaning of the symbols in these diagrams is as follows: 98 o Brackets "[" and "]" enclose list keys. 100 o Curly braces "{" and "}" contain names of optional features that 101 make the corresponding node conditional. 103 o Abbreviations before data node names: "rw" means configuration 104 (read-write), and "ro" state data (read-only). 106 o Symbols after data node names: "?" means an optional node and "*" 107 denotes a "list" or "leaf-list". 109 o Parentheses enclose choice and case nodes, and case nodes are also 110 marked with a colon (":"). 112 o Ellipsis ("...") stands for contents of subtrees that are not 113 shown. 115 2. Design of the Data Model 117 As the module definition is just starting, it is expected that there 118 will be changes as the module matures. 120 module: ietf-segment-routing 121 augment /rt:routing: 122 +--rw segment-routing 123 +--rw transport-type? identityref 124 +--rw msd {msd}? 125 | +--rw node-msd? uint8 126 | +--rw link-msd 127 | +--rw link-msds* [interface] 128 | +--rw interface if:interface-ref 129 | +--rw msd? uint8 130 +--rw bindings 131 | +--rw mapping-server {mapping-server}? 132 | | +--rw policy* [name] 133 | | +--rw name string 134 | | +--rw ipv4 135 | | | +--rw mapping-entry* [prefix algorithm] 136 | | | +--rw prefix inet:ipv4-prefix 137 | | | +--rw value-type? enumeration 138 | | | +--rw start-sid uint32 139 | | | +--rw range? uint32 140 | | | +--rw algorithm identityref 141 | | +--rw ipv6 142 | | +--rw mapping-entry* [prefix algorithm] 143 | | +--rw prefix inet:ipv6-prefix 144 | | +--rw value-type? enumeration 145 | | +--rw start-sid uint32 146 | | +--rw range? uint32 147 | | +--rw algorithm identityref 148 | +--rw connected-prefix-sid-map 149 | +--rw ipv4 150 | | +--rw ipv4-prefix-sid* [prefix algorithm] 151 | | +--rw prefix inet:ipv4-prefix 152 | | +--rw value-type? enumeration 153 | | +--rw start-sid uint32 154 | | +--rw range? uint32 155 | | +--rw algorithm identityref 156 | | +--rw last-hop-behavior? enumeration {sid-last-hop-behavior}? 157 | +--rw ipv6 158 | +--rw ipv6-prefix-sid* [prefix algorithm] 159 | +--rw prefix inet:ipv6-prefix 160 | +--rw value-type? enumeration 161 | +--rw start-sid uint32 162 | +--rw range? uint32 163 | +--rw algorithm identityref 164 | +--rw last-hop-behavior? enumeration {sid-last-hop-behavior}? 165 +--rw global-srgb 166 +--rw srgb* [lower-bound upper-bound] 167 +--rw lower-bound uint32 168 +--rw upper-bound uint32 169 augment /rt:routing-state: 170 +--ro segment-routing 171 +--ro node-capabilities 172 | +--ro transport-planes* [transport-plane] 173 | | +--ro transport-plane identityref 174 | +--ro readable-label-stack-depth? uint8 175 +--ro msd 176 | +--ro node-msd? uint8 177 | +--ro link-msd 178 | +--ro link-msds* [interface] 179 | +--ro interface if:interface-ref 180 | +--ro msd? uint8 181 +--ro label-blocks* 182 | +--ro lower-bound? uint32 183 | +--ro upper-bound? uint32 184 | +--ro size? uint32 185 | +--ro free? uint32 186 | +--ro used? uint32 187 +--ro global-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-state/control-plane-protocols 195 /control-plane-protocol/name 196 +--ro binding-type enumeration 197 notifications: 198 +---n segment-routing-global-srgb-collision 199 | +--ro srgb-collisions* 200 | +--ro lower-bound? uint32 201 | +--ro upper-bound? uint32 202 | +--ro routing-protocol? -> /rt:routing-state/control-plane-protocols 203 | /control-plane-protocol/name 204 | +--ro originating-rtr-id? router-id 205 +---n segment-routing-global-sid-collision 206 | +--ro received-target? string 207 | +--ro new-sid-rtr-id? router-id 208 | +--ro original-target? string 209 | +--ro original-sid-rtr-id? router-id 210 | +--ro index? uint32 211 | +--ro routing-protocol? -> /rt:routing-state/control-plane-protocols 212 | /control-plane-protocol/name 213 +---n segment-routing-index-out-of-range 214 +--ro received-target? string 215 +--ro received-index? uint32 216 +--ro routing-protocol? -> /rt:routing-state/control-plane-protocols 217 /control-plane-protocol/name 219 3. Configuration 221 This module augments the "/rt:routing:" with a segment-routing 222 container. This container defines all the configuration parameters 223 related to segment-routing. 225 The segment-routing configuration is split in global configuration 226 and interface configuration. 228 The global configuration includes : 230 o segment-routing transport type : The underlying transport type for 231 segment routing. The version of the model limits the transport 232 type to an MPLS dataplane. The transport-type is only defined 233 once for a particular routing-instance and is agnostic to the 234 control plane used. Only a single transport-type is supported in 235 this version of the model. 237 o bindings : Defines prefix to SID mappings. The operator can 238 control advertisement of Prefix-SID independently for IPv4 and 239 IPv6. Two types of mappings are available : 241 * Mapping-server : maps non local prefixes to a segment ID. 242 Configuration of bindings does not automatically allow 243 advertisement of those bindings. Advertisement must be 244 controlled by each routing-protocol instance (see Section 4). 245 Multiple mapping policies may be defined. 247 * Connected prefixes : maps connected prefixes to a segment ID. 248 Advertisement of the mapping will be done by IGP when enabled 249 for segment routing (see Section 4). The SID value can be 250 expressed as an index (default), or an absolute value. The 251 "last-hop-behavior" configuration dictates the PHP behavior: 252 "explicit-null", "php", or "non-php". 254 o SRGB (Segment Routing Global Block): Defines a list of label 255 blocks represented by a pair of lower-bound/upper-bound labels. 256 The SRGB is also agnostic to the control plane used. So all 257 routing-protocol instance will have to advertise the same SRGB. 259 4. IGP Control plane configuration 261 Support of segment-routing extensions for a particular IGP control 262 plane is done by augmenting routing-protocol configuration with 263 segment-routing extensions. This augmentation SHOULD be part of 264 separate YANG modules in order to not create any dependency for 265 implementations to support all protocol extensions. 267 This module defines groupings that SHOULD be used by IGP segment 268 routing modules. 270 The "controlplane-cfg" grouping defines the generic global 271 configuration for the IGP. 273 The "enabled" leaf enables segment-routing extensions for the 274 routing-protocol instance. 276 The "bindings" container controls the routing-protocol instance's 277 advertisement of local bindings and the processing of received 278 bindings. 280 4.1. IGP interface configuration 282 The interface configuration is part of the "igp-interface-cfg" 283 grouping and includes Adjacency SID properties. 285 4.1.1. Adjacency SID properties 287 4.1.1.1. Bundling 289 This section is a first proposal on how to use S-bit in Adj-SID to 290 create bundles. Authors would like to trigger discussion based on 291 this first proposal. 293 In case of parallel IP links between routers, an additional Adjacency 294 SID may be advertised representing more than one adjacency (i.e., a 295 bundle of adjacencies). The "advertise-adj-group-sid" configuration 296 controls whether or not an additional adjacency SID is advertised. 298 The "advertise-adj-group-sid" would be a list of "group-id". The 299 "group-id" will permit to identify interfaces that must be bundled 300 together. 302 +-------+ +------+ 303 | | ------- L1 ---- | | 304 | R1 | ------- L2 ---- | R2 | 305 | | ------- L3 ---- | | 306 | | ------- L4 ---- | | 307 +-------+ +------+ 309 In the figure above, R1 and R2 are interconnected by four links. A 310 routing protocol adjacency is established on each link. Operator 311 would like to create segment-routing Adj-SID that represent some 312 bundles of links. We can imagine two different bundles : L1/L2 and 313 L2/L3. To achieve this behavior, the service provider will configure 314 a "group-id" X for both interfaces L1 and L2 and a "group-id" Y for 315 both interfaces L3 and L3. This will result in R1 advertising an 316 additional Adj-SID for each adjacency, for example a Adj-SID with S 317 flag set and value of 400 will be added to L1 and L2. A Adj-SID with 318 S flag set and value of 500 will be added to L3 and L4. As L1/L2 and 319 L3/L4 does not share the same "group-id", a different SID value will 320 be allocated. 322 4.1.1.2. Protection 324 The "advertise-protection" defines how protection for an interface is 325 advertised. It does not control the activation or deactivation of 326 protection. If the "single" option is used, a single Adj-SID will be 327 advertised for the interface. If the interface is protected, the 328 B-Flag for the Adj-SID advertisement will be set. If the "dual" 329 option is used and if the interface is protected, two Adj-SIDs will 330 be advertised for the interface adjacencies. One Adj-SID will always 331 have the B-Flag set and the other will have the B-Flag clear. This 332 option is intended to be used in the case of traffic engineering 333 where a path must use either protected segments or non-protected 334 segments. 336 5. States 338 The operational states contains information reflecting the usage of 339 allocated SRGB labels. 341 It also includes a list of all global SIDs, their associated 342 bindings, and other information such as the source protocol and 343 algorithm. 345 6. Notifications 347 The model defines the following notifications for segment-routing. 349 o segment-routing-global-srgb-collision: Rasied when a control plan 350 advertised SRGB blocks have conflicts. 352 o segment-routing-global-sid-collision: Raised when a control plane 353 advertised index is already associated with another target (in 354 this version, the only defined targets are IPv4 and IPv6 355 prefixes). 357 o segment-routing-index-out-of-range: Raised when a control plane 358 advertised index fall outside the range of SRGBs configured for 359 the network device. 361 7. YANG Module 363 file "ietf-segment-routing-common@2016-10-28.yang" 364 module ietf-segment-routing-common { 365 namespace "urn:ietf:params:xml:ns:" 366 + "yang:ietf-segment-routing-common"; 367 prefix sr-cmn; 369 import ietf-inet-types { 370 prefix "inet"; 371 } 373 organization 374 "IETF SPRING Working Group"; 376 contact 377 "WG List: 379 Editor: Stephane Litkowski 380 382 Author: Acee Lindem 383 384 Author: Yingzhen Qu 385 386 Author: Pushpasis Sarkar 387 388 Author: Jeff Tantsura 389 391 "; 393 description 394 "The YANG module defines a collection of types and groupings for 395 Segment routing."; 397 revision 2016-10-28 { 398 description " 399 * Add support of MSD (Maximum SID Depth) 400 * Update contact info 401 "; 402 reference 403 "RFC XXXX: YANG Data Model for Segment Routing."; 404 } 406 revision 2016-10-24 { 407 description "Initial"; 408 reference 409 "RFC XXXX: YANG Data Model for Segment Routing."; 410 } 412 /* Identities */ 413 identity segment-routing-transport { 414 description 415 "Base identity for segment routing transport."; 416 } 417 identity segment-routing-transport-mpls { 418 base segment-routing-transport; 419 description 420 "This identity represents MPLS transport for segment 421 routing."; 422 } 423 identity prefix-sid-algorithm { 424 description 425 "Base identity for prefix-sid algorithm."; 426 } 428 identity prefix-sid-algorithm-shortest-path { 429 base prefix-sid-algorithm; 430 description 431 "The default behavior of prefix-sid algorithm."; 432 } 434 identity prefix-sid-algorithm-strict-spf { 435 base prefix-sid-algorithm; 436 description 437 "This algorithm mandates that the packet is forwared 438 according to ECMP-aware SPF algorithm."; 439 } 441 /* Features */ 443 feature sid-last-hop-behavior { 444 description 445 "Configurable last hop behavior."; 446 } 448 /* Groupings */ 450 grouping srgb-cfg { 451 list srgb { 452 key "lower-bound upper-bound"; 453 ordered-by user; 454 leaf lower-bound { 455 type uint32; 456 description 457 "Lower value in the block."; 458 } 459 leaf upper-bound { 460 type uint32; 461 description 462 "Upper value in the block."; 463 } 464 description 465 "List of global blocks to be 466 advertised."; 467 } 468 description 469 "Grouping for SRGB configuration."; 470 } 471 grouping sid-value-type { 472 leaf value-type { 473 type enumeration { 474 enum index { 475 description 476 "The value will be 477 interpreted as an index."; 478 } 479 enum absolute { 480 description 481 "The value will become 482 interpreted as an absolute 483 value."; 484 } 485 } 486 default index; 487 description 488 "This leaf defines how value 489 must be interpreted."; 490 } 491 description 492 "Defines how the SID value is expressed."; 493 } 495 grouping ipv4-sid-cfg { 497 leaf prefix { 498 type inet:ipv4-prefix; 499 description 500 "connected prefix sid."; 501 } 503 uses prefix-sid-attributes; 505 description 506 "This grouping defines cfg of prefix SID."; 507 } 509 grouping ipv6-sid-cfg { 510 leaf prefix { 511 type inet:ipv6-prefix; 512 description 513 "connected prefix sid."; 514 } 516 uses prefix-sid-attributes; 518 description 519 "This grouping defines cfg of prefix SID."; 520 } 522 grouping last-hop-behavior { 523 leaf last-hop-behavior { 524 if-feature sid-last-hop-behavior; 525 type enumeration { 526 enum explicit-null { 527 description 528 "Use explicit-null for the SID."; 529 } 530 enum no-php { 531 description 532 "Do no use PHP for the SID."; 533 } 534 enum php { 535 description 536 "Use PHP for the SID."; 537 } 538 } 539 description 540 "Configure last hop behavior."; 541 } 542 description 543 "Defines last hop behavior"; 544 } 546 grouping node-capabilities { 547 description "Containing SR node capabilities."; 548 container node-capabilities { 549 list transport-planes { 550 key transport-plane; 551 leaf transport-plane { 552 type identityref { 553 base segment-routing-transport; 554 } 555 description 556 "Transport plane supported"; 557 } 558 description 559 "List of supported transport planes."; 560 } 561 leaf readable-label-stack-depth { 562 type uint8; 563 description 564 "Number of MPLS labels that 565 can be read in the stack."; 566 } 567 description 568 "Shows the SR capability of the node."; 569 } // node-capabilities 570 } // sr-node-capabilities 572 grouping prefix-sid-attributes { 573 description "Containing SR attributes for a prefix."; 575 uses sid-value-type; 576 leaf start-sid { 577 type uint32; 578 mandatory true; 579 description 580 "Value associated with 581 prefix. The value must 582 be interpreted in the 583 context of value-type."; 584 } 586 leaf range { 587 type uint32; 588 description 589 "Describes how many SIDs could be 590 allocated."; 591 } 593 leaf algorithm { 594 type identityref { 595 base prefix-sid-algorithm; 596 } 597 description "Prefix-sid algorithm."; 598 } 599 } //prefix-sid-attributes 600 } 601 602 file "ietf-segment-routing@2016-10-28.yang" 603 module ietf-segment-routing { 604 namespace "urn:ietf:params:xml:ns:" 605 + "yang:ietf-segment-routing"; 606 prefix sr; 608 import ietf-inet-types { 609 prefix "inet"; 610 } 612 import ietf-yang-types { 613 prefix "yang"; 614 } 615 import ietf-routing { 616 prefix "rt"; 617 } 619 import ietf-interfaces { 620 prefix "if"; 621 } 623 import ietf-segment-routing-common { 624 prefix "sr-cmn"; 625 } 627 organization 628 "IETF SPRING Working Group"; 630 contact 631 "WG List: 633 Editor: Stephane Litkowski 634 636 Author: Acee Lindem 637 638 Author: Yingzhen Qu 639 640 Author: Pushpasis Sarkar 641 642 Author: Jeff Tantsura 643 645 "; 647 description 648 "The YANG module defines a generic configuration model for 649 Segment routing common across all of the vendor 650 implementations."; 652 revision 2016-10-28 { 653 description " 654 * Add support of MSD (Maximum SID Depth) 655 * Update contact info 656 "; 657 reference 658 "RFC XXXX: YANG Data Model for Segment Routing."; 659 } 661 revision 2016-10-24 { 662 description " 663 * Moved common SR types and groupings to a seperate module 664 "; 665 reference 666 "RFC XXXX: YANG Data Model for Segment Routing."; 667 } 668 revision 2016-07-07 { 669 description " 670 * Add support of prefix-sid algorithm configuration 671 * change routing-protocols to control-plane-protocols 672 "; 673 reference 674 "RFC XXXX: YANG Data Model for Segment Routing."; 675 } 676 revision 2016-03-17 { 677 description " 678 * Add notification segment-routing-global-srgb-collision 679 * Add router-id to segment-routing-global-sid-collision 680 * Remove routing-instance 681 * Add typedef router-id 682 "; 683 reference 684 "RFC XXXX: YANG Data Model for Segment Routing."; 685 } 686 revision 2015-10-17 { 687 description " 688 * Add per-protocol SRGB config feature 689 * Move SRBG config to a grouping 690 "; 691 reference 692 "RFC XXXX: YANG Data Model for Segment Routing."; 693 } 694 revision 2015-06-22 { 695 description " 696 * Prefix SID config moved to 697 connected-prefix-sid-map in global SR cfg 698 rather than IGP. 699 "; 700 reference "draft-litkowski-spring-sr-yang-01"; 701 } 702 revision 2015-04-23 { 703 description " 704 * Node flag deprecated from prefixSID 705 * SR interface cfg moved to protocol 706 * Adding multiple binding policies for SRMS 707 "; 708 reference ""; 709 } 710 revision 2015-02-27 { 711 description "Initial"; 712 reference "draft-litkowski-spring-sr-yang-00"; 713 } 715 /* Features */ 717 feature mapping-server { 718 description 719 "Support of SRMS."; 720 } 722 feature protocol-srgb { 723 description 724 "Support per-protocol srgb configuration."; 725 } 727 feature msd { 728 description 729 "Support of signaling MSD (Maximum SID Depth) in IGP."; 730 } 732 /* Type Definitions */ 734 typedef system-id { 735 type string { 736 pattern 737 '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.00'; 738 } 739 description 740 "This type defines ISIS system id using pattern, 741 system id looks like : 0143.0438.AeF0.00"; 742 } 744 typedef router-id { 745 type union { 746 type system-id; 747 type yang:dotted-quad; 748 } 749 description 750 "OSPF/BGP router id or ISIS system ID."; 751 } 753 /* Groupings */ 755 grouping controlplane-cfg { 756 container segment-routing { 757 leaf enabled { 758 type boolean; 759 default false; 760 description 761 "Enables segment-routing 762 protocol extensions."; 763 } 764 container bindings { 765 container advertise { 766 leaf-list policies { 767 type string; 768 description 769 "List of policies to be advertised."; 770 } 771 description 772 "Authorize the advertise 773 of local mappings in binding TLV."; 774 } 775 leaf receive { 776 type boolean; 777 default true; 778 description 779 "Authorize the reception and usage 780 of binding TLV."; 781 } 782 description 783 "Control of binding advertisement 784 and reception."; 785 } 787 description 788 "segment routing global config."; 789 } 790 description 791 "Defines protocol configuration."; 792 } 794 grouping igp-interface-cfg { 795 container segment-routing { 797 container adjacency-sid { 798 list advertise-adj-group-sid { 799 key group-id; 801 leaf group-id { 802 type uint32; 803 description 804 "The value is an internal value to identify 805 a group-ID. Interfaces with the same 806 group-ID will be bundled together."; 808 } 809 description 810 "Control advertisement of S flag. 811 Enable to advertise a common Adj-SID 812 for parallel links."; 813 } 814 leaf advertise-protection { 815 type enumeration { 816 enum "single" { 817 description 818 "A single Adj-SID is associated 819 with the adjacency and reflects 820 the protection configuration."; 821 } 822 enum "dual" { 823 description 824 "Two Adj-SIDs will be associated 825 with the adjacency if interface 826 is protected. In this case 827 one will be enforced with 828 backup flag set, the other 829 will be enforced to backup flag unset. 830 In case, protection is not configured, 831 a single Adj-SID will be advertised 832 with backup flag unset."; 833 } 834 } 835 description 836 "If set, the Adj-SID refers to an 837 adjacency being protected."; 838 } 839 description 840 "Defines the adjacency SID properties."; 841 } 842 description 843 "container for SR interface cfg."; 844 } 845 description 846 "Grouping for IGP interface cfg."; 847 } 849 grouping msd-cfg { 850 leaf node-msd { 851 type uint8; 852 description 853 "Node MSD is the lowest MSD supported by the node."; 854 } 855 container link-msd { 856 list link-msds { 857 key interface; 858 leaf interface { 859 type if:interface-ref; 860 description 861 "Name of the interface."; 862 } 863 leaf msd { 864 type uint8; 865 description 866 "SID depth of the interface associated with the link."; 867 } 868 description 869 "List of link MSDs."; 870 } 871 description 872 "Link MSD is a number represetns the particular link MSD value."; 873 } 874 description 875 "MSD configuration grouping."; 876 } 878 /* Cfg */ 880 augment "/rt:routing" { 881 description 882 "This augments routing-instance 883 configuration with segment-routing."; 884 container segment-routing { 885 leaf transport-type { 886 type identityref { 887 base sr-cmn:segment-routing-transport; 888 } 889 default "sr-cmn:segment-routing-transport-mpls"; 890 description "Dataplane to be used."; 891 } 892 container msd { 893 if-feature msd; 894 uses msd-cfg; 895 description 896 "MSD configuration."; 897 } 898 container bindings { 899 container mapping-server { 900 if-feature mapping-server; 901 list policy { 902 key name; 903 leaf name { 904 type string; 905 description 906 "Name of the mapping policy."; 907 } 908 container ipv4 { 909 list mapping-entry { 910 key "prefix algorithm"; 911 uses sr-cmn:ipv4-sid-cfg; 913 description 914 "Mapping entries."; 915 } 916 description 917 "IPv4 mapping entries."; 918 } 919 container ipv6 { 920 list mapping-entry { 921 key "prefix algorithm"; 922 uses sr-cmn:ipv6-sid-cfg; 923 description 924 "Mapping entries."; 925 } 926 description 927 "IPv6 mapping entries."; 928 } 929 description 930 "Definition of mapping policy."; 931 } 932 description 933 "Configuration of mapping-server 934 local entries."; 935 } 936 container connected-prefix-sid-map { 937 container ipv4 { 938 list ipv4-prefix-sid { 939 key "prefix algorithm"; 940 uses sr-cmn:ipv4-sid-cfg; 941 uses sr-cmn:last-hop-behavior; 942 description 943 "List of prefix SID 944 mapped to IPv4 local prefixes."; 945 } 946 description 947 "Parameters associated with IPv4 prefix SID"; 948 } 949 container ipv6 { 950 list ipv6-prefix-sid { 951 key "prefix algorithm"; 952 uses sr-cmn:ipv6-sid-cfg; 953 uses sr-cmn:last-hop-behavior; 954 description 955 "List of prefix SID 956 mapped to IPv6 local prefixes."; 957 } 958 description 959 "Parameters associated with IPv6 prefix SID"; 960 } 961 description 962 "Prefix SID configuration."; 963 } 964 description 965 "List of bindings."; 966 } 967 container global-srgb { 968 uses sr-cmn:srgb-cfg; 969 description 970 "Global SRGB configuration."; 971 } 972 description 973 "segment routing global config."; 974 } 975 } 977 /* Operational states */ 979 augment "/rt:routing-state" { 980 description 981 "This augments the operational states 982 with segment-routing."; 983 container segment-routing { 984 uses sr-cmn:node-capabilities; 985 container msd { 986 uses msd-cfg; 987 description 988 "MSD configuration state."; 989 } 990 list label-blocks { 991 leaf lower-bound { 992 type uint32; 993 description 994 "Lower bound of the label block."; 995 } 996 leaf upper-bound { 997 type uint32; 998 description 999 "Upper bound of the label block."; 1000 } 1001 leaf size { 1002 type uint32; 1003 description 1004 "Number of indexes in the block."; 1005 } 1006 leaf free { 1007 type uint32; 1008 description 1009 "Number of indexes free in the block."; 1010 } 1011 leaf used { 1012 type uint32; 1013 description 1014 "Number of indexes used in the block."; 1015 } 1016 description 1017 "List of labels blocks currently 1018 in use."; 1019 } 1021 container global-sid-list { 1022 list sid { 1023 key "target sid source source-protocol binding-type"; 1024 ordered-by system; 1025 leaf target { 1026 type string; 1027 description 1028 "Defines the target of the binding. 1029 It can be a prefix or something else."; 1030 } 1031 leaf sid { 1032 type uint32; 1033 description 1034 "Index associated with the prefix."; 1035 } 1036 leaf algorithm { 1037 type uint8; 1038 description 1039 "Algorithm to be used for the prefix 1040 SID."; 1041 } 1042 leaf source { 1043 type inet:ip-address; 1044 description 1045 "IP address of the router than own 1046 the binding."; 1047 } 1048 leaf used { 1049 type boolean; 1050 description 1051 "Defines if the binding is used 1052 in forwarding plane."; 1053 } 1054 leaf source-protocol { 1055 type leafref { 1056 path "/rt:routing-state/rt:control-plane-protocols/" 1057 + "rt:control-plane-protocol/rt:name"; 1058 } 1059 description 1060 "Rtg protocol that owns the binding"; 1061 } 1062 leaf binding-type { 1063 type enumeration { 1064 enum prefix-sid { 1065 description 1066 "Binding is learned from 1067 a prefix SID."; 1068 } 1069 enum binding-tlv { 1070 description 1071 "Binding is learned from 1072 a binding TLV."; 1073 } 1074 } 1075 description 1076 "Type of binding."; 1077 } 1078 description 1079 "Binding."; 1081 } 1082 description 1083 "List of prefix and SID associations."; 1084 } 1085 description 1086 "Segment routing operational states."; 1087 } 1088 } 1090 /* Notifications */ 1092 notification segment-routing-global-srgb-collision { 1093 list srgb-collisions { 1094 leaf lower-bound { 1095 type uint32; 1096 description 1097 "Lower value in the block."; 1098 } 1099 leaf upper-bound { 1100 type uint32; 1101 description 1102 "Upper value in the block."; 1103 } 1104 leaf routing-protocol { 1105 type leafref { 1106 path "/rt:routing-state/rt:control-plane-protocols/" 1107 + "rt:control-plane-protocol/rt:name"; 1108 } 1109 description 1110 "Routing protocol reference that received the event."; 1111 } 1112 leaf originating-rtr-id { 1113 type router-id; 1114 description 1115 "Originating router id of this SRGB block."; 1116 } 1117 description 1118 "List of SRGB blocks that conflict."; 1119 } 1120 description 1121 "This notification is sent when received SRGB blocks from 1122 a router conflict."; 1123 } 1124 notification segment-routing-global-sid-collision { 1125 leaf received-target { 1126 type string; 1127 description 1128 "Target received in the controlplane that 1129 caused SID collision."; 1130 } 1131 leaf new-sid-rtr-id { 1132 type router-id; 1133 description 1134 "Router Id that advertising the conflicting SID."; 1135 } 1136 leaf original-target { 1137 type string; 1138 description 1139 "Target already available in database that have the same SID 1140 as the received target."; 1142 } 1143 leaf original-sid-rtr-id { 1144 type router-id; 1145 description 1146 "Original router ID that advertised the conflicting SID."; 1147 } 1148 leaf index { 1149 type uint32; 1150 description 1151 "Value of the index used by two different prefixes."; 1152 } 1153 leaf routing-protocol { 1154 type leafref { 1155 path "/rt:routing-state/rt:control-plane-protocols/" 1156 + "rt:control-plane-protocol/rt:name"; 1157 } 1158 description 1159 "Routing protocol reference that received the event."; 1160 } 1161 description 1162 "This notification is sent when a new mapping is learned 1163 , containing mapping 1164 where the SID is already used. 1165 The notification generation must be throttled with at least 1166 a 5 second gap. "; 1167 } 1168 notification segment-routing-index-out-of-range { 1169 leaf received-target { 1170 type string; 1171 description 1172 "Target received in the controlplane 1173 that caused SID collision."; 1174 } 1175 leaf received-index { 1176 type uint32; 1177 description 1178 "Value of the index received."; 1179 } 1180 leaf routing-protocol { 1181 type leafref { 1182 path "/rt:routing-state/rt:control-plane-protocols/" + 1183 "rt:control-plane-protocol/rt:name"; 1184 } 1185 description 1186 "Routing protocol reference that received the event."; 1187 } 1188 description 1189 "This notification is sent when a binding 1190 is received, containing a segment index 1191 which is out of the local configured ranges. 1192 The notification generation must be throttled with at least 1193 a 5 second gap. "; 1194 } 1195 } 1196 1198 8. Security Considerations 1200 TBD. 1202 9. Acknowledgements 1204 Authors would like to thank Derek Yeung, Acee Lindem, Greg Hankins, 1205 Hannes Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge for their 1206 contributions. 1208 10. IANA Considerations 1210 TBD. 1212 11. Normative References 1214 [I-D.ietf-spring-segment-routing] 1215 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1216 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1217 spring-segment-routing-09 (work in progress), July 2016. 1219 [I-D.tantsura-isis-segment-routing-msd] 1220 Tantsura, J. and U. Chunduri, "Signaling MSD (Maximum SID 1221 Depth) using IS-IS", draft-tantsura-isis-segment-routing- 1222 msd-02 (work in progress), September 2016. 1224 [I-D.tantsura-ospf-segment-routing-msd] 1225 Tantsura, J. and U. Chunduri, "Signaling MSD (Maximum SID 1226 Depth) using OSPF", draft-tantsura-ospf-segment-routing- 1227 msd-01 (work in progress), September 2016. 1229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1230 Requirement Levels", BCP 14, RFC 2119, March 1997. 1232 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1233 Network Configuration Protocol (NETCONF)", RFC 6020, 1234 October 2010. 1236 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 1237 RFC 7950, August 2016. 1239 Authors' Addresses 1241 Stephane Litkowski 1242 Orange Business Service 1244 Email: stephane.litkowski@orange.com 1246 Yingzhen Qu 1247 Cisco Systems 1249 Email: yiqu@cisco.com 1251 Pushpasis Sarkar 1252 Individual 1254 Email: pushpasis.ietf@gmail.com 1256 Jeff Tantsura 1257 Individual 1259 Email: jefftant.ietf@gmail.com