idnits 2.17.00 (12 Aug 2021) /tmp/idnits29320/draft-ietf-spring-sr-yang-02.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 5 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([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: '...rw name str...' == Line 158 has weird spacing: '...r-bound uin...' == Line 159 has weird spacing: '...r-bound uin...' == Line 164 has weird spacing: '...t-plane ide...' -- The document date (March 18, 2016) is 2254 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) == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 Summary: 2 errors (**), 0 flaws (~~), 6 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: September 19, 2016 Cisco Systems 6 P. Sarkar 7 Juniper Networks 8 J. Tantsura 9 Ericsson 10 March 18, 2016 12 YANG Data Model for Segment Routing 13 draft-ietf-spring-sr-yang-02 15 Abstract 17 This document defines a YANG data model ([RFC6020]) for segment 18 routing ([I-D.ietf-spring-segment-routing]) configuration and 19 operation. This YANG model is intended to be used on network 20 elements to configure or operate segment routing. This document 21 defines also generic containers that SHOULD be reused by IGP protocol 22 modules to support segment routing. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 19, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 67 3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. IGP Control plane configuration . . . . . . . . . . . . . . . 6 69 4.1. IGP interface configuration . . . . . . . . . . . . . . . 6 70 4.1.1. Adjacency SID properties . . . . . . . . . . . . . . 6 71 4.1.1.1. Bundling . . . . . . . . . . . . . . . . . . . . 6 72 4.1.1.2. Protection . . . . . . . . . . . . . . . . . . . 7 73 5. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 8 75 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 79 11. Normative References . . . . . . . . . . . . . . . . . . . . 23 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 1.1. Tree diagram 94 A simplified graphical representation of the data model is presented 95 in Section 2. 97 The meaning of the symbols in these diagrams is as follows: 99 o Brackets "[" and "]" enclose list keys. 101 o Curly braces "{" and "}" contain names of optional features that 102 make the corresponding node conditional. 104 o Abbreviations before data node names: "rw" means configuration 105 (read-write), and "ro" state data (read-only). 107 o Symbols after data node names: "?" means an optional node and "*" 108 denotes a "list" or "leaf-list". 110 o Parentheses enclose choice and case nodes, and case nodes are also 111 marked with a colon (":"). 113 o Ellipsis ("...") stands for contents of subtrees that are not 114 shown. 116 2. Design of the Data Model 118 As the module definition is just starting, it is expected that there 119 will be changes as the module matures. 121 module: ietf-segment-routing 122 augment /rt:routing: 123 +--rw segment-routing 124 +--rw transport-type? identityref 125 +--rw bindings 126 | +--rw mapping-server {mapping-server}? 127 | | +--rw policy* [name] 128 | | +--rw name string 129 | | +--rw ipv4 130 | | | +--rw mapping-entry* [prefix] 131 | | | +--rw prefix inet:ipv4-prefix 132 | | | +--rw value-type? enumeration 133 | | | +--rw start-sid uint32 134 | | | +--rw range? uint32 135 | | +--rw ipv6 136 | | +--rw mapping-entry* [prefix] 137 | | +--rw prefix inet:ipv6-prefix 138 | | +--rw value-type? enumeration 139 | | +--rw start-sid uint32 140 | | +--rw range? uint32 141 | +--rw connected-prefix-sid-map 142 | +--rw ipv4 143 | | +--rw ipv4-prefix-sid* [prefix] 144 | | +--rw prefix inet:ipv4-prefix 145 | | +--rw value-type? enumeration 146 | | +--rw start-sid uint32 147 | | +--rw range? uint32 148 | | +--rw last-hop-behavior? enumeration {sid-last-hop-behavior}? 149 | +--rw ipv6 150 | +--rw ipv6-prefix-sid* [prefix] 151 | +--rw prefix inet:ipv6-prefix 152 | +--rw value-type? enumeration 153 | +--rw start-sid uint32 154 | +--rw range? uint32 155 | +--rw last-hop-behavior? enumeration {sid-last-hop-behavior}? 156 +--rw global-srgb 157 +--rw srgb* [lower-bound upper-bound] 158 +--rw lower-bound uint32 159 +--rw upper-bound uint32 160 augment /rt:routing-state: 161 +--ro segment-routing 162 +--ro node-capabilities 163 | +--ro transport-planes* [transport-plane] 164 | | +--ro transport-plane identityref 165 | +--ro segment-stack-push-limit? uint8 166 | +--ro readable-label-stack-depth? uint8 167 +--ro label-blocks* 168 | +--ro lower-bound? uint32 169 | +--ro upper-bound? uint32 170 | +--ro size? uint32 171 | +--ro free? uint32 172 | +--ro used? uint32 173 +--ro global-sid-list 174 +--ro sid* [target sid source source-protocol binding-type] 175 +--ro target string 176 +--ro sid uint32 177 +--ro algorithm? uint8 178 +--ro source inet:ip-address 179 +--ro used? boolean 180 +--ro source-protocol -> /rt:routing-state/routing-protocols/ 181 routing-protocol/name 182 +--ro binding-type enumeration 183 notifications: 184 +---n segment-routing-global-srgb-collision 185 | +--ro srgb-collisions* 186 | +--ro lower-bound? uint32 187 | +--ro upper-bound? uint32 188 | +--ro routing-protocol? -> /rt:routing-state/routing-protocols/ 189 routing-protocol/name 190 | +--ro originating-rtr-id? router-id 191 +---n segment-routing-global-sid-collision 192 | +--ro received-target? string 193 | +--ro new-sid-rtr-id? router-id 194 | +--ro original-target? string 195 | +--ro original-sid-rtr-id? router-id 196 | +--ro index? uint32 197 | +--ro routing-protocol? -> /rt:routing-state/routing-protocols/ 198 routing-protocol/name 199 +---n segment-routing-index-out-of-range 200 +--ro received-target? string 201 +--ro received-index? uint32 202 +--ro routing-protocol? -> /rt:routing-state/routing-protocols/ 203 routing-protocol/name 205 3. Configuration 207 This module augments the "/rt:routing/rt:routing-instance:" with a 208 segment-routing container. This container defines all the 209 configuration parameters related to segment-routing for this 210 particular routing-instance. 212 The segment-routing configuration is split in global routing-instance 213 configuration and interface configuration. 215 The global configuration includes : 217 o segment-routing transport type : The underlying transport type for 218 segment routing. The version of the model limits the transport 219 type to an MPLS dataplane. The transport-type is only defined 220 once for a particular routing-instance and is agnostic to the 221 control plane used. Only a single transport-type is supported in 222 this version of the model. 224 o bindings : Defines prefix to SID mappings. The operator can 225 control advertisement of Prefix-SID independently for IPv4 and 226 IPv6. Two types of mappings are available : 228 * Mapping-server : maps non local prefixes to a segment ID. 229 Configuration of bindings does not automatically allow 230 advertisement of those bindings. Advertisement must be 231 controlled by each routing-protocol instance (see Section 4). 232 Multiple mapping policies may be defined. 234 * Connected prefixes : maps connected prefixes to a segment ID. 235 Advertisement of the mapping will be done by IGP when enabled 236 for segment routing (see Section 4). The SID value can be 237 expressed as an index (default), or an absolute value. The 238 "last-hop-behavior" configuration dictates the PHP behavior: 239 "explicit-null", "php", or "non-php". 241 o SRGB (Segment Routing Global Block): Defines a list of label 242 blocks represented by a pair of lower-bound/upper-bound labels. 243 The SRGB is also agnostic to the control plane used. So all 244 routing-protocol instance will have to advertise the same SRGB. 246 4. IGP Control plane configuration 248 Support of segment-routing extensions for a particular IGP control 249 plane is done by augmenting routing-protocol configuration with 250 segment-routing extensions. This augmentation SHOULD be part of 251 separate YANG modules in order to not create any dependency for 252 implementations to support all protocol extensions. 254 This module defines groupings that SHOULD be used by IGP segment 255 routing modules. 257 The "controlplane-cfg" grouping defines the generic global 258 configuration for the IGP. 260 The "enabled" leaf enables segment-routing extensions for the 261 routing-protocol instance. 263 The "bindings" container controls the routing-protocol instance's 264 advertisement of local bindings and the processing of received 265 bindings. 267 4.1. IGP interface configuration 269 The interface configuration is part of the "igp-interface-cfg" 270 grouping and includes Adjacency SID properties. 272 4.1.1. Adjacency SID properties 274 4.1.1.1. Bundling 276 This section is a first proposal on how to use S-bit in Adj-SID to 277 create bundles. Authors would like to trigger discussion based on 278 this first proposal. 280 In case of parallel IP links between routers, an additional Adjacency 281 SID may be advertised representing more than one adjacency (i.e., a 282 bundle of adjacencies). The "advertise-adj-group-sid" configuration 283 controls whether or not an additional adjacency SID is advertised. 285 The "advertise-adj-group-sid" would be a list of "group-id". The 286 "group-id" will permit to identify interfaces that must be bundled 287 together. 289 +-------+ +------+ 290 | | ------- L1 ---- | | 291 | R1 | ------- L2 ---- | R2 | 292 | | ------- L3 ---- | | 293 | | ------- L4 ---- | | 294 +-------+ +------+ 296 In the figure above, R1 and R2 are interconnected by four links. A 297 routing protocol adjacency is established on each link. Operator 298 would like to create segment-routing Adj-SID that represent some 299 bundles of links. We can imagine two different bundles : L1/L2 and 300 L2/L3. To achieve this behavior, the service provider will configure 301 a "group-id" X for both interfaces L1 and L2 and a "group-id" Y for 302 both interfaces L3 and L3. This will result in R1 advertising an 303 additional Adj-SID for each adjacency, for example a Adj-SID with S 304 flag set and value of 400 will be added to L1 and L2. A Adj-SID with 305 S flag set and value of 500 will be added to L3 and L4. As L1/L2 and 306 L3/L4 does not share the same "group-id", a different SID value will 307 be allocated. 309 4.1.1.2. Protection 311 The "advertise-protection" defines how protection for an interface is 312 advertised. It does not control the activation or deactivation of 313 protection. If the "single" option is used, a single Adj-SID will be 314 advertised for the interface. If the interface is protected, the 315 B-Flag for the Adj-SID advertisement will be set. If the "dual" 316 option is used and if the interface is protected, two Adj-SIDs will 317 be advertised for the interface adjacencies. One Adj-SID will always 318 have the B-Flag set and the other will have the B-Flag clear. This 319 option is intended to be used in the case of traffic engineering 320 where a path must use either protected segments or non-protected 321 segments. 323 5. States 325 The operational states contains information reflecting the usage of 326 allocated SRGB labels. 328 It also includes a list of all global SIDs, their associated 329 bindings, and other information such as the source protocol and 330 algorithm. 332 6. Notifications 334 The model defines the following notifications for segment-routing. 336 o segment-routing-global-srgb-collision: Rasied when a control plan 337 advertised SRGB blocks have conflicts. 339 o segment-routing-global-sid-collision: Raised when a control plane 340 advertised index is already associated with another target (in 341 this version, the only defined targets are IPv4 and IPv6 342 prefixes). 344 o segment-routing-index-out-of-range: Raised when a control plane 345 advertised index fall outside the range of SRGBs configured for 346 the network device. 348 7. YANG Module 350 file "ietf-segment-routing@2016-03-18.yang" 351 module ietf-segment-routing { 352 namespace "urn:ietf:params:xml:ns:" 353 + "yang:ietf-segment-routing"; 354 prefix sr; 356 import ietf-inet-types { 357 prefix "inet"; 358 } 360 import ietf-yang-types { 361 prefix "yang"; 362 } 364 import ietf-routing { 365 prefix "rt"; 366 } 368 organization 369 "IETF SPRING Working Group"; 371 contact 372 "WG List: 374 Editor: Stephane Litkowski 375 377 Author: Acee Lindem 378 379 Author: Yingzhen Qu 380 381 Author: Pushpasis Sarkar 382 383 Author: Ing-Wher Chen 384 385 Author: Jeff Tantsura 386 388 "; 390 description 391 "The YANG module defines a generic configuration model for 392 Segment routing common across all of the vendor 393 implementations."; 395 revision 2016-03-18 { 396 description " 397 * Add notification segment-routing-global-srgb-collision 398 * Add router-id to segment-routing-global-sid-collision 399 * Remove routing-instance 400 * Add typedef router-id 401 "; 402 reference 403 "RFC XXXX: YANG Data Model for Segment Routing."; 404 } 405 revision 2015-10-17 { 406 description " 407 * Add per-protocol SRGB config feature 408 * Move SRBG config to a grouping 409 "; 410 reference 411 "RFC XXXX: YANG Data Model for Segment Routing."; 412 } 413 revision 2015-06-22 { 414 description " 415 * Prefix SID config moved to 416 connected-prefix-sid-map in global SR cfg 417 rather than IGP. 418 "; 419 reference "draft-litkowski-spring-sr-yang-01"; 420 } 421 revision 2015-04-23 { 422 description " 423 * Node flag deprecated from prefixSID 424 * SR interface cfg moved to protocol 425 * Adding multiple binding policies for SRMS 426 "; 427 reference ""; 429 } 430 revision 2015-02-27 { 431 description "Initial"; 432 reference "draft-litkowski-spring-sr-yang-00"; 433 } 435 /* Identities */ 436 identity segment-routing-transport { 437 description 438 "Base identity for segment routing transport."; 439 } 440 identity segment-routing-transport-mpls { 441 base segment-routing-transport; 442 description 443 "This identity represents MPLS transport for segment 444 routing."; 445 } 447 /* Features */ 449 feature mapping-server { 450 description 451 "Support of SRMS."; 452 } 454 feature sid-last-hop-behavior { 455 description 456 "Configurable last hop behavior."; 457 } 459 feature protocol-srgb { 460 description 461 "Support per-protocol srgb configuration."; 462 } 464 /* Type Definitions */ 466 typedef system-id { 467 type string { 468 pattern 469 '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.00'; 470 } 471 description 472 "This type defines ISIS system id using pattern, 473 system id looks like : 0143.0438.AeF0.00"; 474 } 476 typedef router-id { 477 type union { 478 type system-id; 479 type yang:dotted-quad; 480 } 481 description 482 "OSPF/BGP router id or ISIS system ID."; 483 } 485 /* Groupings */ 487 grouping srgb-cfg { 488 list srgb { 489 key "lower-bound upper-bound"; 490 ordered-by user; 491 leaf lower-bound { 492 type uint32; 493 description 494 "Lower value in the block."; 495 } 496 leaf upper-bound { 497 type uint32; 498 description 499 "Upper value in the block."; 500 } 501 description 502 "List of global blocks to be 503 advertised."; 504 } 505 description 506 "Grouping for SRGB configuration."; 507 } 509 grouping controlplane-cfg { 510 container segment-routing { 511 leaf enabled { 512 type boolean; 513 default false; 514 description 515 "Enables segment-routing 516 protocol extensions."; 517 } 518 container bindings { 519 container advertise { 520 leaf-list policies { 521 type string; 522 description 523 "List of policies to be advertised."; 524 } 526 description 527 "Authorize the advertise 528 of local mappings in binding TLV."; 529 } 530 leaf receive { 531 type boolean; 532 default true; 533 description 534 "Authorize the reception and usage 535 of binding TLV."; 536 } 537 description 538 "Control of binding advertisement 539 and reception."; 540 } 542 description 543 "segment routing global config."; 544 } 545 description 546 "Defines protocol configuration."; 547 } 549 grouping sid-value-type { 550 leaf value-type { 551 type enumeration { 552 enum index { 553 description 554 "The value will be 555 interpreted as an index."; 556 } 557 enum absolute { 558 description 559 "The value will become 560 interpreted as an absolute 561 value."; 562 } 563 } 564 default index; 565 description 566 "This leaf defines how value 567 must be interpreted."; 568 } 569 description 570 "Defines how the SID value is expressed."; 571 } 573 grouping ipv4-sid-cfg { 574 leaf prefix { 575 type inet:ipv4-prefix; 576 description 577 "connected prefix sid."; 578 } 580 uses sid-value-type; 582 leaf start-sid { 583 type uint32; 584 mandatory true; 585 description 586 "Value associated with 587 prefix. The value must 588 be interpreted in the 589 context of value-type."; 590 } 592 leaf range { 593 type uint32; 594 description 595 "Describes how many SIDs could be 596 allocated."; 597 } 598 description 599 "This grouping defines cfg of prefix SID."; 600 } 602 grouping ipv6-sid-cfg { 603 leaf prefix { 604 type inet:ipv6-prefix; 605 description 606 "connected prefix sid."; 607 } 609 uses sid-value-type; 611 leaf start-sid { 612 type uint32; 613 mandatory true; 614 description 615 "Value associated with 616 prefix. The value must 617 be interpreted in the 618 context of value-type."; 619 } 621 leaf range { 622 type uint32; 623 description 624 "Describes how many SIDs could be 625 allocated."; 626 } 628 description 629 "This grouping defines cfg of prefix SID."; 630 } 632 grouping last-hop-behavior { 633 leaf last-hop-behavior { 634 if-feature sid-last-hop-behavior; 635 type enumeration { 636 enum explicit-null { 637 description 638 "Use explicit-null for the SID."; 639 } 640 enum no-php { 641 description 642 "Do no use PHP for the SID."; 643 } 644 enum php { 645 description 646 "Use PHP for the SID."; 647 } 648 } 649 description 650 "Configure last hop behavior."; 651 } 652 description 653 "Defines last hop behavior"; 654 } 656 grouping igp-interface-cfg { 657 container segment-routing { 659 container adjacency-sid { 660 list advertise-adj-group-sid { 661 key group-id; 663 leaf group-id { 664 type uint32; 665 description 667 "The value is an internal value to identify 668 a group-ID. Interfaces with the same 669 group-ID will be bundled together. 671 "; 672 } 673 description 674 "Control advertisement of S flag. 675 Enable to advertise a common Adj-SID 676 for parallel links."; 677 } 678 leaf advertise-protection { 679 type enumeration { 680 enum "single" { 681 description 682 "A single Adj-SID is associated 683 with the adjacency and reflects 684 the protection configuration."; 685 } 686 enum "dual" { 687 description 688 "Two Adj-SIDs will be associated 689 with the adjacency if interface 690 is protected. In this case 691 one will be enforced with 692 backup flag set, the other 693 will be enforced to backup flag unset. 694 In case, protection is not configured, 695 a single Adj-SID will be advertised 696 with backup flag unset."; 697 } 698 } 699 description 700 "If set, the Adj-SID refers to an 701 adjacency being protected."; 702 } 703 description 704 "Defines the adjacency SID properties."; 705 } 706 description 707 "container for SR interface cfg."; 708 } 709 description 710 "Grouping for IGP interface cfg."; 711 } 713 /* Cfg */ 715 augment "/rt:routing" { 716 description 717 "This augments routing-instance 718 configuration with segment-routing."; 720 container segment-routing { 721 leaf transport-type { 722 type identityref { 723 base segment-routing-transport; 724 } 725 default "segment-routing-transport-mpls"; 726 description "Dataplane to be used."; 727 } 728 container bindings { 729 container mapping-server { 730 if-feature mapping-server; 731 list policy { 732 key name; 733 leaf name { 734 type string; 735 description 736 "Name of the mapping policy."; 737 } 738 container ipv4 { 739 list mapping-entry { 740 key prefix; 741 uses ipv4-sid-cfg; 743 description 744 "Mapping entries."; 745 } 746 description 747 "IPv4 mapping entries."; 748 } 749 container ipv6 { 750 list mapping-entry { 751 key prefix; 752 uses ipv6-sid-cfg; 753 description 754 "Mapping entries."; 755 } 756 description 757 "IPv6 mapping entries."; 758 } 759 description 760 "Definition of mapping policy."; 761 } 762 description 763 "Configuration of mapping-server 764 local entries."; 765 } 766 container connected-prefix-sid-map { 767 container ipv4 { 768 list ipv4-prefix-sid { 769 key prefix; 770 uses ipv4-sid-cfg; 771 uses last-hop-behavior; 772 description 773 "List of prefix SID 774 mapped to IPv4 local prefixes."; 775 } 776 description 777 "Parameters associated with IPv4 prefix SID"; 778 } 779 container ipv6 { 780 list ipv6-prefix-sid { 781 key prefix; 782 uses ipv6-sid-cfg; 783 uses last-hop-behavior; 784 description 785 "List of prefix SID 786 mapped to IPv6 local prefixes."; 787 } 788 description 789 "Parameters associated with IPv6 prefix SID"; 790 } 791 description 792 "Prefix SID configuration."; 793 } 794 description 795 "List of bindings."; 796 } 797 container global-srgb { 798 uses srgb-cfg; 799 description 800 "Global SRGB configuration."; 801 } 802 description 803 "segment routing global config."; 804 } 805 } 807 /* Operational states */ 809 augment "/rt:routing-state" { 810 description 811 "This augments the operational states 812 with segment-routing."; 813 container segment-routing { 814 container node-capabilities { 815 list transport-planes { 816 key transport-plane; 817 leaf transport-plane { 818 type identityref { 819 base segment-routing-transport; 820 } 821 description 822 "Transport plane supported"; 823 } 824 description 825 "List of supported transport planes."; 826 } 827 leaf segment-stack-push-limit { 828 type uint8; 829 description 830 "Describes the number of segments 831 that can be pushed by the node."; 832 } 833 leaf readable-label-stack-depth { 834 type uint8; 835 description 836 "Number of MPLS labels that 837 can be read in the stack."; 838 } 839 description 840 "Shows the SR capability of the node."; 841 } 842 list label-blocks { 843 leaf lower-bound { 844 type uint32; 845 description 846 "Lower bound of the label block."; 847 } 848 leaf upper-bound { 849 type uint32; 850 description 851 "Upper bound of the label block."; 852 } 853 leaf size { 854 type uint32; 855 description 856 "Number of indexes in the block."; 857 } 858 leaf free { 859 type uint32; 860 description 861 "Number of indexes free in the block."; 862 } 863 leaf used { 864 type uint32; 865 description 866 "Number of indexes used in the block."; 867 } 868 description 869 "List of labels blocks currently 870 in use."; 871 } 873 container global-sid-list { 874 list sid { 875 key "target sid source source-protocol binding-type"; 876 ordered-by system; 877 leaf target { 878 type string; 879 description 880 "Defines the target of the binding. 881 It can be a prefix or something else."; 882 } 883 leaf sid { 884 type uint32; 885 description 886 "Index associated with the prefix."; 887 } 888 leaf algorithm { 889 type uint8; 890 description 891 "Algorithm to be used for the prefix 892 SID."; 893 } 894 leaf source { 895 type inet:ip-address; 896 description 897 "IP address of the router than own 898 the binding."; 899 } 900 leaf used { 901 type boolean; 902 description 903 "Defines if the binding is used 904 in forwarding plane."; 905 } 906 leaf source-protocol { 907 type leafref { 908 path "/rt:routing-state/rt:routing-protocols/" 909 + "rt:routing-protocol/rt:name"; 910 } 911 description 912 "Rtg protocol that owns the binding"; 913 } 914 leaf binding-type { 915 type enumeration { 916 enum prefix-sid { 917 description 918 "Binding is learned from 919 a prefix SID."; 920 } 921 enum binding-tlv { 922 description 923 "Binding is learned from 924 a binding TLV."; 925 } 926 } 927 description 928 "Type of binding."; 929 } 930 description 931 "Binding."; 933 } 934 description 935 "List of prefix and SID associations."; 936 } 937 description 938 "Segment routing operational states."; 939 } 940 } 942 /* Notifications */ 944 notification segment-routing-global-srgb-collision { 945 list srgb-collisions { 946 leaf lower-bound { 947 type uint32; 948 description 949 "Lower value in the block."; 950 } 951 leaf upper-bound { 952 type uint32; 953 description 954 "Upper value in the block."; 955 } 956 leaf routing-protocol { 957 type leafref { 958 path "/rt:routing-state/rt:routing-protocols/" 959 + "rt:routing-protocol/rt:name"; 960 } 961 description 962 "Routing protocol reference that received the event."; 963 } 964 leaf originating-rtr-id { 965 type router-id; 966 description 967 "Originating router id of this SRGB block."; 968 } 969 description 970 "List of SRGB blocks that conflict."; 971 } 972 description 973 "This notification is sent when received SRGB blocks from 974 a router conflict."; 975 } 976 notification segment-routing-global-sid-collision { 977 leaf received-target { 978 type string; 979 description 980 "Target received in the controlplane that 981 caused SID collision."; 982 } 983 leaf new-sid-rtr-id { 984 type router-id; 985 description 986 "Router Id that advertising the conflicting SID."; 987 } 988 leaf original-target { 989 type string; 990 description 991 "Target already available in database that have the same SID 992 as the received target."; 993 } 994 leaf original-sid-rtr-id { 995 type router-id; 996 description 997 "Original router ID that advertised the conflicting SID."; 998 } 999 leaf index { 1000 type uint32; 1001 description 1002 "Value of the index used by two different prefixes."; 1003 } 1004 leaf routing-protocol { 1005 type leafref { 1006 path "/rt:routing-state/rt:routing-protocols/" 1007 + "rt:routing-protocol/rt:name"; 1008 } 1009 description 1010 "Routing protocol reference that received the event."; 1011 } 1012 description 1013 "This notification is sent when a new mapping is learned 1014 , containing mapping 1015 where the SID is already used. 1016 The notification generation must be throttled with at least 1017 a 5 second gap. "; 1018 } 1019 notification segment-routing-index-out-of-range { 1020 leaf received-target { 1021 type string; 1022 description 1023 "Target received in the controlplane 1024 that caused SID collision."; 1025 } 1026 leaf received-index { 1027 type uint32; 1028 description 1029 "Value of the index received."; 1030 } 1031 leaf routing-protocol { 1032 type leafref { 1033 path "/rt:routing-state/rt:routing-protocols/" + 1034 "rt:routing-protocol/rt:name"; 1035 } 1036 description 1037 "Routing protocol reference that received the event."; 1038 } 1039 description 1040 "This notification is sent when a binding 1041 is received, containing a segment index 1042 which is out of the local configured ranges. 1043 The notification generation must be throttled with at least 1044 a 5 second gap. "; 1045 } 1047 } 1048 1050 8. Security Considerations 1052 TBD. 1054 9. Acknowledgements 1056 Authors would like to thank Derek Yeung, Acee Lindem, Greg Hankins, 1057 Hannes Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge for their 1058 contributions. 1060 10. IANA Considerations 1062 TBD. 1064 11. Normative References 1066 [I-D.ietf-spring-segment-routing] 1067 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1068 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1069 spring-segment-routing-03 (work in progress), May 2015. 1071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1072 Requirement Levels", BCP 14, RFC 2119, March 1997. 1074 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1075 Network Configuration Protocol (NETCONF)", RFC 6020, 1076 October 2010. 1078 Authors' Addresses 1080 Stephane Litkowski 1081 Orange Business Service 1083 Email: stephane.litkowski@orange.com 1085 Yingzhen Qu 1086 Cisco Systems 1088 Email: yiqu@cisco.com 1090 Pushpasis Sarkar 1091 Juniper Networks 1093 Email: psarkar@juniper.net 1094 Jeff Tantsura 1095 Ericsson 1097 Email: jeff.tantsura@ericsson.com