idnits 2.17.1 draft-litkowski-spring-sr-yang-00.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 33 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 131 has weird spacing: '...r-bound uin...' == Line 132 has weird spacing: '...r-bound uin...' == Line 138 has weird spacing: '...roup-id uin...' == Line 180 has weird spacing: '...rotocol lea...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 05, 2015) is 3337 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 928, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 949, but no explicit reference was found in the text == Unused Reference: 'RFC6242' is defined on line 953, but no explicit reference was found in the text == Unused Reference: 'RFC6536' is defined on line 956, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-03 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-04 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-01 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 14 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 A. Lindem 5 Expires: September 6, 2015 Cisco Systems 6 P. Sarkar 7 Juniper Networks 8 I. Chen 9 Ericsson 10 March 05, 2015 12 YANG Data Model for Segment Routing 13 draft-litkowski-spring-sr-yang-00 15 Abstract 17 This document defines a YANG data model for segment routing 18 configuration and operation. This YANG model is intended to be used 19 on network elements to configure or operate segment routing. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 6, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 64 3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Adjacency SID properties . . . . . . . . . . . . . . . . 5 66 3.1.1. Bundling . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1.2. Protection . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Prefix SID properties . . . . . . . . . . . . . . . . . . 6 69 4. Control plane configuration . . . . . . . . . . . . . . . . . 7 70 5. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 76 11. Normative References . . . . . . . . . . . . . . . . . . . . 20 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 79 1. Introduction 81 This document defines a YANG data model for segment routing 82 configuration and operation. 84 1.1. Tree diagram 86 A simplified graphical representation of the data model is presented 87 in Section 2. 89 The meaning of the symbols in these diagrams is as follows: 91 o Brackets "[" and "]" enclose list keys. 93 o Curly braces "{" and "}" contain names of optional features that 94 make the corresponding node conditional. 96 o Abbreviations before data node names: "rw" means configuration 97 (read-write), and "ro" state data (read-only). 99 o Symbols after data node names: "?" means an optional node and "*" 100 denotes a "list" or "leaf-list". 102 o Parentheses enclose choice and case nodes, and case nodes are also 103 marked with a colon (":"). 105 o Ellipsis ("...") stands for contents of subtrees that are not 106 shown. 108 2. Design of the Data Model 110 This is the initial version of this module and and its relationship 111 to the protocol modules. It is expected that there will be changes 112 as the module matures. 114 module: ietf-segment-routing 115 augment /rt:routing/rt:routing-instance: 116 +--rw segment-routing 117 +--rw transport-type? identityref 118 +--rw bindings 119 | +--rw mapping-server {mapping-server}? 120 | +--rw ipv4 121 | | +--rw mapping-entry* [prefix] 122 | | +--rw prefix inet:ipv4-prefix 123 | | +--rw start-sid? uint32 124 | | +--rw range? uint32 125 | +--rw ipv6 126 | +--rw mapping-entry* [prefix] 127 | +--rw prefix inet:ipv6-prefix 128 | +--rw start-sid? uint32 129 | +--rw range? uint32 130 +--rw srgb* [lower-bound upper-bound] 131 | +--rw lower-bound uint32 132 | +--rw upper-bound uint32 133 +--rw interfaces 134 +--rw interface* [name] 135 +--rw name if:interface-ref 136 +--rw adjacency-sid 137 | +--rw advertise-adj-group-sid* [group-id] 138 | | +--rw group-id uint32 139 | +--rw advertise-protection? enumeration 140 +--rw prefix-sid 141 +--rw ipv4 142 | +--rw prefix-sid* [value] 143 | +--rw value-type? enumeration 144 | +--rw value uint32 145 | +--rw node-flag? boolean 146 | +--rw last-hop-behavior? enumeration 147 +--rw ipv6 148 +--rw prefix-sid* [value] 149 +--rw value-type? enumeration 150 +--rw value uint32 151 +--rw node-flag? boolean 152 +--rw last-hop-behavior? enumeration 153 augment /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol/isis:isis/isis:instance: 154 +--rw segment-routing 155 +--rw enabled? boolean 156 +--rw bindings 157 +--rw advertise? boolean 158 +--rw receive? boolean 159 augment /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol/ospf:ospf/ospf:instance: 160 +--rw segment-routing 161 +--rw enabled? boolean 162 +--rw bindings 163 +--rw advertise? boolean 164 +--rw receive? boolean 165 augment /rt:routing-state/rt:routing-instance: 166 +--ro segment-routing 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 how external information is mapped to a segment 213 ID. The current version supports a mapping-server where static 214 prefix-to-SID bindings can be defined. Configuration of bindings 215 does not allow advertisement of those bindings. Advertisement 216 must be controlled by each routing-protocol instance. 218 o SRGB (Segment Routing Global Block): Defines a list of label 219 blocks represented by a pair of lower-bound/upper-bound labels. 220 The SRGB is also agnostic to the control plane used. So all 221 routing-protocol instance will have to advertise the same SRGB. 223 The interface configuration includes : 225 o Adjacency SID properties 227 o Prefix SID properties 229 3.1. Adjacency SID properties 231 3.1.1. Bundling 233 This section is a first proposal on how to use S-bit in Adj-SID to 234 create bundles. Authors would like to trigger discussion based on 235 this first proposal. 237 In case of parallel IP links between routers, an additional Adjacency 238 SID may be advertised representing more than one adjacency (i.e., a 239 bundle of adjacencies). The "advertise-adj-group-sid" configuration 240 controls whether or not an additional adjacency SID is advertised. 242 The "advertise-adj-group-sid" would be a list of "group-id". The 243 "group-id" will permit to identify interfaces that must be bundled 244 together. 246 +-------+ +------+ 247 | | ------- L1 ---- | | 248 | R1 | ------- L2 ---- | R2 | 249 | | ------- L3 ---- | | 250 | | ------- L4 ---- | | 251 +-------+ +------+ 253 In the figure above, R1 and R2 are interconnected by four links. A 254 routing protocol adjacency is established on each link. Operator 255 would like to create segment-routing Adj-SID that represent some 256 bundles of links. We can imagine two different bundles : L1/L2 and 257 L2/L3. To achieve this behavior, the service provider will configure 258 a "group-id" X for both interfaces L1 and L2 and a "group-id" Y for 259 both interfaces L3 and L3. This will result in R1 advertising an 260 additional Adj-SID for each adjacency, for example a Adj-SID with S 261 flag set and value of 400 will be added to L1 and L2. A Adj-SID with 262 S flag set and value of 500 will be added to L3 and L4. As L1/L2 and 263 L3/L4 does not share the same "group-id", a different SID value will 264 be allocated. 266 3.1.2. Protection 268 The "advertise-protection" defines how protection for an interface is 269 advertised. It does not control the activation or deactivation of 270 protection. If the "single" option is used, a single Adj-SID will be 271 advertised for the interface. If the interface is protected, the 272 B-Flag for the Adj-SID advertisement will be set. If the "dual" 273 option is used and if the interface is protected, two Adj-SIDs will 274 be advertised for the interface adjacencies. One Adj-SID will always 275 have the B-Flag set and the other will have the B-Flag clear. This 276 option is intended to be used in the case of traffic engineering 277 where a path must use either protected segments or non-protected 278 segments. 280 3.2. Prefix SID properties 282 An interface may have associated IP prefixes. By default, no Prefix- 283 SID will be advertised for any IP prefix associated with an 284 interface. 286 The operator can control the advertisement of IP prefixes by setting 287 "prefix-sid" in the interface configuration. 289 The operator can control advertisement of Prefix-SID independently 290 for IPv4 and IPv6. When specified, the "prefix-sid" value must be 291 included. 293 The value can be expressed as an index (default), or an absolute 294 value. The operator can also control if the "node-flag" is set for 295 the prefix. As the network device owns the prefix, the default is to 296 advertise the prefix with the "node-flag" set. 298 The "last-hop-behavior" configuration dictates the PHP behavior: 299 "explicit-null", "php", or "non-php". 301 4. Control plane configuration 303 Activation of segment-routing extensions for a particular control 304 plane is done by augmenting routing-protocol configuration with 305 segment-routing. 307 The "enabled" leaf enables segment-routing extensions for the 308 routing-protocol instance. 310 The "bindings" container controls the routing-protocol instance's 311 advertisement of local bindings and the processing of received 312 bindings. 314 This model supports ISIS ([I-D.ietf-isis-segment-routing-extensions]) 315 and OSPF as controlplane ([I-D.ietf-ospf-segment-routing-extensions] 316 and [I-D.psenak-ospf-segment-routing-ospfv3-extension]) for segment- 317 routing. 319 5. States 321 The operational states contains information reflecting the usage of 322 allocated SRGB labels. 324 It also includes a list of all global SIDs, their associated 325 bindings, and other information such as the source protocol and 326 algorithm. 328 6. Notifications 330 The model proposes two notifications for segment-routing. 332 o segment-routing-global-sid-collision: Raised when a control plane 333 advertised index is already associated with another target (in 334 this version, the only defined targets are IPv4 and IPv6 335 prefixes). 337 o segment-routing-index-out-of-range: Raised when a control plane 338 advertised index fall outside the range of SRGBs configured for 339 the network device. 341 7. YANG Module 343 file "ietf-segment-routing@2015-03-04.yang" 345 module ietf-segment-routing { 346 namespace "urn:ietf:params:xml:ns:" 347 + "yang:ietf-segment-routing"; 348 prefix sr; 350 import ietf-inet-types { 351 prefix "inet"; 352 } 354 import ietf-routing { 355 prefix "rt"; 356 } 358 import ietf-interfaces { 359 prefix "if"; 360 } 362 import ietf-isis { 363 prefix "isis"; 364 } 366 import ospf { 367 prefix "ospf"; 368 } 370 organization 371 "IETF SPRING Working Group"; 373 contact 374 "WG List: <mailto:spring@ietf.org> 376 Editor: Stephane Litkowski 377 <mailto:stephane.litkowski@orange.com> 379 Acee Lindem 380 <mailto:acee@cisco.com> 381 Pushpasis Sarkar 382 <mailto:psarkar@juniper.net> 383 Ing-Wher Chen 384 <mailto:ing-wher.chen@ericsson.com> 386 "; 388 description 389 "The YANG module defines a generic configuration model for 390 Segment routing common across all of the vendor 391 implementations."; 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 /* Groupings */ 419 grouping controlplane-cfg { 420 container segment-routing { 421 leaf enabled { 422 type boolean; 423 default false; 424 description 425 "Enables segment-routing 426 protocol extensions."; 427 } 428 container bindings { 429 leaf advertise { 430 type boolean; 431 default true; 432 description 433 "Authorize the advertise 434 of local mappings in binding TLV."; 435 } 436 leaf receive { 437 type boolean; 438 default true; 439 description 440 "Authorize the reception and usage 441 of binding TLV."; 442 } 443 description 444 "Control of binding advertisement 445 and reception."; 446 } 448 description 449 "segment routing global config."; 450 } 451 description 452 "Defines protocol configuration."; 453 } 455 grouping prefix-sid-cfg { 456 list prefix-sid { 457 key value; 458 leaf value-type { 459 type enumeration { 460 enum index { 461 description 462 "The value will be 463 interpreted as an index."; 465 } 466 enum absolute { 468 description 469 "The value will become 470 interpreted as an absolute 471 value."; 472 } 473 } 474 default index; 475 description 476 "This leaf defines how value 477 must be interpreted."; 478 } 480 leaf value { 481 type uint32; 482 mandatory true; 483 description 484 "Value associated with 485 prefix. The value must 486 be interpreted in the 487 context of value-type."; 488 } 489 leaf node-flag { 490 type boolean; 491 default true; 492 description 493 "Set prefix as a node 494 representative prefix."; 495 } 496 leaf last-hop-behavior { 497 type enumeration { 498 enum explicit-null { 499 description 500 "Use explicit-null for the SID."; 501 } 502 enum no-php { 503 description 504 "Do no use PHP for the SID."; 505 } 506 enum php { 507 description 508 "Use PHP for the SID."; 509 } 510 } 511 description 512 "Configure last hop behavior."; 513 } 514 description 515 "List of prefix SID."; 516 } 517 description 518 "This grouping defines cfg of prefix SID."; 519 } 521 /* Cfg */ 523 augment "/rt:routing/rt:routing-instance" { 524 description 525 "This augments routing-instance 526 configuration with segment-routing."; 527 container segment-routing { 528 leaf transport-type { 529 type identityref { 530 base segment-routing-transport; 531 } 532 default "segment-routing-transport-mpls"; 533 description "Dataplane to be used."; 534 } 535 container bindings { 536 container mapping-server { 537 if-feature mapping-server; 538 container ipv4 { 539 list mapping-entry { 540 key prefix; 542 leaf prefix { 543 type inet:ipv4-prefix; 544 description 545 "Base prefix used for mapping."; 546 } 547 leaf start-sid { 548 type uint32; 549 description 550 "Starting SID value to be associated 551 with prefix."; 552 } 553 leaf range { 554 type uint32; 555 description 556 "Describes how many SIDs could be 557 allocated."; 558 } 559 description 560 "Mapping entries."; 561 } 562 description 563 "IPv4 mapping entries."; 564 } 565 container ipv6 { 566 list mapping-entry { 567 key prefix; 569 leaf prefix { 570 type inet:ipv6-prefix; 571 description 572 "Base prefix used for mapping."; 573 } 574 leaf start-sid { 575 type uint32; 576 description 577 "Starting SID value to be associated 578 with prefix."; 579 } 580 leaf range { 581 type uint32; 582 description 583 "Describes how many SIDs could be 584 allocated."; 585 } 586 description 587 "Mapping entries."; 588 } 589 description 590 "IPv6 mapping entries."; 591 } 592 description 593 "Configuration of mapping-server 594 local entries."; 595 } 596 description 597 "List of bindings."; 598 } 599 list srgb { 600 key "lower-bound upper-bound"; 601 ordered-by user; 602 leaf lower-bound { 603 type uint32; 604 description 605 "Lower value in the block."; 606 } 607 leaf upper-bound { 608 type uint32; 609 description 610 "Upper value in the block."; 611 } 612 description 613 "List of global blocks to be 614 advertised."; 615 } 617 container interfaces { 618 list interface { 619 key "name"; 620 leaf name { 621 type if:interface-ref; 623 description 624 "Reference to the interface within 625 the routing-instance."; 627 } 628 container adjacency-sid { 629 list advertise-adj-group-sid { 630 key group-id; 632 leaf group-id { 633 type uint32; 634 description 636 "The value is an internal value to identify 637 a group-ID. Interfaces with the same 638 group-ID will be bundled together. 639 "; 640 } 641 description 642 "Control advertisement of S flag. 643 Enable to advertise a common Adj-SID 644 for parallel links."; 645 } 646 leaf advertise-protection { 647 type enumeration { 648 enum "single" { 649 description 650 "A single Adj-SID is associated 651 with the adjacency and reflects 652 the protection configuration."; 653 } 654 enum "dual" { 655 description 656 "Two Adj-SIDs will be associated 657 with the adjacency if interface 658 is protected. In this case 659 one will be enforced with 660 backup flag set, the other 661 will be enforced to backup flag unset. 662 In case, protection is not configured, 663 a single Adj-SID will be advertised 664 with backup flag unset."; 665 } 666 } 667 description 668 "If set, the Adj-SID refers to an 669 adjacency being protected."; 670 } 671 description 672 "Defines the adjacency SID properties."; 673 } 674 container prefix-sid { 675 container ipv4 { 676 uses prefix-sid-cfg; 677 description 678 "Parameters associated with IPv4 prefix SID"; 679 } 680 container ipv6 { 681 uses prefix-sid-cfg; 682 description 683 "Parameters associated with IPv6 prefix SID"; 684 } 685 description 686 "Prefix SID configuration."; 687 } 688 description 689 "List of interfaces."; 690 } 691 description 692 "Interface configuration."; 693 } 694 description 695 "segment routing global config."; 696 } 697 } 699 augment "/rt:routing/rt:routing-instance/" + 700 "rt:routing-protocols/rt:routing-protocol"+ 701 "/isis:isis/isis:instance" { 702 when "rt:type = 'isis:isis'" { 703 description 704 "This augment ISIS routing protocol when used"; 705 } 706 description 707 "This augments ISIS protocol configuration 708 with segment routing."; 710 uses controlplane-cfg; 711 } 713 augment "/rt:routing/rt:routing-instance/rt:routing-protocols" + 714 "/rt:routing-protocol/ospf:ospf/ospf:instance" { 715 when "rt:type = 'ospf:ospfv2' or rt:type = 'ospf:ospfv3'" { 716 description 717 "This augment ISIS routing protocol when used"; 718 } 719 description 720 "This augments ISIS protocol configuration 721 with segment routing."; 723 uses controlplane-cfg; 724 } 726 /* Operational states */ 728 augment "/rt:routing-state/rt:routing-instance" { 729 description 730 "This augments the operational states 731 with segment-routing."; 732 container segment-routing { 733 list label-blocks { 734 leaf lower-bound { 735 type uint32; 736 description 737 "Lower bound of the label block."; 738 } 739 leaf upper-bound { 740 type uint32; 741 description 742 "Upper bound of the label block."; 743 } 744 leaf size { 745 type uint32; 746 description 747 "Number of indexes in the block."; 748 } 749 leaf free { 750 type uint32; 751 description 752 "Number of indexes free in the block."; 753 } 754 leaf used { 755 type uint32; 756 description 757 "Number of indexes used in the block."; 758 } 759 description 760 "List of labels blocks currently 761 in use."; 762 } 764 container global-sid-list { 765 list sid { 766 key "target sid source source-protocol binding-type"; 767 ordered-by system; 769 leaf target { 770 type string; 771 description 772 "Defines the target of the binding. 773 It can be a prefix or something else."; 774 } 775 leaf sid { 776 type uint32; 777 description 778 "Index associated with the prefix."; 779 } 780 leaf algorithm { 781 type uint8; 782 description 783 "Algorithm to be used for the prefix 784 SID."; 785 } 786 leaf source { 787 type inet:ip-address; 788 description 789 "IP address of the router than own 790 the binding."; 791 } 792 leaf used { 793 type boolean; 794 description 795 "Defines if the binding is used 796 in forwarding plane."; 797 } 798 leaf source-protocol { 799 type leafref { 800 path "/rt:routing-state/rt:routing-instance/" + 801 "rt:routing-protocols/rt:routing-protocol/rt:name"; 802 } 803 description 804 "Rtg protocol that owns the binding"; 805 } 806 leaf binding-type { 807 type enumeration { 808 enum prefix-sid { 809 description 810 "Binding is learned from 811 a prefix SID."; 812 } 813 enum binding-tlv { 814 description 815 "Binding is learned from 816 a binding TLV."; 817 } 819 } 820 description 821 "Type of binding."; 822 } 823 description 824 "Binding."; 826 } 827 description 828 "List of prefix and SID associations."; 829 } 830 description 831 "Segment routing operational states."; 832 } 833 } 835 /* Notifications */ 837 notification segment-routing-global-sid-collision { 838 leaf received-target { 839 type string; 840 description 841 "Target received in the controlplane that 842 caused SID collision."; 843 } 844 leaf original-target { 845 type string; 846 description 847 "Target already available in database that have the same SID 848 as the received target."; 849 } 850 leaf index { 851 type uint32; 852 description 853 "Value of the index used by two different prefixes."; 854 } 855 leaf routing-protocol { 856 type leafref { 857 path "/rt:routing-state/rt:routing-instance/" + 858 "rt:routing-protocols/rt:routing-protocol/rt:name"; 859 } 860 description 861 "Routing protocol reference that received the event."; 862 } 863 description 864 "This notification is sent when a new mapping is learned 865 , containing mapping 866 where the SID is already used. 867 The notification generation must be throttled with at least 868 a 5 second gap. "; 869 } 870 notification segment-routing-index-out-of-range { 871 leaf received-target { 872 type string; 873 description 874 "Target received in the controlplane 875 that caused SID collision."; 876 } 877 leaf received-index { 878 type uint32; 879 description 880 "Value of the index received."; 881 } 882 leaf routing-protocol { 883 type leafref { 884 path "/rt:routing-state/rt:routing-instance/" + 885 "rt:routing-protocols/rt:routing-protocol/rt:name"; 886 } 887 description 888 "Routing protocol reference that received the event."; 889 } 890 description 891 "This notification is sent when a binding 892 is received, containing a segment index 893 which is out of the local configured ranges. 894 The notification generation must be throttled with at least 895 a 5 second gap. "; 896 } 898 } 900 902 8. Security Considerations 904 TBD. 906 9. Acknowledgements 908 TBD. 910 10. IANA Considerations 912 TBD. 914 11. Normative References 916 [I-D.ietf-isis-segment-routing-extensions] 917 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 918 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 919 Extensions for Segment Routing", draft-ietf-isis-segment- 920 routing-extensions-03 (work in progress), October 2014. 922 [I-D.ietf-ospf-segment-routing-extensions] 923 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 924 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 925 Extensions for Segment Routing", draft-ietf-ospf-segment- 926 routing-extensions-04 (work in progress), February 2015. 928 [I-D.ietf-spring-segment-routing] 929 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 930 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 931 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 932 spring-segment-routing-01 (work in progress), February 933 2015. 935 [I-D.psenak-ospf-segment-routing-ospfv3-extension] 936 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 937 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 938 Extensions for Segment Routing", draft-psenak-ospf- 939 segment-routing-ospfv3-extension-02 (work in progress), 940 July 2014. 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", BCP 14, RFC 2119, March 1997. 945 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 946 Network Configuration Protocol (NETCONF)", RFC 6020, 947 October 2010. 949 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 950 Bierman, "Network Configuration Protocol (NETCONF)", RFC 951 6241, June 2011. 953 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 954 Shell (SSH)", RFC 6242, June 2011. 956 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 957 Protocol (NETCONF) Access Control Model", RFC 6536, March 958 2012. 960 Authors' Addresses 962 Stephane Litkowski 963 Orange Business Service 965 Email: stephane.litkowski@orange.com 967 Acee Lindem 968 Cisco Systems 970 Email: acee@cisco.com 972 Pushpasis Sarkar 973 Juniper Networks 975 Email: psarkar@juniper.net 977 Ing-Wher Chen 978 Ericsson 980 Email: ing-wher.chen@ericsson.com