idnits 2.17.00 (12 Aug 2021) /tmp/idnits44382/draft-ietf-spring-sr-yang-01.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 2 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...' == Line 180 has weird spacing: '...rotocol lea...' -- The document date (October 17, 2015) is 2408 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 (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group S. Litkowski 3 Internet-Draft Orange Business Service 4 Intended status: Standards Track Y. Qu 5 Expires: April 19, 2016 Cisco Systems 6 P. Sarkar 7 Juniper Networks 8 J. Tantsura 9 Ericsson 10 October 17, 2015 12 YANG Data Model for Segment Routing 13 draft-ietf-spring-sr-yang-01 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 April 19, 2016. 47 Copyright Notice 49 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 79 11. Normative References . . . . . . . . . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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/rt:routing-instance: 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/rt:routing-instance: 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 leafref 181 +--ro binding-type enumeration 182 notifications: 183 +---n segment-routing-global-sid-collision 184 | +--ro received-target? string 185 | +--ro original-target? string 186 | +--ro index? uint32 187 | +--ro routing-protocol? leafref 188 +---n segment-routing-index-out-of-range 189 +--ro received-target? string 190 +--ro received-index? uint32 191 +--ro routing-protocol? leafref 193 3. Configuration 195 This module augments the "/rt:routing/rt:routing-instance:" with a 196 segment-routing container. This container defines all the 197 configuration parameters related to segment-routing for this 198 particular routing-instance. 200 The segment-routing configuration is split in global routing-instance 201 configuration and interface configuration. 203 The global configuration includes : 205 o segment-routing transport type : The underlying transport type for 206 segment routing. The version of the model limits the transport 207 type to an MPLS dataplane. The transport-type is only defined 208 once for a particular routing-instance and is agnostic to the 209 control plane used. Only a single transport-type is supported in 210 this version of the model. 212 o bindings : Defines prefix to SID mappings. The operator can 213 control advertisement of Prefix-SID independently for IPv4 and 214 IPv6. Two types of mappings are available : 216 * Mapping-server : maps non local prefixes to a segment ID. 217 Configuration of bindings does not automatically allow 218 advertisement of those bindings. Advertisement must be 219 controlled by each routing-protocol instance (see Section 4). 220 Multiple mapping policies may be defined. 222 * Connected prefixes : maps connected prefixes to a segment ID. 223 Advertisement of the mapping will be done by IGP when enabled 224 for segment routing (see Section 4). The SID value can be 225 expressed as an index (default), or an absolute value. The 226 "last-hop-behavior" configuration dictates the PHP behavior: 227 "explicit-null", "php", or "non-php". 229 o SRGB (Segment Routing Global Block): Defines a list of label 230 blocks represented by a pair of lower-bound/upper-bound labels. 231 The SRGB is also agnostic to the control plane used. So all 232 routing-protocol instance will have to advertise the same SRGB. 234 4. IGP Control plane configuration 236 Support of segment-routing extensions for a particular IGP control 237 plane is done by augmenting routing-protocol configuration with 238 segment-routing extensions. This augmentation SHOULD be part of 239 separate YANG modules in order to not create any dependency for 240 implementations to support all protocol extensions. 242 This module defines groupings that SHOULD be used by IGP segment 243 routing modules. 245 The "controlplane-cfg" grouping defines the generic global 246 configuration for the IGP. 248 The "enabled" leaf enables segment-routing extensions for the 249 routing-protocol instance. 251 The "bindings" container controls the routing-protocol instance's 252 advertisement of local bindings and the processing of received 253 bindings. 255 4.1. IGP interface configuration 257 The interface configuration is part of the "igp-interface-cfg" 258 grouping and includes Adjacency SID properties. 260 4.1.1. Adjacency SID properties 262 4.1.1.1. Bundling 264 This section is a first proposal on how to use S-bit in Adj-SID to 265 create bundles. Authors would like to trigger discussion based on 266 this first proposal. 268 In case of parallel IP links between routers, an additional Adjacency 269 SID may be advertised representing more than one adjacency (i.e., a 270 bundle of adjacencies). The "advertise-adj-group-sid" configuration 271 controls whether or not an additional adjacency SID is advertised. 273 The "advertise-adj-group-sid" would be a list of "group-id". The 274 "group-id" will permit to identify interfaces that must be bundled 275 together. 277 +-------+ +------+ 278 | | ------- L1 ---- | | 279 | R1 | ------- L2 ---- | R2 | 280 | | ------- L3 ---- | | 281 | | ------- L4 ---- | | 282 +-------+ +------+ 284 In the figure above, R1 and R2 are interconnected by four links. A 285 routing protocol adjacency is established on each link. Operator 286 would like to create segment-routing Adj-SID that represent some 287 bundles of links. We can imagine two different bundles : L1/L2 and 288 L2/L3. To achieve this behavior, the service provider will configure 289 a "group-id" X for both interfaces L1 and L2 and a "group-id" Y for 290 both interfaces L3 and L3. This will result in R1 advertising an 291 additional Adj-SID for each adjacency, for example a Adj-SID with S 292 flag set and value of 400 will be added to L1 and L2. A Adj-SID with 293 S flag set and value of 500 will be added to L3 and L4. As L1/L2 and 294 L3/L4 does not share the same "group-id", a different SID value will 295 be allocated. 297 4.1.1.2. Protection 299 The "advertise-protection" defines how protection for an interface is 300 advertised. It does not control the activation or deactivation of 301 protection. If the "single" option is used, a single Adj-SID will be 302 advertised for the interface. If the interface is protected, the 303 B-Flag for the Adj-SID advertisement will be set. If the "dual" 304 option is used and if the interface is protected, two Adj-SIDs will 305 be advertised for the interface adjacencies. One Adj-SID will always 306 have the B-Flag set and the other will have the B-Flag clear. This 307 option is intended to be used in the case of traffic engineering 308 where a path must use either protected segments or non-protected 309 segments. 311 5. States 313 The operational states contains information reflecting the usage of 314 allocated SRGB labels. 316 It also includes a list of all global SIDs, their associated 317 bindings, and other information such as the source protocol and 318 algorithm. 320 6. Notifications 322 The model proposes two notifications for segment-routing. 324 o segment-routing-global-sid-collision: Raised when a control plane 325 advertised index is already associated with another target (in 326 this version, the only defined targets are IPv4 and IPv6 327 prefixes). 329 o segment-routing-index-out-of-range: Raised when a control plane 330 advertised index fall outside the range of SRGBs configured for 331 the network device. 333 7. YANG Module 335 file "ietf-segment-routing@2015-10-17.yang" 337 module ietf-segment-routing { 338 namespace "urn:ietf:params:xml:ns:" 339 + "yang:ietf-segment-routing"; 340 prefix sr; 342 import ietf-inet-types { 343 prefix "inet"; 344 } 346 import ietf-routing { 347 prefix "rt"; 348 } 350 organization 351 "IETF SPRING Working Group"; 353 contact 354 "WG List: 356 Editor: Stephane Litkowski 357 359 Author: Acee Lindem 360 361 Author: Yingzhen Qu 362 363 Author: Pushpasis Sarkar 364 365 Author: Ing-Wher Chen 366 367 Author: Jeff Tantsura 368 370 "; 372 description 373 "The YANG module defines a generic configuration model for 374 Segment routing common across all of the vendor 375 implementations."; 377 revision 2015-10-17 { 378 description " 379 * Add per-protocol SRGB config feature 380 * Move SRBG config to a grouping 381 "; 382 reference 383 "RFC XXXX: YANG Data Model for Segment Routing."; 384 } 385 revision 2015-06-22 { 386 description " 387 * Prefix SID config moved to 388 connected-prefix-sid-map in global SR cfg 389 rather than IGP. 390 "; 391 reference "draft-litkowski-spring-sr-yang-01"; 392 } 393 revision 2015-04-23 { 394 description " 395 * Node flag deprecated from prefixSID 396 * SR interface cfg moved to protocol 397 * Adding multiple binding policies for SRMS 398 "; 399 reference ""; 400 } 401 revision 2015-02-27 { 402 description "Initial"; 403 reference "draft-litkowski-spring-sr-yang-00"; 404 } 406 /* Identities */ 407 identity segment-routing-transport { 408 description 409 "Base identity for segment routing transport."; 410 } 411 identity segment-routing-transport-mpls { 412 base segment-routing-transport; 413 description 414 "This identity represents MPLS transport for segment 415 routing."; 416 } 418 /* Features */ 419 feature mapping-server { 420 description 421 "Support of SRMS."; 422 } 424 feature sid-last-hop-behavior { 425 description 426 "Configurable last hop behavior."; 427 } 429 feature protocol-srgb { 430 description 431 "Support per-protocol srgb configuration."; 432 } 434 /* Groupings */ 436 grouping srgb-cfg { 437 list srgb { 438 key "lower-bound upper-bound"; 439 ordered-by user; 440 leaf lower-bound { 441 type uint32; 442 description 443 "Lower value in the block."; 444 } 445 leaf upper-bound { 446 type uint32; 447 description 448 "Upper value in the block."; 449 } 450 description 451 "List of global blocks to be 452 advertised."; 453 } 454 description 455 "Grouping for SRGB configuration."; 456 } 458 grouping controlplane-cfg { 459 container segment-routing { 460 leaf enabled { 461 type boolean; 462 default false; 463 description 464 "Enables segment-routing 465 protocol extensions."; 466 } 467 container bindings { 468 container advertise { 469 leaf-list policies { 470 type string; 471 description 472 "List of policies to be advertised."; 473 } 474 description 475 "Authorize the advertise 476 of local mappings in binding TLV."; 477 } 478 leaf receive { 479 type boolean; 480 default true; 481 description 482 "Authorize the reception and usage 483 of binding TLV."; 484 } 485 description 486 "Control of binding advertisement 487 and reception."; 488 } 490 description 491 "segment routing global config."; 492 } 493 description 494 "Defines protocol configuration."; 495 } 497 grouping sid-value-type { 498 leaf value-type { 499 type enumeration { 500 enum index { 501 description 502 "The value will be 503 interpreted as an index."; 504 } 505 enum absolute { 506 description 507 "The value will become 508 interpreted as an absolute 509 value."; 510 } 511 } 512 default index; 513 description 514 "This leaf defines how value 515 must be interpreted."; 516 } 517 description 518 "Defines how the SID value is expressed."; 519 } 521 grouping ipv4-sid-cfg { 523 leaf prefix { 524 type inet:ipv4-prefix; 525 description 526 "connected prefix sid."; 527 } 529 uses sid-value-type; 531 leaf start-sid { 532 type uint32; 533 mandatory true; 534 description 535 "Value associated with 536 prefix. The value must 537 be interpreted in the 538 context of value-type."; 539 } 541 leaf range { 542 type uint32; 543 description 544 "Describes how many SIDs could be 545 allocated."; 546 } 547 description 548 "This grouping defines cfg of prefix SID."; 549 } 551 grouping ipv6-sid-cfg { 552 leaf prefix { 553 type inet:ipv6-prefix; 554 description 555 "connected prefix sid."; 556 } 558 uses sid-value-type; 560 leaf start-sid { 561 type uint32; 562 mandatory true; 563 description 564 "Value associated with 565 prefix. The value must 566 be interpreted in the 567 context of value-type."; 568 } 570 leaf range { 571 type uint32; 572 description 573 "Describes how many SIDs could be 574 allocated."; 575 } 577 description 578 "This grouping defines cfg of prefix SID."; 579 } 581 grouping last-hop-behavior { 582 leaf last-hop-behavior { 583 if-feature sid-last-hop-behavior; 584 type enumeration { 585 enum explicit-null { 586 description 587 "Use explicit-null for the SID."; 588 } 589 enum no-php { 590 description 591 "Do no use PHP for the SID."; 592 } 593 enum php { 594 description 595 "Use PHP for the SID."; 596 } 597 } 598 description 599 "Configure last hop behavior."; 600 } 601 description 602 "Defines last hop behavior"; 603 } 605 grouping igp-interface-cfg { 606 container segment-routing { 608 container adjacency-sid { 609 list advertise-adj-group-sid { 610 key group-id; 611 leaf group-id { 612 type uint32; 613 description 615 "The value is an internal value to identify 616 a group-ID. Interfaces with the same 617 group-ID will be bundled together. 618 "; 619 } 620 description 621 "Control advertisement of S flag. 622 Enable to advertise a common Adj-SID 623 for parallel links."; 624 } 625 leaf advertise-protection { 626 type enumeration { 627 enum "single" { 628 description 629 "A single Adj-SID is associated 630 with the adjacency and reflects 631 the protection configuration."; 632 } 633 enum "dual" { 634 description 635 "Two Adj-SIDs will be associated 636 with the adjacency if interface 637 is protected. In this case 638 one will be enforced with 639 backup flag set, the other 640 will be enforced to backup flag unset. 641 In case, protection is not configured, 642 a single Adj-SID will be advertised 643 with backup flag unset."; 644 } 645 } 646 description 647 "If set, the Adj-SID refers to an 648 adjacency being protected."; 649 } 650 description 651 "Defines the adjacency SID properties."; 652 } 653 description 654 "container for SR interface cfg."; 655 } 656 description 657 "Grouping for IGP interface cfg."; 658 } 659 /* Cfg */ 661 augment "/rt:routing/rt:routing-instance" { 662 description 663 "This augments routing-instance 664 configuration with segment-routing."; 665 container segment-routing { 666 leaf transport-type { 667 type identityref { 668 base segment-routing-transport; 669 } 670 default "segment-routing-transport-mpls"; 671 description "Dataplane to be used."; 672 } 673 container bindings { 674 container mapping-server { 675 if-feature mapping-server; 676 list policy { 677 key name; 678 leaf name { 679 type string; 680 description 681 "Name of the mapping policy."; 682 } 683 container ipv4 { 684 list mapping-entry { 685 key prefix; 686 uses ipv4-sid-cfg; 688 description 689 "Mapping entries."; 690 } 691 description 692 "IPv4 mapping entries."; 693 } 694 container ipv6 { 695 list mapping-entry { 696 key prefix; 697 uses ipv6-sid-cfg; 698 description 699 "Mapping entries."; 700 } 701 description 702 "IPv6 mapping entries."; 703 } 704 description 705 "Definition of mapping policy."; 706 } 707 description 708 "Configuration of mapping-server 709 local entries."; 710 } 711 container connected-prefix-sid-map { 712 container ipv4 { 713 list ipv4-prefix-sid { 714 key prefix; 715 uses ipv4-sid-cfg; 716 uses last-hop-behavior; 717 description 718 "List of prefix SID 719 mapped to IPv4 local prefixes."; 720 } 721 description 722 "Parameters associated with IPv4 prefix SID"; 723 } 724 container ipv6 { 725 list ipv6-prefix-sid { 726 key prefix; 727 uses ipv6-sid-cfg; 728 uses last-hop-behavior; 729 description 730 "List of prefix SID 731 mapped to IPv6 local prefixes."; 732 } 733 description 734 "Parameters associated with IPv6 prefix SID"; 735 } 736 description 737 "Prefix SID configuration."; 738 } 739 description 740 "List of bindings."; 741 } 742 container global-srgb { 743 uses srgb-cfg; 744 description 745 "Global SRGB configuration."; 746 } 747 description 748 "segment routing global config."; 749 } 750 } 752 /* Operational states */ 753 augment "/rt:routing-state/rt:routing-instance" { 754 description 755 "This augments the operational states 756 with segment-routing."; 757 container segment-routing { 758 container node-capabilities { 759 list transport-planes { 760 key transport-plane; 761 leaf transport-plane { 762 type identityref { 763 base segment-routing-transport; 764 } 765 description 766 "Transport plane supported"; 767 } 768 description 769 "List of supported transport planes."; 770 } 771 leaf segment-stack-push-limit { 772 type uint8; 773 description 774 "Describes the number of segments 775 that can be pushed by the node."; 776 } 777 leaf readable-label-stack-depth { 778 type uint8; 779 description 780 "Number of MPLS labels that 781 can be read in the stack."; 782 } 783 description 784 "Shows the SR capability of the node."; 785 } 786 list label-blocks { 787 leaf lower-bound { 788 type uint32; 789 description 790 "Lower bound of the label block."; 791 } 792 leaf upper-bound { 793 type uint32; 794 description 795 "Upper bound of the label block."; 796 } 797 leaf size { 798 type uint32; 799 description 800 "Number of indexes in the block."; 802 } 803 leaf free { 804 type uint32; 805 description 806 "Number of indexes free in the block."; 807 } 808 leaf used { 809 type uint32; 810 description 811 "Number of indexes used in the block."; 812 } 813 description 814 "List of labels blocks currently 815 in use."; 816 } 818 container global-sid-list { 819 list sid { 820 key "target sid source source-protocol binding-type"; 821 ordered-by system; 822 leaf target { 823 type string; 824 description 825 "Defines the target of the binding. 826 It can be a prefix or something else."; 827 } 828 leaf sid { 829 type uint32; 830 description 831 "Index associated with the prefix."; 832 } 833 leaf algorithm { 834 type uint8; 835 description 836 "Algorithm to be used for the prefix 837 SID."; 838 } 839 leaf source { 840 type inet:ip-address; 841 description 842 "IP address of the router than own 843 the binding."; 844 } 845 leaf used { 846 type boolean; 847 description 848 "Defines if the binding is used 849 in forwarding plane."; 851 } 852 leaf source-protocol { 853 type leafref { 854 path "/rt:routing-state/rt:routing-instance/" + 855 "rt:routing-protocols/rt:routing-protocol/rt:name"; 856 } 857 description 858 "Rtg protocol that owns the binding"; 859 } 860 leaf binding-type { 861 type enumeration { 862 enum prefix-sid { 863 description 864 "Binding is learned from 865 a prefix SID."; 866 } 867 enum binding-tlv { 868 description 869 "Binding is learned from 870 a binding TLV."; 871 } 872 } 873 description 874 "Type of binding."; 875 } 876 description 877 "Binding."; 879 } 880 description 881 "List of prefix and SID associations."; 882 } 883 description 884 "Segment routing operational states."; 885 } 886 } 888 /* Notifications */ 890 notification segment-routing-global-sid-collision { 891 leaf received-target { 892 type string; 893 description 894 "Target received in the controlplane that 895 caused SID collision."; 896 } 897 leaf original-target { 898 type string; 899 description 900 "Target already available in database that have the same SID 901 as the received target."; 902 } 903 leaf index { 904 type uint32; 905 description 906 "Value of the index used by two different prefixes."; 907 } 908 leaf routing-protocol { 909 type leafref { 910 path "/rt:routing-state/rt:routing-instance/" + 911 "rt:routing-protocols/rt:routing-protocol/rt:name"; 912 } 913 description 914 "Routing protocol reference that received the event."; 915 } 916 description 917 "This notification is sent when a new mapping is learned 918 , containing mapping 919 where the SID is already used. 920 The notification generation must be throttled with at least 921 a 5 second gap. "; 922 } 923 notification segment-routing-index-out-of-range { 924 leaf received-target { 925 type string; 926 description 927 "Target received in the controlplane 928 that caused SID collision."; 929 } 930 leaf received-index { 931 type uint32; 932 description 933 "Value of the index received."; 934 } 935 leaf routing-protocol { 936 type leafref { 937 path "/rt:routing-state/rt:routing-instance/" + 938 "rt:routing-protocols/rt:routing-protocol/rt:name"; 939 } 940 description 941 "Routing protocol reference that received the event."; 942 } 943 description 944 "This notification is sent when a binding 945 is received, containing a segment index 946 which is out of the local configured ranges. 947 The notification generation must be throttled with at least 948 a 5 second gap. "; 949 } 950 } 951 953 8. Security Considerations 955 TBD. 957 9. Acknowledgements 959 Authors would like to thank Derek Yeung, Acee Lindem, Greg Hankins, 960 Hannes Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge for their 961 contributions. 963 10. IANA Considerations 965 TBD. 967 11. Normative References 969 [I-D.ietf-spring-segment-routing] 970 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 971 and R. Shakir, "Segment Routing Architecture", draft-ietf- 972 spring-segment-routing-03 (work in progress), May 2015. 974 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 975 Requirement Levels", BCP 14, RFC 2119, March 1997. 977 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 978 Network Configuration Protocol (NETCONF)", RFC 6020, 979 October 2010. 981 Authors' Addresses 983 Stephane Litkowski 984 Orange Business Service 986 Email: stephane.litkowski@orange.com 988 Yingzhen Qu 989 Cisco Systems 991 Email: yiqu@cisco.com 992 Pushpasis Sarkar 993 Juniper Networks 995 Email: psarkar@juniper.net 997 Jeff Tantsura 998 Ericsson 1000 Email: jeff.tantsura@ericsson.com