idnits 2.17.1 draft-hb-spring-sr-p2mp-policy-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 4 characters in excess of 72. ** There are 321 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 163 has weird spacing: '...address ine...' == Line 206 has weird spacing: '...ion-sid uin...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2019) is 1639 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) -- Missing reference section? 'RFC2119' on line 152 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working group H. Bidgoli, Ed. 3 Internet Draft Nokia 4 Intended status: Standard Track D. Voyer 5 Bell Canada 6 Tanmoy Kundu 7 J. Kotalwar 8 Nokia 9 R. Parekh 10 Cisco System, Inc. 11 T. Saad 12 Juniper Networks 14 Expires: May 2, 2020 October 30, 2019 16 YANG Data Model for p2mp sr policy 17 draft-hb-spring-sr-p2mp-policy-yang-01 19 Abstract 21 SR P2MP policies are set of policies that enable architecture for 22 P2MP service delivery. 24 A P2MP policy consists of candidate paths that connects the Root of 25 the Tree to a set of Leaves. The P2MP policy is composed of 26 replication segments. A replication segment is a forwarding 27 instruction for a candidate path which is downloaded to the Root, 28 transit nodes and the leaves. 30 This document defines a YANG data model for SR P2MP Policy 31 Configuration and operation. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." The list 47 of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 This Internet-Draft will expire on October 8, 2017. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Conventions used in this document . . . . . . . . . . . . . . . 4 74 3. Design of the Data Model . . . . . . . . . . . . . . . . . . . 4 75 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5. Control plane configuration . . . . . . . . . . . . . . . . . . 6 77 6. States . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 7. Yang Data Model . . . . . . . . . . . . . . . . . . . . . . . . 6 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 17 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 This document defines a YANG data model for P2MP SR Policy 90 configuration and operation. 92 The draft [draft-voyer-spring-sr-p2mp-policy] defines a variant of 93 the SR Policy [I-D. ietf-spring-segment-routing-policy] for 94 constructing a P2MP segment to support multicast service delivery. 96 A Point-to-Multipoint (P2MP) Policy contains a set of candidate paths 97 and identifies a Root node and a set of Leaf nodes in a Segment 98 Routing Domain. The draft also defines a Replication segment, which 99 corresponds to the state of a P2MP segment on a particular node. The 100 Replication segment is the forwarding instruction for a P2MP LSP at 101 the Root, Transit and Leaf nodes. 103 For a P2MP segment, a controller may be used to compute a tree from a 104 Root node to a set of Leaf nodes, optionally via a set of replication 105 nodes. A packet is replicated at the root node and optionally on 106 Replication nodes towards each Leaf node. 108 We define two types of a P2MP segment: Spray and Replication. 110 A Point-to-Multipoint service delivery could be via Ingress 111 Replication (aka Spray in some SR context), i.e., the root unicasts 112 individual copies of traffic to each leaf. The corresponding P2MP 113 segment consists of replication segments only for the root and the 114 leaves. 116 A Point-to-Multipoint service delivery could also be via Downstream 117 Replication (aka TreeSID in some SR context), i.e., the root and some 118 downstream replication nodes replicate the traffic along the way as 119 it traverses closer to the leaves. 121 It should be noted that two replication nodes can be connected 122 directly, or they can be connected via unicast SR segment or a 123 segment list. 125 The leaves and the root of a p2mp policy can be discovered via the 126 NG-MVPN procedures [RFC 6513 and RFC 6514] or manually configured. 128 Base on the discovered root and leaves the controller builds a P2MP 129 policy and advertise it to the head-end router (i.e. the root of the 130 P2MP Tree). In addition, the controller builds the replication 131 segments on each segment of the tree, Root, Transit and Leaf nodes 132 and downloads the forwarding instructions to the nodes. 134 As it was mentioned a SR p2mp policy is a variant of the SR policy 135 and as such it reuses the concept of a candidate path. This draft 136 reuses some of the concepts and TLVs mentioned in [I-D. draft-ietf- 137 idr-segment-routing-te-policy] 139 A candidate path with in the P2MP policy can contain multiple path- 140 instances. A path-instance can be viewed as a P2MP LSP. For candidate 141 path global optimization purposes two or more path-instances can be 142 used to execute make before break procedures. 144 Each path-instance is a P2MP LSP as such each path-instance needs a 145 set of replication segments to construct its forwarding instructions. 147 2. Conventions used in this document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 3. Design of the Data Model 154 submodule: router-p2mp-traffic-engineering (belongs-to root) 155 +--rw p2mp-traffic-engiineering! 156 +--rw p2mp-policy* [root-address tree-id] 157 | +--rw root-address inet:ip-address 158 | +--rw tree-id uint32 159 | +--rw p2mp-policy-name? string 160 | +--rw admin-state? enumeration 161 | +--ro oper-state? enumeration 162 | +--rw leaf-list* [leaf-address] 163 | | +--rw leaf-address inet:ip-address 164 | | +--rw admin-state? enumeration 165 | +--rw candidate-path* [protocol-id originator discriminator] 166 | +--rw protocol-id enumeration 167 | +--rw originator inet:ip-address 168 | +--rw discriminator uint32 169 | +--rw candidate-path-name? string 170 | +--rw admin-state? enumeration 171 | +--ro oper-state? enumeration 172 | +--rw preference? uint32 173 | +--rw constraints* [index] 174 | | +--rw index uint32 175 | | +--rw attributes? uint32 176 | +--rw explicit-routing* [index] 177 | | +--rw index uint32 178 | | +--rw attributes? uint32 179 | +--rw path-instances* [index] 180 | +--rw index uint32 181 | +--rw instance-id? 182 | -> ../../../../replication-segment/replication-id 183 | +--ro oper-state? enumeration 184 +--rw replication-segment* [node-address replication-id] 185 +--rw node-address inet:ipv4-address 186 +--rw replication-id uint32 187 +--rw admin-state? enumeration 188 +--ro oper-state? enumeration 189 +--rw root-address? inet:ipv4-address 190 +--rw tree-id? uint32 191 +--rw instance-id? uint32 192 +--rw replication-sid? uint32 193 +--rw downstream-nodes* [downstream-index] 194 +--rw downstream-index uint32 195 +--rw next-hop-address? inet:ip-address 196 +--rw next-hop-interface-name? if:interface-ref 197 +--rw protecting-next-hop? boolean 198 +--rw protect-nexthop-id? uint32 199 +--rw (label)? 200 +--:(sid-list) 201 | +--rw sid-list* [index] 202 | +--rw index uint32 203 | +--rw sid-segment-type? uint32 204 +--:(sr-policy) 205 | +--rw sr-policy* [replication-sid] 206 | +--rw replication-sid uint32 207 | +--rw sr-policy? string 208 +--:(rsvp-te) 209 +--rw rsvp-te* [replication-sid] 210 +--rw replication-sid uint32 211 +--rw rsvp-te-tunnel-id? uint32 213 4. Configuration 215 This Module augments the "/rt:routing:" with a treeSID container. 216 This container defines all the configuration parameter related to 217 treeSID and P2MP SR Policy for this particular routing. The P2MP SR 218 policy contains replication policy which in order contain candidate- 219 path and the next-hop-groups for each OIF in the replication Policy. 220 IT should be noted that two disjoint replication policies can be 221 connected via a SR Policy as per draft-ietf-spring-segment-routing- 222 policy. 223 5. Control plane configuration 225 6. States 227 7. Yang Data Model 228 file "ietf-p2mp-policy-@2019-07-04.yang" 229 module ietf-tree-sid { 230 yang-version 1.1; 231 namespace "urn:ietf:params:xml:ns:yang:p2mp-policy-segment"; 232 // replace with IANA namespace when assigned 233 prefix tree-sid; 235 import ietf-inet-types { 236 prefix "inet"; 237 } 239 import ietf-yang-types { 240 prefix "yang"; 241 } 243 import ietf-routing-types { 244 prefix "rt-types"; 245 } 247 import ietf-routing { 248 prefix "rt"; 249 } 251 import ietf-interfaces { 252 prefix "if"; 253 } 255 import ietf-ip { 256 prefix ip; 257 } 259 organization 260 "IETF SPRING Working Group"; 262 contact 263 "WG Web: 264 WG List: 266 WG Chair: Bruno Decraene 267 269 WG Chair: Rob Shakir 270 271 Editor: Hooman Bidgoli 272 273 Editor: Tanmoy Kundu 274 275 Editor: Daniel Voyer 276 277 description 278 "The module defines a collection of YANG definition for 279 p2mp policy module."; 281 revision 2019-10-30 { 282 description 283 "First draft."; 284 reference 285 "RFC XXXX: A YANG Data Model for TREE-SID"; 286 } 288 submodule router-p2mp-traffic-engineering { 290 belongs-to root { prefix "root"; } 291 import ietf-inet-types { prefix "inet"; } 292 import ietf-interfaces { prefix "if"; } 294 container p2mp-traffic-engineering { 295 presence "Configure Tree SID P2PM segment parameters."; 296 description 297 "Create p2mp policies and their corresponding 298 candidate paths for p2mp trees."; 300 list p2mp-policy { 301 key "root-address tree-id"; 302 uses p2mp-policy-key; 303 description 304 "Each p2mp-policy identifies one or more p2mp 305 LSP for on the root towards a set of leaf/leaves."; 307 unique "p2mp-policy-name"; 309 leaf p2mp-policy-name { 310 type string; 311 description 312 "P2MP policy name to be referenced by mvpn pmsi."; 313 } 315 leaf admin-state { 316 type enumeration{ 317 enum down { value 0; } 318 enum up { value 1; } 319 } 320 default down; 321 description 322 "Administratively enable/disable Tree SID p2mp policy."; 323 } 324 leaf oper-state { 325 type enumeration{ 326 enum down { value 0; } 327 enum up { value 1; } 328 } 329 default down; 330 config false; 331 description 332 "Tree SID p2mp policy operational state based on users."; 333 } 335 list leaf-list { 336 key "leaf-address"; 337 uses leaf-list-key; 338 description 339 "This list consists of one or more endpoint/s 340 for a p2mp-segment."; 342 leaf admin-state { 343 type enumeration{ 344 enum down { value 0; } 345 enum up { value 1; } 346 } 347 default down; 348 description 349 "Administratively enable/disable 350 each leaf/endpoint"; 351 } 352 } 354 list candidate-path { 355 description 356 "Candidate path is p2mp tree representing a 357 unique path from root to a specific 358 endpoint using the tree-id constraint."; 360 key "protocol-id originator descriminator"; 362 uses candidate-path-key; 364 leaf candidate-path-name { 365 type string; 366 description 367 "A candidate path name 368 equivalent to a PLSP"; 369 } 370 leaf admin-state { 371 type enumeration{ 372 enum down { value 0; } 373 enum up { value 1; } 374 } 375 default down; 376 description 377 "Administratively enable/disable Tree 378 SID candidate path."; 379 } 381 leaf oper-state { 382 type enumeration{ 383 enum down { value 0; } 384 enum up { value 1; } 385 } 386 default down; 387 config false; 388 description 389 "candidate-path operational state based 390 on ilm programming."; 391 } 393 leaf preference { 394 type uint32; 395 default 100; 396 description 397 "Preference determines the best preferred 398 candidate-path among list of candidate path 399 towards a leaf. Higher preference is 400 chosen."; 401 } 403 list constraints { 404 description 405 "Set of constraints"; 406 key "index"; 408 leaf index { 409 type uint32; 410 description 411 "Key index"; 412 } 414 leaf attributes { 415 type uint32; 416 description 417 "Hooman to fill this, I am not sure"; 418 } 419 } 421 list explicit-routing { 422 description 423 "Set of explicit routing"; 424 key "index"; 426 leaf index { 427 type uint32; 428 description 429 "Key index"; 430 } 432 leaf attributes { 433 type uint32; 434 description 435 "Hooman to fill this, I am not sure"; 436 } 437 } 439 list path-instances { 440 description 441 "Set of calculated path 442 given the constraints 443 and explicit routing per 444 candidate path"; 445 key "index"; 447 leaf index { 448 type uint32; 449 description 450 "Key index"; 451 } 453 leaf instance-id { 454 type leafref { 455 path "../../../../replication-segment/replication-id"; 456 } 457 } 459 leaf oper-state { 460 type enumeration{ 461 enum down { value 0; } 462 enum up { value 1; } 463 } 464 default down; 465 config false; 466 description 467 "Operational state of this replication segment."; 468 } 470 } 471 } 472 } 474 list replication-segment { 475 description 476 "A replication segment specifies the forwarding 477 information for one path-instance in a 478 candidate path."; 480 key "node-address replication-id"; 481 uses replication-segment-key; 483 leaf admin-state { 484 type enumeration{ 485 enum down { value 0; } 486 enum up { value 1; } 487 } 488 default down; 489 description 490 "Administratively enable/disable Tree SID replication segment."; 491 } 493 leaf oper-state { 494 type enumeration{ 495 enum down { value 0; } 496 enum up { value 1; } 497 } 498 default down; 499 config false; 500 description 501 "Replication segment operational 502 state based on SID programming."; 503 } 505 container service-info { 507 leaf root-address { 508 type inet:ipv4-address; 509 description 510 "Root address of the tree."; 511 } 513 leaf tree-id { 514 type uint32; 515 description 516 "Tree ID uniquely identifies a tunnel in the root, 517 this also represent a specific constraint. Also known as 518 color and/or p2mp-id"; 519 } 521 leaf instance-id { 522 type uint32; 523 description 524 "Each LSP instance within a root, tree-id."; 525 } 526 } 528 leaf replication-sid { 529 type uint32; 530 description 531 "incoming sid to identify this 532 replication segment. Either 533 BSID or MPLS label"; 534 } 536 list downstream-nodes { 537 description 538 "Identifies each nexthop in a candidate path."; 539 key "downstream-index"; 541 uses downstream-key; 543 leaf next-hop-address { 544 type inet:ip-address; 545 description 546 "Nexthop address of the destination."; 547 } 549 leaf next-hop-interface-name { 550 type if:interface-ref; 551 description 552 "Next hop out going interface."; 553 } 555 leaf protecting-next-hop { 556 type boolean; 557 default false; 558 description 559 "True if this is a protect nexthop."; 560 } 561 leaf protect-nexthop-id { 562 type uint32; 563 description 564 "Nexthop protection id."; 565 } 567 choice label { 568 list sid-list { 569 key index; 570 uses sid-list-key; 571 description 572 "Out going label for this nexthop."; 574 leaf sid-segment-type { 575 type uint32; 576 description 577 "Hooman to fill, I don't know"; 578 } 579 } 581 list sr-policy { 582 key replication-sid; 583 uses sr-policy-key; 584 description 585 "sr-policy sid for this nexthop."; 587 leaf sr-policy { 588 type string; 589 description 590 "SR policy name to be referrenced by outloing label"; 591 } 592 } 594 list rsvp-te { 595 key replication-sid; 596 uses sr-policy-key; 597 description 598 "RSVP TE Tunnel for this nexthop."; 600 leaf rsvp-te-tunnel-id { 601 type uint32; 602 description 603 "rsvp-te-tunnel-id"; 604 } 605 } 606 } 607 } 608 } 609 } 611 // -------------------------- GROUPINGS --------------------------- 612 grouping p2mp-policy-key { 614 leaf root-address { 615 type inet:ip-address; 616 description 617 "Root address of the tree."; 618 } 620 leaf tree-id { 621 type uint32; 622 description 623 "Tree ID uniquely indentifies a tunnel in the root, 624 this also represent a spefic constraint. Also known as 625 color and/or p2mp-id"; 626 } 628 } 630 grouping leaf-list-key { 631 leaf leaf-address{ 632 type inet:ip-address; 633 description 634 "leaf address of the this p2mp-tree"; 635 } 636 } 638 grouping candidate-path-key { 640 leaf protocol-id { 641 type enumeration { 642 enum pcep { value 10; } 643 enum bgp-sr-policy { value 20; } 644 enum configuration { value 30; } 646 } 647 description 648 "Protocol-Origin of a candidate path is an 8-bit value 649 which identifies the component or protocol that originates 650 or signals the candidate path."; 651 } 653 leaf originator { 654 type inet:ip-address; 655 description 656 "128 bit value, IPv4 address are encoded in lower 32 bit."; 657 } 659 leaf descriminator { 660 type uint32; 661 description 662 "The Discriminator is a 32 bit value associated 663 with a candidate path that uniquely identifies 664 it within the context of an SR Policy from a 665 specific Protocol-Origin"; 666 } 667 } 669 grouping replication-segment-key { 670 leaf node-address { 671 type inet:ipv4-address; 672 description 673 "Node address for which this replication policy is used."; 674 } 676 leaf replication-id { 677 type uint32; 678 description 679 "Each LSP per candidate path."; 680 } 681 } 683 grouping downstream-key { 684 leaf downstream-index { 685 type uint32; 686 description 687 "Nexthop group or downstream replication node index"; 688 } 689 } 691 grouping sid-list-key { 692 leaf index { 693 type uint32 { 694 range 1..2; 695 } 696 } 697 } 699 grouping sr-policy-key { 700 leaf replication-sid { 701 type uint32 { 702 range 1..12; 703 } 704 description 705 "Index for push-label."; 706 } 707 } 708 } 710 6. IANA Considerations 712 This document contains no actions for IANA. 714 7. Security Considerations 716 TBD 718 8. References 720 8.1. Normative References 722 8.2. Informative References 724 [sr-p2mp-policy] D. Yoyer, Ed., C. Hassen, K. Gillis, C. Filsfils, R. 725 Parekh, H.Bidgoli, "SR Replication Policy for P2MP Service Delivery", 726 draft-voyer-spring-sr-p2mp-policy-01, April 2019. 728 7. Acknowledgments 730 Authors' Addresses 732 Hooman Bidgoli 733 Nokia 734 600 March Rd. 735 Ottawa, Ontario K2K 2E6 736 Canada 738 Email: hooman.bidgoli@nokia.com 740 Daniel Voyer 741 Bell Canada 742 Montreal 743 CA 745 Email: daniel.voyer@bell.ca 746 Tanmoy kundu 747 nokia 748 Montain View 749 US 751 Email: tanmoy.kundu@nokia.com 753 Jayant Kotalwar 754 nokia 755 Montain View 756 US 758 Email: jayant.kotalwar@nokia.com 760 Rishabh Parekh 761 Cisco Systems, Inc. 762 San Jose 763 US 765 Email: riparekh@cisco.com 767 Tarek Saad 768 Juniper Networks 770 Email: tssad@juniper.net