idnits 2.17.00 (12 Aug 2021) /tmp/idnits47595/draft-ietf-spring-sr-yang-03.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 6 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 162 has weird spacing: '...r-bound uin...' == Line 163 has weird spacing: '...r-bound uin...' == Line 168 has weird spacing: '...t-plane ide...' -- The document date (July 07, 2016) is 2143 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: January 8, 2017 Cisco Systems 6 P. Sarkar 7 Juniper Networks 8 J. Tantsura 9 Ericsson 10 July 07, 2016 12 YANG Data Model for Segment Routing 13 draft-ietf-spring-sr-yang-03 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 January 8, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 8 75 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 79 11. Normative References . . . . . . . . . . . . . . . . . . . . 24 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 algorithm] 131 | | | +--rw prefix inet:ipv4-prefix 132 | | | +--rw value-type? enumeration 133 | | | +--rw start-sid uint32 134 | | | +--rw range? uint32 135 | | | +--rw algorithm identityref 136 | | +--rw ipv6 137 | | +--rw mapping-entry* [prefix algorithm] 138 | | +--rw prefix inet:ipv6-prefix 139 | | +--rw value-type? enumeration 140 | | +--rw start-sid uint32 141 | | +--rw range? uint32 142 | | +--rw algorithm identityref 143 | +--rw connected-prefix-sid-map 144 | +--rw ipv4 145 | | +--rw ipv4-prefix-sid* [prefix algorithm] 146 | | +--rw prefix inet:ipv4-prefix 147 | | +--rw value-type? enumeration 148 | | +--rw start-sid uint32 149 | | +--rw range? uint32 150 | | +--rw algorithm identityref 151 | | +--rw last-hop-behavior? enumeration {sid-last-hop-behavior}? 152 | +--rw ipv6 153 | +--rw ipv6-prefix-sid* [prefix algorithm] 154 | +--rw prefix inet:ipv6-prefix 155 | +--rw value-type? enumeration 156 | +--rw start-sid uint32 157 | +--rw range? uint32 158 | +--rw algorithm identityref 159 | +--rw last-hop-behavior? enumeration {sid-last-hop-behavior}? 160 +--rw global-srgb 161 +--rw srgb* [lower-bound upper-bound] 162 +--rw lower-bound uint32 163 +--rw upper-bound uint32 164 augment /rt:routing-state: 165 +--ro segment-routing 166 +--ro node-capabilities 167 | +--ro transport-planes* [transport-plane] 168 | | +--ro transport-plane identityref 169 | +--ro segment-stack-push-limit? uint8 170 | +--ro readable-label-stack-depth? uint8 171 +--ro label-blocks* 172 | +--ro lower-bound? uint32 173 | +--ro upper-bound? uint32 174 | +--ro size? uint32 175 | +--ro free? uint32 176 | +--ro used? uint32 177 +--ro global-sid-list 178 +--ro sid* [target sid source source-protocol binding-type] 179 +--ro target string 180 +--ro sid uint32 181 +--ro algorithm? uint8 182 +--ro source inet:ip-address 183 +--ro used? boolean 184 +--ro source-protocol -> /rt:routing-state/control-plane-protocols 185 /control-plane-protocol/name 186 +--ro binding-type enumeration 187 notifications: 189 +---n segment-routing-global-srgb-collision 190 | +--ro srgb-collisions* 191 | +--ro lower-bound? uint32 192 | +--ro upper-bound? uint32 193 | +--ro routing-protocol? -> /rt:routing-state/control-plane-protocols 194 | /control-plane-protocol/name 195 | +--ro originating-rtr-id? router-id 196 +---n segment-routing-global-sid-collision 197 | +--ro received-target? string 198 | +--ro new-sid-rtr-id? router-id 199 | +--ro original-target? string 200 | +--ro original-sid-rtr-id? router-id 201 | +--ro index? uint32 202 | +--ro routing-protocol? -> /rt:routing-state/control-plane-protocols 203 | /control-plane-protocol/name 204 +---n segment-routing-index-out-of-range 205 +--ro received-target? string 206 +--ro received-index? uint32 207 +--ro routing-protocol? -> /rt:routing-state/control-plane-protocols 208 /control-plane-protocol/name 210 3. Configuration 212 This module augments the "/rt:routing/rt:routing-instance:" with a 213 segment-routing container. This container defines all the 214 configuration parameters related to segment-routing for this 215 particular routing-instance. 217 The segment-routing configuration is split in global routing-instance 218 configuration and interface configuration. 220 The global configuration includes : 222 o segment-routing transport type : The underlying transport type for 223 segment routing. The version of the model limits the transport 224 type to an MPLS dataplane. The transport-type is only defined 225 once for a particular routing-instance and is agnostic to the 226 control plane used. Only a single transport-type is supported in 227 this version of the model. 229 o bindings : Defines prefix to SID mappings. The operator can 230 control advertisement of Prefix-SID independently for IPv4 and 231 IPv6. Two types of mappings are available : 233 * Mapping-server : maps non local prefixes to a segment ID. 234 Configuration of bindings does not automatically allow 235 advertisement of those bindings. Advertisement must be 236 controlled by each routing-protocol instance (see Section 4). 237 Multiple mapping policies may be defined. 239 * Connected prefixes : maps connected prefixes to a segment ID. 240 Advertisement of the mapping will be done by IGP when enabled 241 for segment routing (see Section 4). The SID value can be 242 expressed as an index (default), or an absolute value. The 243 "last-hop-behavior" configuration dictates the PHP behavior: 244 "explicit-null", "php", or "non-php". 246 o SRGB (Segment Routing Global Block): Defines a list of label 247 blocks represented by a pair of lower-bound/upper-bound labels. 248 The SRGB is also agnostic to the control plane used. So all 249 routing-protocol instance will have to advertise the same SRGB. 251 4. IGP Control plane configuration 253 Support of segment-routing extensions for a particular IGP control 254 plane is done by augmenting routing-protocol configuration with 255 segment-routing extensions. This augmentation SHOULD be part of 256 separate YANG modules in order to not create any dependency for 257 implementations to support all protocol extensions. 259 This module defines groupings that SHOULD be used by IGP segment 260 routing modules. 262 The "controlplane-cfg" grouping defines the generic global 263 configuration for the IGP. 265 The "enabled" leaf enables segment-routing extensions for the 266 routing-protocol instance. 268 The "bindings" container controls the routing-protocol instance's 269 advertisement of local bindings and the processing of received 270 bindings. 272 4.1. IGP interface configuration 274 The interface configuration is part of the "igp-interface-cfg" 275 grouping and includes Adjacency SID properties. 277 4.1.1. Adjacency SID properties 279 4.1.1.1. Bundling 281 This section is a first proposal on how to use S-bit in Adj-SID to 282 create bundles. Authors would like to trigger discussion based on 283 this first proposal. 285 In case of parallel IP links between routers, an additional Adjacency 286 SID may be advertised representing more than one adjacency (i.e., a 287 bundle of adjacencies). The "advertise-adj-group-sid" configuration 288 controls whether or not an additional adjacency SID is advertised. 290 The "advertise-adj-group-sid" would be a list of "group-id". The 291 "group-id" will permit to identify interfaces that must be bundled 292 together. 294 +-------+ +------+ 295 | | ------- L1 ---- | | 296 | R1 | ------- L2 ---- | R2 | 297 | | ------- L3 ---- | | 298 | | ------- L4 ---- | | 299 +-------+ +------+ 301 In the figure above, R1 and R2 are interconnected by four links. A 302 routing protocol adjacency is established on each link. Operator 303 would like to create segment-routing Adj-SID that represent some 304 bundles of links. We can imagine two different bundles : L1/L2 and 305 L2/L3. To achieve this behavior, the service provider will configure 306 a "group-id" X for both interfaces L1 and L2 and a "group-id" Y for 307 both interfaces L3 and L3. This will result in R1 advertising an 308 additional Adj-SID for each adjacency, for example a Adj-SID with S 309 flag set and value of 400 will be added to L1 and L2. A Adj-SID with 310 S flag set and value of 500 will be added to L3 and L4. As L1/L2 and 311 L3/L4 does not share the same "group-id", a different SID value will 312 be allocated. 314 4.1.1.2. Protection 316 The "advertise-protection" defines how protection for an interface is 317 advertised. It does not control the activation or deactivation of 318 protection. If the "single" option is used, a single Adj-SID will be 319 advertised for the interface. If the interface is protected, the 320 B-Flag for the Adj-SID advertisement will be set. If the "dual" 321 option is used and if the interface is protected, two Adj-SIDs will 322 be advertised for the interface adjacencies. One Adj-SID will always 323 have the B-Flag set and the other will have the B-Flag clear. This 324 option is intended to be used in the case of traffic engineering 325 where a path must use either protected segments or non-protected 326 segments. 328 5. States 330 The operational states contains information reflecting the usage of 331 allocated SRGB labels. 333 It also includes a list of all global SIDs, their associated 334 bindings, and other information such as the source protocol and 335 algorithm. 337 6. Notifications 339 The model defines the following notifications for segment-routing. 341 o segment-routing-global-srgb-collision: Rasied when a control plan 342 advertised SRGB blocks have conflicts. 344 o segment-routing-global-sid-collision: Raised when a control plane 345 advertised index is already associated with another target (in 346 this version, the only defined targets are IPv4 and IPv6 347 prefixes). 349 o segment-routing-index-out-of-range: Raised when a control plane 350 advertised index fall outside the range of SRGBs configured for 351 the network device. 353 7. YANG Module 355 file "ietf-segment-routing@2016-07-07.yang" 356 module ietf-segment-routing { 357 namespace "urn:ietf:params:xml:ns:" 358 + "yang:ietf-segment-routing"; 359 prefix sr; 361 import ietf-inet-types { 362 prefix "inet"; 363 } 365 import ietf-yang-types { 366 prefix "yang"; 367 } 369 import ietf-routing { 370 prefix "rt"; 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: Ing-Wher Chen 389 390 Author: Jeff Tantsura 391 393 "; 395 description 396 "The YANG module defines a generic configuration model for 397 Segment routing common across all of the vendor 398 implementations."; 400 revision 2016-07-07 { 401 description " 402 * Add support of prefix-sid algorithm configuration 403 * change routing-protocols to control-plane-protocols 404 "; 405 reference 406 "RFC XXXX: YANG Data Model for Segment Routing."; 407 } 409 revision 2016-03-17 { 410 description " 411 * Add notification segment-routing-global-srgb-collision 412 * Add router-id to segment-routing-global-sid-collision 413 * Remove routing-instance 414 * Add typedef router-id 415 "; 416 reference 417 "RFC XXXX: YANG Data Model for Segment Routing."; 418 } 419 revision 2015-10-17 { 420 description " 421 * Add per-protocol SRGB config feature 422 * Move SRBG config to a grouping 423 "; 424 reference 425 "RFC XXXX: YANG Data Model for Segment Routing."; 426 } 427 revision 2015-06-22 { 428 description " 429 * Prefix SID config moved to 430 connected-prefix-sid-map in global SR cfg 431 rather than IGP. 432 "; 433 reference "draft-litkowski-spring-sr-yang-01"; 434 } 435 revision 2015-04-23 { 436 description " 437 * Node flag deprecated from prefixSID 438 * SR interface cfg moved to protocol 439 * Adding multiple binding policies for SRMS 440 "; 441 reference ""; 442 } 443 revision 2015-02-27 { 444 description "Initial"; 445 reference "draft-litkowski-spring-sr-yang-00"; 446 } 448 /* Identities */ 449 identity segment-routing-transport { 450 description 451 "Base identity for segment routing transport."; 452 } 453 identity segment-routing-transport-mpls { 454 base segment-routing-transport; 455 description 456 "This identity represents MPLS transport for segment 457 routing."; 458 } 460 identity prefix-sid-algorithm { 461 description 462 "Base identity for prefix-sid algorithm."; 463 } 465 identity prefix-sid-algorithm-shortest-path { 466 base prefix-sid-algorithm; 467 description 468 "The default behavior of prefix-sid algorithm."; 469 } 471 identity prefix-sid-algorithm-strict-spf { 472 base prefix-sid-algorithm; 473 description 474 "This algorithm mandates that the packet is forwared 475 according to ECMP-aware SPF algorithm."; 476 } 478 /* Features */ 480 feature mapping-server { 481 description 482 "Support of SRMS."; 483 } 485 feature sid-last-hop-behavior { 486 description 487 "Configurable last hop behavior."; 488 } 490 feature protocol-srgb { 491 description 492 "Support per-protocol srgb configuration."; 493 } 495 /* Type Definitions */ 497 typedef system-id { 498 type string { 499 pattern 500 '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.00'; 501 } 502 description 503 "This type defines ISIS system id using pattern, 504 system id looks like : 0143.0438.AeF0.00"; 505 } 507 typedef router-id { 508 type union { 509 type system-id; 510 type yang:dotted-quad; 511 } 512 description 513 "OSPF/BGP router id or ISIS system ID."; 514 } 516 /* Groupings */ 518 grouping srgb-cfg { 519 list srgb { 520 key "lower-bound upper-bound"; 521 ordered-by user; 522 leaf lower-bound { 523 type uint32; 524 description 525 "Lower value in the block."; 526 } 527 leaf upper-bound { 528 type uint32; 529 description 530 "Upper value in the block."; 531 } 532 description 533 "List of global blocks to be 534 advertised."; 535 } 536 description 537 "Grouping for SRGB configuration."; 538 } 540 grouping controlplane-cfg { 541 container segment-routing { 542 leaf enabled { 543 type boolean; 544 default false; 545 description 546 "Enables segment-routing 547 protocol extensions."; 548 } 549 container bindings { 550 container advertise { 551 leaf-list policies { 552 type string; 553 description 554 "List of policies to be advertised."; 555 } 556 description 557 "Authorize the advertise 558 of local mappings in binding TLV."; 559 } 560 leaf receive { 561 type boolean; 562 default true; 563 description 564 "Authorize the reception and usage 565 of binding TLV."; 566 } 567 description 568 "Control of binding advertisement 569 and reception."; 570 } 572 description 573 "segment routing global config."; 574 } 575 description 576 "Defines protocol configuration."; 577 } 579 grouping sid-value-type { 580 leaf value-type { 581 type enumeration { 582 enum index { 583 description 584 "The value will be 585 interpreted as an index."; 586 } 587 enum absolute { 588 description 589 "The value will become 590 interpreted as an absolute 591 value."; 592 } 593 } 594 default index; 595 description 596 "This leaf defines how value 597 must be interpreted."; 598 } 599 description 600 "Defines how the SID value is expressed."; 601 } 603 grouping ipv4-sid-cfg { 605 leaf prefix { 606 type inet:ipv4-prefix; 607 description 608 "connected prefix sid."; 609 } 611 uses sid-value-type; 613 leaf start-sid { 614 type uint32; 615 mandatory true; 616 description 617 "Value associated with 618 prefix. The value must 619 be interpreted in the 620 context of value-type."; 621 } 623 leaf range { 624 type uint32; 625 description 626 "Describes how many SIDs could be 627 allocated."; 628 } 630 leaf algorithm { 631 type identityref { 632 base prefix-sid-algorithm; 633 } 634 description "Prefix-sid algorithm."; 635 } 636 description 637 "This grouping defines cfg of prefix SID."; 638 } 640 grouping ipv6-sid-cfg { 641 leaf prefix { 642 type inet:ipv6-prefix; 643 description 644 "connected prefix sid."; 645 } 647 uses sid-value-type; 649 leaf start-sid { 650 type uint32; 651 mandatory true; 652 description 653 "Value associated with 654 prefix. The value must 655 be interpreted in the 656 context of value-type."; 657 } 659 leaf range { 660 type uint32; 661 description 662 "Describes how many SIDs could be 663 allocated."; 664 } 666 leaf algorithm { 667 type identityref { 668 base prefix-sid-algorithm; 669 } 670 description "Prefix-sid algorithm."; 671 } 673 description 674 "This grouping defines cfg of prefix SID."; 675 } 677 grouping last-hop-behavior { 678 leaf last-hop-behavior { 679 if-feature sid-last-hop-behavior; 680 type enumeration { 681 enum explicit-null { 682 description 683 "Use explicit-null for the SID."; 684 } 685 enum no-php { 686 description 687 "Do no use PHP for the SID."; 688 } 689 enum php { 690 description 691 "Use PHP for the SID."; 692 } 693 } 694 description 695 "Configure last hop behavior."; 696 } 697 description 698 "Defines last hop behavior"; 699 } 701 grouping igp-interface-cfg { 702 container segment-routing { 704 container adjacency-sid { 705 list advertise-adj-group-sid { 706 key group-id; 708 leaf group-id { 709 type uint32; 710 description 711 "The value is an internal value to identify 712 a group-ID. Interfaces with the same 713 group-ID will be bundled together. 714 "; 715 } 716 description 717 "Control advertisement of S flag. 718 Enable to advertise a common Adj-SID 719 for parallel links."; 720 } 721 leaf advertise-protection { 722 type enumeration { 723 enum "single" { 724 description 725 "A single Adj-SID is associated 726 with the adjacency and reflects 727 the protection configuration."; 728 } 729 enum "dual" { 730 description 731 "Two Adj-SIDs will be associated 732 with the adjacency if interface 733 is protected. In this case 734 one will be enforced with 735 backup flag set, the other 736 will be enforced to backup flag unset. 737 In case, protection is not configured, 738 a single Adj-SID will be advertised 739 with backup flag unset."; 740 } 741 } 742 description 743 "If set, the Adj-SID refers to an 744 adjacency being protected."; 745 } 746 description 747 "Defines the adjacency SID properties."; 748 } 749 description 750 "container for SR interface cfg."; 751 } 752 description 753 "Grouping for IGP interface cfg."; 754 } 756 /* Cfg */ 758 augment "/rt:routing" { 759 description 760 "This augments routing-instance 761 configuration with segment-routing."; 762 container segment-routing { 763 leaf transport-type { 764 type identityref { 765 base segment-routing-transport; 766 } 767 default "segment-routing-transport-mpls"; 768 description "Dataplane to be used."; 769 } 770 container bindings { 771 container mapping-server { 772 if-feature mapping-server; 773 list policy { 774 key name; 775 leaf name { 776 type string; 777 description 778 "Name of the mapping policy."; 779 } 780 container ipv4 { 781 list mapping-entry { 782 key "prefix algorithm"; 783 uses ipv4-sid-cfg; 785 description 786 "Mapping entries."; 787 } 788 description 789 "IPv4 mapping entries."; 790 } 791 container ipv6 { 792 list mapping-entry { 793 key "prefix algorithm"; 794 uses ipv6-sid-cfg; 795 description 796 "Mapping entries."; 797 } 798 description 799 "IPv6 mapping entries."; 800 } 801 description 802 "Definition of mapping policy."; 803 } 804 description 805 "Configuration of mapping-server 806 local entries."; 808 } 809 container connected-prefix-sid-map { 810 container ipv4 { 811 list ipv4-prefix-sid { 812 key "prefix algorithm"; 813 uses ipv4-sid-cfg; 814 uses last-hop-behavior; 815 description 816 "List of prefix SID 817 mapped to IPv4 local prefixes."; 818 } 819 description 820 "Parameters associated with IPv4 prefix SID"; 821 } 822 container ipv6 { 823 list ipv6-prefix-sid { 824 key "prefix algorithm"; 825 uses ipv6-sid-cfg; 826 uses last-hop-behavior; 827 description 828 "List of prefix SID 829 mapped to IPv6 local prefixes."; 830 } 831 description 832 "Parameters associated with IPv6 prefix SID"; 833 } 834 description 835 "Prefix SID configuration."; 836 } 837 description 838 "List of bindings."; 839 } 840 container global-srgb { 841 uses srgb-cfg; 842 description 843 "Global SRGB configuration."; 844 } 845 description 846 "segment routing global config."; 847 } 848 } 850 /* Operational states */ 852 augment "/rt:routing-state" { 853 description 854 "This augments the operational states 855 with segment-routing."; 856 container segment-routing { 857 container node-capabilities { 858 list transport-planes { 859 key transport-plane; 860 leaf transport-plane { 861 type identityref { 862 base segment-routing-transport; 863 } 864 description 865 "Transport plane supported"; 866 } 867 description 868 "List of supported transport planes."; 869 } 870 leaf segment-stack-push-limit { 871 type uint8; 872 description 873 "Describes the number of segments 874 that can be pushed by the node."; 875 } 876 leaf readable-label-stack-depth { 877 type uint8; 878 description 879 "Number of MPLS labels that 880 can be read in the stack."; 881 } 882 description 883 "Shows the SR capability of the node."; 884 } 885 list label-blocks { 886 leaf lower-bound { 887 type uint32; 888 description 889 "Lower bound of the label block."; 890 } 891 leaf upper-bound { 892 type uint32; 893 description 894 "Upper bound of the label block."; 895 } 896 leaf size { 897 type uint32; 898 description 899 "Number of indexes in the block."; 900 } 901 leaf free { 902 type uint32; 903 description 904 "Number of indexes free in the block."; 905 } 906 leaf used { 907 type uint32; 908 description 909 "Number of indexes used in the block."; 910 } 911 description 912 "List of labels blocks currently 913 in use."; 914 } 916 container global-sid-list { 917 list sid { 918 key "target sid source source-protocol binding-type"; 919 ordered-by system; 920 leaf target { 921 type string; 922 description 923 "Defines the target of the binding. 924 It can be a prefix or something else."; 925 } 926 leaf sid { 927 type uint32; 928 description 929 "Index associated with the prefix."; 930 } 931 leaf algorithm { 932 type uint8; 933 description 934 "Algorithm to be used for the prefix 935 SID."; 936 } 937 leaf source { 938 type inet:ip-address; 939 description 940 "IP address of the router than own 941 the binding."; 942 } 943 leaf used { 944 type boolean; 945 description 946 "Defines if the binding is used 947 in forwarding plane."; 948 } 949 leaf source-protocol { 950 type leafref { 951 path "/rt:routing-state/rt:control-plane-protocols/" 952 + "rt:control-plane-protocol/rt:name"; 953 } 954 description 955 "Rtg protocol that owns the binding"; 956 } 957 leaf binding-type { 958 type enumeration { 959 enum prefix-sid { 960 description 961 "Binding is learned from 962 a prefix SID."; 963 } 964 enum binding-tlv { 965 description 966 "Binding is learned from 967 a binding TLV."; 968 } 969 } 970 description 971 "Type of binding."; 972 } 973 description 974 "Binding."; 976 } 977 description 978 "List of prefix and SID associations."; 979 } 980 description 981 "Segment routing operational states."; 982 } 983 } 985 /* Notifications */ 987 notification segment-routing-global-srgb-collision { 988 list srgb-collisions { 989 leaf lower-bound { 990 type uint32; 991 description 992 "Lower value in the block."; 993 } 994 leaf upper-bound { 995 type uint32; 996 description 997 "Upper value in the block."; 999 } 1000 leaf routing-protocol { 1001 type leafref { 1002 path "/rt:routing-state/rt:control-plane-protocols/" 1003 + "rt:control-plane-protocol/rt:name"; 1004 } 1005 description 1006 "Routing protocol reference that received the event."; 1007 } 1008 leaf originating-rtr-id { 1009 type router-id; 1010 description 1011 "Originating router id of this SRGB block."; 1012 } 1013 description 1014 "List of SRGB blocks that conflict."; 1015 } 1016 description 1017 "This notification is sent when received SRGB blocks from 1018 a router conflict."; 1019 } 1020 notification segment-routing-global-sid-collision { 1021 leaf received-target { 1022 type string; 1023 description 1024 "Target received in the controlplane that 1025 caused SID collision."; 1026 } 1027 leaf new-sid-rtr-id { 1028 type router-id; 1029 description 1030 "Router Id that advertising the conflicting SID."; 1031 } 1032 leaf original-target { 1033 type string; 1034 description 1035 "Target already available in database that have the same SID 1036 as the received target."; 1037 } 1038 leaf original-sid-rtr-id { 1039 type router-id; 1040 description 1041 "Original router ID that advertised the conflicting SID."; 1042 } 1043 leaf index { 1044 type uint32; 1045 description 1046 "Value of the index used by two different prefixes."; 1048 } 1049 leaf routing-protocol { 1050 type leafref { 1051 path "/rt:routing-state/rt:control-plane-protocols/" 1052 + "rt:control-plane-protocol/rt:name"; 1053 } 1054 description 1055 "Routing protocol reference that received the event."; 1056 } 1057 description 1058 "This notification is sent when a new mapping is learned 1059 , containing mapping 1060 where the SID is already used. 1061 The notification generation must be throttled with at least 1062 a 5 second gap. "; 1063 } 1064 notification segment-routing-index-out-of-range { 1065 leaf received-target { 1066 type string; 1067 description 1068 "Target received in the controlplane 1069 that caused SID collision."; 1070 } 1071 leaf received-index { 1072 type uint32; 1073 description 1074 "Value of the index received."; 1075 } 1076 leaf routing-protocol { 1077 type leafref { 1078 path "/rt:routing-state/rt:control-plane-protocols/" + 1079 "rt:control-plane-protocol/rt:name"; 1080 } 1081 description 1082 "Routing protocol reference that received the event."; 1083 } 1084 description 1085 "This notification is sent when a binding 1086 is received, containing a segment index 1087 which is out of the local configured ranges. 1088 The notification generation must be throttled with at least 1089 a 5 second gap. "; 1090 } 1092 } 1093 1095 8. Security Considerations 1097 TBD. 1099 9. Acknowledgements 1101 Authors would like to thank Derek Yeung, Acee Lindem, Greg Hankins, 1102 Hannes Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge for their 1103 contributions. 1105 10. IANA Considerations 1107 TBD. 1109 11. Normative References 1111 [I-D.ietf-spring-segment-routing] 1112 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1113 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1114 spring-segment-routing-03 (work in progress), May 2015. 1116 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1117 Requirement Levels", BCP 14, RFC 2119, March 1997. 1119 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1120 Network Configuration Protocol (NETCONF)", RFC 6020, 1121 October 2010. 1123 Authors' Addresses 1125 Stephane Litkowski 1126 Orange Business Service 1128 Email: stephane.litkowski@orange.com 1130 Yingzhen Qu 1131 Cisco Systems 1133 Email: yiqu@cisco.com 1135 Pushpasis Sarkar 1136 Juniper Networks 1138 Email: psarkar@juniper.net 1139 Jeff Tantsura 1140 Ericsson 1142 Email: jeff.tantsura@ericsson.com