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