idnits 2.17.00 (12 Aug 2021) /tmp/idnits37960/draft-ietf-mpls-base-yang-17.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2020) is 565 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group T. Saad 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track K. Raza 5 Expires: April 29, 2021 R. Gandhi 6 Cisco Systems Inc 7 X. Liu 8 Volta Networks 9 V. Beeram 10 Juniper Networks 11 October 26, 2020 13 A YANG Data Model for MPLS Base 14 draft-ietf-mpls-base-yang-17 16 Abstract 18 This document contains a specification of the MPLS base YANG data 19 model. The MPLS base YANG data model serves as a base framework for 20 configuring and managing an MPLS switching subsystem on an MPLS- 21 enabled router. It is expected that other MPLS YANG data models 22 (e.g. MPLS Label Switched Path (LSP) Static, LDP or RSVP-TE YANG 23 models) will augment the MPLS base YANG data model. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 29, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 62 2. MPLS Base Model . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Model Overview . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Model Organization . . . . . . . . . . . . . . . . . . . 4 65 2.3. Model Design . . . . . . . . . . . . . . . . . . . . . . 6 66 2.4. Model Tree Diagram . . . . . . . . . . . . . . . . . . . 8 67 2.5. Model YANG Module . . . . . . . . . . . . . . . . . . . . 9 68 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 70 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 71 6. Appendix A. Data Tree Instance Example . . . . . . . . . . . 21 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 75 8.2. Informative References . . . . . . . . . . . . . . . . . 29 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 78 1. Introduction 80 A core routing YANG data model is defined in [RFC8349], and it 81 provides a basis for the development of routing data models for 82 specific Address Families (AFs). Specifically, [RFC8349] defines a 83 model for a generic Routing Information Base (RIB) that is Address- 84 Family (AF) agnostic. [RFC8349] also defines two instances of RIBs 85 based on the generic RIB model for IPv4 and IPv6 AFs. 87 The MPLS base model that is defined in this document augments the 88 generic RIB model defined in [RFC8349] with additional data that 89 enables MPLS forwarding for the specific destination prefix(es) 90 present in the AF RIB(s) as described in the MPLS architecture 91 document [RFC3031]. 93 The MPLS base model also defines a new instance of the generic RIB 94 YANG data model as defined in [RFC8349] to store native MPLS routes. 95 The native MPLS RIB instance stores route(s) that are not associated 96 with other AF instance RIBs (such as IPv4, or IPv6 instance RIB(s)), 97 but are enabled for MPLS forwarding. Examples of such native MPLS 98 routes are routes programmed by RSVP on transit MPLS router(s) along 99 the path of a Label Switched Path (LSP). Other example(s) are MPLS 100 routes that cross-connect to specific Layer-2 adjacencies, such as 101 Layer-2 Attachment Circuit(s) (ACs)), or Layer-3 adjacencies, such as 102 Segment-Routing (SR) Adjacency Segments (Adj-SIDs) described in 103 [RFC8402]. 105 The MPLS base YANG data model serves as a basis for future 106 development of MPLS YANG data models covering more-sophisticated MPLS 107 feature(s) and sub-system(s). The main purpose is to provide 108 essential building blocks for other YANG data models involving 109 different control-plane protocols, and MPLS functions. 111 To this end, it is expected that the MPLS base data model will be 112 augmented by a number of other YANG modules developed at IETF (e.g. 113 by TEAS and MPLS working groups). 115 The YANG module in this document conforms to the Network Management 116 Datastore Architecture (NMDA) [RFC8342]. 118 1.1. Terminology 120 The terminology for describing YANG data models is found in 121 [RFC7950]. 123 1.2. Acronyms and Abbreviations 125 MPLS: Multiprotocol Label Switching 127 RIB: Routing Information Base 129 LSP: Label Switched Path 131 LSR: Label Switching Router 133 LER: Label Edge Router 135 FEC: Forwarding Equivalence Class 137 NHLFE: Next Hop Label Forwarding Entry 139 ILM: Incoming Label Map 141 2. MPLS Base Model 143 This document describes the 'ietf-mpls' YANG module that provides 144 base components of the MPLS data model. It is expected that other 145 MPLS YANG modules will augment 'ietf-mpls' YANG module for other MPLS 146 extension to provision Label Switched Paths (LSPs) (e.g. MPLS 147 Static, MPLS LDP or MPLS RSVP-TE LSP(s)). 149 2.1. Model Overview 151 This document models MPLS labeled routes as an augmentation of the 152 generic routing RIB data model as defined in [RFC8349]. For example, 153 IP prefix routes (e.g. routes stored in IPv4 or IPv6 RIBs) are 154 augmented to carry additional data to enable it for MPLS forwarding. 156 This document also defines a new instance of the generic RIB defined 157 in [RFC8349] to store native MPLS route(s) (described further in 158 Section 2.3) by extending the identity 'address-family' defined in 159 [RFC8349] with a new "mpls" identity as suggested in Section 3 of 160 [RFC8349]. 162 2.2. Model Organization 164 Routing +---------------+ v: import 165 YANG module | ietf-routing | o: augment 166 +---------------+ 167 o 168 | 169 v 170 MPLS base +-----------+ v: import 171 YANG module | ietf-mpls | o: augment 172 +-----------+ 173 o o------+ 174 | \ 175 v v 176 +-------------------+ +---------------------+ 177 MPLS Static | ietf-mpls-static@ | | ietf-mpls-ldp.yang@ | . . 178 LSP YANG +-------------------+ +---------------------+ 179 module 180 @: not in this document, shown for illustration only 182 Figure 1: Relationship between MPLS modules 184 The 'ietf-mpls' YANG module defines the following identities: 186 mpls: 188 This identity extends the 'address-family' identity for RIB 189 instance(s) identity as defined in [RFC8349] to represent the 190 native MPLS RIB instance. 192 label-block-alloc-mode: 194 A base YANG identity for supported label block allocation mode(s). 196 The 'ietf-mpls' YANG module contains the following high-level types 197 and groupings: 199 mpls-operations-type: 201 An enumeration type that represents support for possible MPLS 202 operation types (impose-and-forward, pop-and-forward, pop-impose- 203 and-forward, and pop-and-lookup) 205 nhlfe-role: 207 An enumeration type that represents the role of the NHLFE entry. 209 nhlfe-single-contents: 211 A YANG grouping that describes single Next Hop Label Forwarding 212 Entry (NHLFE) and its associated parameters as described in the 213 MPLS architecture document [RFC3031]. This grouping is specific 214 to the case when a single next-hop is associated with the route. 216 The NHLFE is used when forwarding labeled packet. It contains the 217 following information: 219 1. the packet's next hop. For 'nhlfe-single-contents' only a single 220 next hop is expected, while for 'nhlfe-multiple-contents' 221 multiple next hops are possible. 223 2. the operation to perform on the packet's label stack; this can be 224 one of the following operations: a) replace the label at the top 225 of the label stack with one or more specified new label b) pop 226 the label stack c) replace the label at the top of the label 227 stack with a specified new label, and then push one or more 228 specified new labels onto the label stack. d) push one or more 229 label(s) on an unlabeled packet 231 It may also contain: 233 d) the data link encapsulation to use when transmitting the packet 235 e) the way to encode the label stack when transmitting the packet 237 f) any other information needed in order to properly dispose of 238 the packet. 240 nhlfe-multiple-contents: 242 A YANG grouping that describes a set of NHLFE(s) and their 243 associated parameters as described in the MPLS architecture 244 document [RFC3031]. This grouping is used when multiple next-hops 245 are associated with the route. 247 interfaces-mpls: 249 A YANG grouping that describes the list of MPLS enabled interfaces 250 on a device. 252 label-blocks: 254 A YANG grouping that describes the list of assigned MPLS label 255 blocks and their properties. 257 rib-mpls-properties: 259 A YANG grouping for the augmentation of the generic RIB with MPLS 260 label forwarding data as defined in [RFC3031]. 262 rib-active-route-mpls-input: 264 A YANG grouping for the augmentation to the 'active-route' RPC 265 that is specific to the MPLS RIB instance. 267 2.3. Model Design 269 The MPLS routing model is based on the core routing data model 270 defined in [RFC8349]. Figure 2 shows the extensions introduced by 271 the MPLS base model on defined RIB(s). 273 +-----------------+ 274 | MPLS base model | 275 +-----------------+ 276 ____/ | |_____ |________ 277 / | \ \ 278 / | \ \ 279 o o o + 280 +---------+ +---------+ +--------+ +-----------+ 281 | RIB(v4) | | RIB(v6) | | RIB(x) | | RIB(mpls) | 282 +---------+ +---------+ +--------+ +-----------+ 284 +: created by the MPLS base model 285 o: augmented by the MPLS base model 287 Figure 2: Relationship between MPLS model and RIB instances 289 As shown in Figure 2, the MPLS base YANG data model augments defined 290 instance(s) of AF RIB(s) with additional data that enables MPLS 291 forwarding for destination prefix(es) store in such RIB(s). For 292 example, an IPv4 prefix stored in RIB(v4) is augmented to carry a 293 MPLS local label and per next-hop remote label(s) to enable MPLS 294 forwarding for such prefix. 296 The MPLS base model also creates a separate instance of the generic 297 RIB model defined in [RFC8349] to store MPLS native route(s) that are 298 enabled for MPLS forwarding, but not stored in other AF RIB(s). 300 Some examples of such native MPLS routes are: 302 o routes programmed by RSVP on Label Switched Router(s) (LSRs) along 303 the path of a Label Switched Path (LSP), 305 o routes that cross-connect an MPLS local label to a Layer-2, or 306 Layer-3 VRF, 308 o routes that cross-connect an MPLS local label to a specific 309 Layer-2 adjacency or interface, such as Layer-2 Attachment 310 Circuit(s) (ACs), or 312 o routes that cross-connect an MPLS local label to a Layer-3 313 adjacency or interface - such as MPLS Segment-Routing (SR) 314 Adjacency Segments (Adj-SIDs), SR MPLS Binding SIDs, etc. as 315 defined in [RFC8402]. 317 2.4. Model Tree Diagram 319 The MPLS base tree diagram that follows the notation defined in 320 [RFC8340] is shown in Figure 3. 322 module: ietf-mpls 323 augment /rt:routing: 324 +--rw mpls 325 +--rw ttl-propagate? boolean 326 +--rw mpls-label-blocks 327 | +--rw mpls-label-block* [index] 328 | +--rw index string 329 | +--rw start-label? rt-types:mpls-label 330 | +--rw end-label? rt-types:mpls-label 331 | +--rw block-allocation-mode? identityref 332 | +--ro inuse-labels-count? yang:gauge32 333 +--rw interfaces 334 +--rw interface* [name] 335 +--rw name if:interface-ref 336 +--rw mpls-enabled? boolean 337 +--rw maximum-labeled-packet? uint32 338 augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route: 339 +--ro mpls-enabled? boolean 340 +--ro mpls-local-label? rt-types:mpls-label 341 +--ro destination-prefix? -> ../mpls-local-label 342 +--ro route-context? string 343 augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop 344 /rt:next-hop-options/rt:simple-next-hop: 345 +--ro mpls-label-stack 346 +--ro entry* [id] 347 +--ro id uint8 348 +--ro label? rt-types:mpls-label 349 +--ro ttl? uint8 350 +--ro traffic-class? uint8 351 augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop 352 /rt:next-hop-options/rt:next-hop-list/rt:next-hop-list 353 /rt:next-hop: 354 +--ro index? string 355 +--ro backup-index? string 356 +--ro loadshare? uint16 357 +--ro role? nhlfe-role 358 +--ro mpls-label-stack 359 +--ro entry* [id] 360 +--ro id uint8 361 +--ro label? rt-types:mpls-label 362 +--ro ttl? uint8 363 +--ro traffic-class? uint8 364 augment /rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input: 366 +---w destination-address? -> ../mpls-local-label 367 +---w mpls-local-label? rt-types:mpls-label 368 augment /rt:routing/rt:ribs/rt:rib/rt:active-route/rt:output 369 /rt:route/rt:next-hop/rt:next-hop-options 370 /rt:simple-next-hop: 371 +-- mpls-label-stack 372 +-- entry* [id] 373 +-- id uint8 374 +-- label? rt-types:mpls-label 375 +-- ttl? uint8 376 +-- traffic-class? uint8 377 augment /rt:routing/rt:ribs/rt:rib/rt:active-route/rt:output 378 /rt:route/rt:next-hop/rt:next-hop-options 379 /rt:next-hop-list/rt:next-hop-list/rt:next-hop: 380 +-- index? string 381 +-- backup-index? string 382 +-- loadshare? uint16 383 +-- role? nhlfe-role 384 +-- mpls-label-stack 385 +-- entry* [id] 386 +-- id uint8 387 +-- label? rt-types:mpls-label 388 +-- ttl? uint8 389 +-- traffic-class? uint8 391 Figure 3: MPLS Base tree diagram 393 2.5. Model YANG Module 395 This section describes the 'ietf-mpls' YANG module that provides base 396 components of the MPLS data model. Other YANG module(s) may import 397 and augment the base MPLS module to add feature specific data. 399 The ietf-mpls YANG module imports the following YANG modules: 401 o ietf-routing defined in [RFC8349] 403 o ietf-routing-types defined in [RFC8294] 405 o ietf-interfaces defined in [RFC8343] 407 This YANG module also references the following RFCs in defining the 408 types and YANG grouping of the YANG module: [RFC3032], [RFC3031], and 409 [RFC7424]. 411 file "ietf-mpls@2020-10-26.yang" 412 module ietf-mpls { 413 yang-version 1.1; 414 namespace "urn:ietf:params:xml:ns:yang:ietf-mpls"; 416 /* Replace with IANA when assigned */ 418 prefix mpls; 420 import ietf-routing { 421 prefix rt; 422 reference 423 "RFC8349: A YANG Data Model for Routing Management"; 424 } 425 import ietf-routing-types { 426 prefix rt-types; 427 reference 428 "RFC8294:Common YANG Data Types for the Routing Area"; 429 } 430 import ietf-yang-types { 431 prefix yang; 432 reference 433 "RFC6991: Common YANG Data Types"; 434 } 435 import ietf-interfaces { 436 prefix if; 437 reference 438 "RFC8343: A YANG Data Model for Interface Management"; 439 } 441 organization 442 "IETF MPLS Working Group"; 443 contact 444 "WG Web: 446 WG List: 448 Editor: Tarek Saad 449 451 Editor: Kamran Raza 452 454 Editor: Rakesh Gandhi 455 457 Editor: Xufeng Liu 458 460 Editor: Vishnu Pavan Beeram 461 "; 463 description 464 "This YANG module defines the essential components for the 465 management of the MPLS subsystem. The model fully conforms 466 to the Network Management Datastore Architecture (NMDA). 468 Copyright (c) 2018 IETF Trust and the persons 469 identified as authors of the code. All rights reserved. 471 Redistribution and use in source and binary forms, with or 472 without modification, is permitted pursuant to, and subject 473 to the license terms contained in, the Simplified BSD License 474 set forth in Section 4.c of the IETF Trust's Legal Provisions 475 Relating to IETF Documents 476 (https://trustee.ietf.org/license-info). 477 This version of this YANG module is part of RFC XXXX; see 478 the RFC itself for full legal notices."; 480 // RFC Ed.: replace XXXX with actual RFC number and remove this 481 // note. 482 // RFC Ed.: update the date below with the date of RFC publication 483 // and remove this note. 485 revision 2020-10-26 { 486 description 487 "Initial revision."; 488 reference 489 "RFC XXXX: A YANG Data Model for base MPLS"; 490 } 492 /* Identities */ 494 identity mpls { 495 base rt:address-family; 496 description 497 "This identity represents the MPLS address family."; 498 } 500 identity mpls-unicast { 501 base mpls:mpls; 502 description 503 "This identity represents the MPLS unicast address family."; 504 } 506 identity label-block-alloc-mode { 507 description 508 "Base identity for label-block allocation mode."; 509 } 510 identity label-block-alloc-mode-manager { 511 base label-block-alloc-mode; 512 description 513 "Label block allocation on reserved block 514 is managed by label manager."; 515 } 517 identity label-block-alloc-mode-application { 518 base label-block-alloc-mode; 519 description 520 "Label block allocation on reserved block 521 is managed by application."; 522 } 524 /** 525 * Typedefs 526 */ 528 typedef mpls-operations-type { 529 type enumeration { 530 enum impose-and-forward { 531 description 532 "Operation impose outgoing label(s) and forward to 533 next-hop."; 534 } 535 enum pop-and-forward { 536 description 537 "Operation pop incoming label and forward to next-hop."; 538 } 539 enum pop-impose-and-forward { 540 description 541 "Operation pop incoming label, impose one or more 542 outgoing label(s) and forward to next-hop."; 543 } 544 enum swap-and-forward { 545 description 546 "Operation swap incoming label, with outgoing label and 547 forward to next-hop."; 548 } 549 enum pop-and-lookup { 550 description 551 "Operation pop incoming label and perform a lookup."; 552 } 553 } 554 description 555 "MPLS operations types."; 556 } 557 typedef nhlfe-role { 558 type enumeration { 559 enum primary { 560 description 561 "Next-hop acts as primary for carrying traffic."; 562 } 563 enum backup { 564 description 565 "Next-hop acts as backup."; 566 } 567 enum primary-and-backup { 568 description 569 "Next-hop acts as primary and backup simultaneously 570 for carry traffic."; 571 } 572 } 573 description 574 "The next-hop role."; 575 } 577 grouping nhlfe-single-contents { 578 description 579 "A grouping that describes single Next Hop Label Forwarding 580 Entry (NHLFE) and its associated parameters as described in 581 the MPLS architecture. This grouping is specific to the case 582 when a single next-hop is associated with the route."; 583 uses rt-types:mpls-label-stack; 584 } 586 grouping nhlfe-multiple-contents { 587 description 588 "A grouping that describes a set of NHLFE(s) and their 589 associated parameters as described in the MPLS architecture. 590 This grouping is used when multiple next-hops are associated 591 with the route."; 592 leaf index { 593 type string; 594 description 595 "A user-specified identifier utilised to uniquely 596 reference the next-hop entry in the next-hop list. 597 The value of this index has no semantic meaning 598 other than for referencing the entry."; 599 } 600 leaf backup-index { 601 type string; 602 description 603 "A user-specified identifier utilised to uniquely 604 reference the backup next-hop entry in the NHLFE list. 606 The value of this index has no semantic meaning 607 other than for referencing the entry."; 608 reference 609 "RFC4090 and RFC5714"; 610 } 611 leaf loadshare { 612 type uint16; 613 default "1"; 614 description 615 "This value is used to compute a loadshare to perform un-equal 616 load balancing when multiple outgoing next-hop(s) are 617 specified. A share is computed as a ratio of this number to the 618 total under all next-hops(s)."; 619 reference 620 "RFC7424, section 5.4, 621 RFC3031, section 3.11 and 3.12."; 622 } 623 leaf role { 624 type nhlfe-role; 625 description 626 "NHLFE role."; 627 } 628 uses nhlfe-single-contents; 629 } 631 grouping interfaces-mpls { 632 description 633 "List of MPLS interfaces."; 634 container interfaces { 635 description 636 "List of MPLS enabled interaces."; 637 list interface { 638 key "name"; 639 description 640 "MPLS enabled interface entry."; 641 leaf name { 642 type if:interface-ref; 643 description 644 "A reference to the name of a interface in the system that 645 is to be enabled for MPLS."; 646 } 647 leaf mpls-enabled { 648 type boolean; 649 default "false"; 650 description 651 "'true' if mpls encapsulation is enabled on the interface. 652 'false' if mpls encapsulation is disabled on the 653 interface."; 655 } 656 leaf maximum-labeled-packet { 657 type uint32; 658 units "octets"; 659 description 660 "Maximum labeled packet size."; 661 reference 662 "RFC3032, section 3.2."; 663 } 664 } 665 } 666 } 668 grouping globals { 669 description 670 "MPLS global configuration grouping."; 671 leaf ttl-propagate { 672 type boolean; 673 default "true"; 674 description 675 "Propagate TTL between IP and MPLS."; 676 } 677 } 679 grouping label-blocks { 680 description 681 "Label-block allocation grouping."; 682 container mpls-label-blocks { 683 description 684 "Label-block allocation container."; 685 list mpls-label-block { 686 key "index"; 687 description 688 "List of MPLS label-blocks."; 689 leaf index { 690 type string; 691 description 692 "A user-specified identifier utilised to uniquely 693 reference an MPLS label block."; 694 } 695 leaf start-label { 696 type rt-types:mpls-label; 697 must '. <= ../end-label' { 698 error-message 699 "The start-label must be less than or equal " 700 + "to end-label"; 701 } 702 description 703 "Label-block start."; 704 } 705 leaf end-label { 706 type rt-types:mpls-label; 707 must '. >= ../start-label' { 708 error-message 709 "The end-label must be greater than or equal " 710 + "to start-label"; 711 } 712 description 713 "Label-block end."; 714 } 715 leaf block-allocation-mode { 716 type identityref { 717 base label-block-alloc-mode; 718 } 719 description 720 "Label-block allocation mode."; 721 } 722 leaf inuse-labels-count { 723 when "derived-from-or-self(../block-allocation-mode, " 724 + "'mpls:label-block-alloc-mode-manager')"; 725 type yang:gauge32; 726 config false; 727 description 728 "Label-block inuse labels count."; 729 } 730 } 731 } 732 } 734 grouping rib-mpls-properties { 735 description 736 "A grouping of native MPLS RIB properties."; 737 leaf destination-prefix { 738 type leafref { 739 path "../mpls-local-label"; 740 } 741 description 742 "MPLS destination prefix."; 743 } 744 leaf route-context { 745 type string; 746 description 747 "A context associated with the native MPLS route."; 748 } 749 } 750 grouping rib-active-route-mpls-input { 751 description 752 "A grouping applicable to native MPLS RIB 'active-route' 753 RPC input augmentation."; 754 leaf destination-address { 755 type leafref { 756 path "../mpls-local-label"; 757 } 758 description 759 "MPLS native active route destination."; 760 } 761 leaf mpls-local-label { 762 type rt-types:mpls-label; 763 description 764 "MPLS local label."; 765 } 766 } 768 augment "/rt:routing" { 769 description 770 "MPLS augmentation."; 771 container mpls { 772 description 773 "MPLS container, to be used as an augmentation target node 774 other MPLS sub-features config, e.g. MPLS static LSP, MPLS 775 LDP LSPs, and Trafic Engineering MPLS LSP Tunnels, etc."; 776 uses globals; 777 uses label-blocks; 778 uses interfaces-mpls; 779 } 780 } 782 /* MPLS routes augmentation */ 784 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { 785 description 786 "This augmentation is applicable to all MPLS routes."; 787 leaf mpls-enabled { 788 type boolean; 789 default "false"; 790 description 791 "Indicates whether MPLS is enabled for this route."; 792 } 793 leaf mpls-local-label { 794 when "../mpls-enabled = 'true'"; 795 type rt-types:mpls-label; 796 description 797 "MPLS local label associated with the route."; 799 } 800 uses rib-mpls-properties { 801 /* MPLS AF augmentation to native MPLS RIB */ 802 when "derived-from-or-self(../../rt:address-family, " 803 + "'mpls:mpls')" { 804 description 805 "This augment is valid only for routes of native MPLS 806 RIB."; 807 } 808 } 809 } 811 /* MPLS simple-next-hop augmentation */ 813 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" 814 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 815 description 816 "Augment 'simple-next-hop' case in IP unicast routes."; 817 uses nhlfe-single-contents { 818 when "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" 819 + "/mpls:mpls-enabled = 'true'"; 820 } 821 } 823 /* MPLS next-hop-list augmentation */ 825 augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" 826 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 827 + "rt:next-hop-list/rt:next-hop" { 828 description 829 "This leaf augments the 'next-hop-list' case of IP unicast 830 routes."; 831 uses nhlfe-multiple-contents { 832 when "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" 833 + "/mpls:mpls-enabled = 'true'"; 834 } 835 } 837 /* MPLS RPC input augmentation */ 839 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" { 840 description 841 "Input MPLS augmentation for the 'active-route' action 842 statement."; 843 uses rib-active-route-mpls-input { 844 /* MPLS AF augmentation to native MPLS RIB */ 845 when "derived-from-or-self(../rt:address-family, " 846 + "'mpls:mpls')" { 848 description 849 "This augment is valid only for routes of native MPLS 850 RIB."; 851 } 852 } 853 } 855 /* MPLS RPC output augmentation */ 857 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 858 + "rt:output/rt:route/" 859 + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { 860 description 861 "Output MPLS augmentation for the 'active-route' action 862 statement."; 863 uses nhlfe-single-contents; 864 } 866 augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" 867 + "rt:output/rt:route/" 868 + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" 869 + "rt:next-hop-list/rt:next-hop" { 870 description 871 "Output MPLS augmentation for the 'active-route' action 872 statement."; 873 uses nhlfe-multiple-contents; 874 } 875 } 876 878 Figure 4: MPLS base YANG module. 880 3. IANA Considerations 882 This document registers the following URIs in the 'ns' sub-registry 883 of the IETF XML registry [RFC3688]. Following the format in 884 [RFC3688], the following registration is requested to be made. 886 URI: urn:ietf:params:xml:ns:yang:ietf-mpls 887 Registrant Contact: The MPLS WG of the IETF. 888 XML: N/A, the requested URI is an XML namespace. 890 This document registers a YANG module in the YANG Module Names 891 registry [RFC6020]. 893 name: ietf-mpls 894 namespace: urn:ietf:params:xml:ns:yang:ietf-mpls 895 prefix: mpls 896 // RFC Ed.: replace XXXX with RFC number and remove this note 897 reference: RFCXXXX 899 4. Security Considerations 901 The YANG module specified in this document define a schema for data 902 that is designed to be accessed via network management protocols such 903 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 904 is the secure transport layer, and the mandatory-to-implement secure 905 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 906 is HTTPS, and the mandatory-to-implement secure transport is TLS 907 [RFC8446]. 909 The NETCONF access control model [RFC8341] provides the means to 910 restrict access for particular NETCONF or RESTCONF users to a 911 preconfigured subset of all available NETCONF or RESTCONF protocol 912 operations and content. 914 There are a number of data nodes defined in this YANG module that are 915 writable/creatable/deletable (i.e., config true, which is the 916 default). These data nodes may be considered sensitive or vulnerable 917 in some network environments. Write operations (e.g., edit-config) 918 to these data nodes without proper protection can have a negative 919 effect on network operations. These are the subtrees and data nodes 920 and their sensitivity/vulnerability: 922 "/rt:routing/mpls:mpls/mpls:label-blocks": there are data nodes under 923 this path that are writeable such as 'start-label' and 'end-label'. 924 Write operations to those data npdes may cause disruptive action to 925 existing traffic. 927 Some of the readable data nodes in these YANG module may be 928 considered sensitive or vulnerable in some network environments. It 929 is thus important to control read access (e.g., via get, get-config, 930 or notification) to these data nodes. These are the subtrees and 931 data nodes and their sensitivity/vulnerability: 933 "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next- 934 hop-options/rt:next-hop-list/rt:next-hop-list/rt:next-hop" and 935 "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:output/rt:route/ 936 rt:next-hop/rt:next-hop-options/rt:simple-next-hop": these two paths 937 are augmented by additional MPLS leaf(s) defined in this model. 938 Access to this information may disclose the next-hop or path per 939 prefix and/or other information. 941 Some of the RPC operations in this YANG module may be considered 942 sensitive or vulnerable in some network environments. It is thus 943 important to control access to these operations. These are the 944 operations and their sensitivity/vulnerability: 946 "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" and 947 "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:output/rt:route": 948 these two paths are augmented by additional MPLS data node(s) that 949 are defined in this model. Access to those path(s) may may disclose 950 information about per prefix route and/or other information and that 951 may be further used for further attack(s). 953 The security considerations spelled out in [RFC3031] and [RFC3032] 954 apply for this document as well. 956 5. Acknowledgement 958 The authors would like to thank Xia Chen for her contributions to the 959 early revisions of this document. 961 6. Appendix A. Data Tree Instance Example 963 A simple network setup is shown in Figure 5. R1 runs the ISIS 964 routing protocol, and learns reachability about two IPv4 prefixes: 965 P1: 198.51.100.1/32 and P2: 198.51.100.1/32, and two IPv6 prefixes 966 P3: 2001:db8:0:10::1/64 and P4: 2001:db8:0:10::1/64. We also assume 967 that R1 learns about local and remote MPLS label bindings for each 968 prefix using ISIS (e.g. using Segment-Routing (SR) extensions). 970 State on R1: 971 ============ 972 IPv4 Prefix MPLS Label 973 P1: 198.51.100.1/32 16001 974 P2: 198.51.100.2/32 16002 976 IPv6 Prefix MPLS Label 977 P3: 2001:db8:0:10::1/64 16003 978 P4: 2001:db8:0:10::2/64 16004 980 RSVP MPLS LSPv4-Tunnel: 981 Source: 198.51.100.3 982 Destination: 198.51.100.4 983 Tunnel-ID: 10 984 LSP-ID: 1 985 192.0.2.5/30 986 2001:db8:0:1::1/64 987 eth0 988 +--- 989 / 990 +-----+ 991 | R1 | 992 +-----+ 993 \ 994 +--- 995 eth1 996 192.0.2.13/30 997 2001:db8:0:2::1/64 999 Figure 5: Example of network configuration. 1001 The instance data tree could then be as follows: 1003 { 1004 "ietf-routing:routing":{ 1005 "ribs":{ 1006 "rib":[ 1007 { 1008 "name":"RIB-V4", 1009 "address-family": 1010 "ietf-ipv4-unicast-routing:v4ur:ipv4-unicast", 1011 "routes":{ 1012 "route":[ 1013 { 1014 "next-hop":{ 1015 "outgoing-interface":"eth0", 1016 "ietf-mpls:mpls-label-stack":{ 1017 "entry":[ 1018 { 1019 "id":1, 1020 "label":16001, 1021 "ttl":255 1022 } 1023 ] 1024 }, 1025 "ietf-ipv4-unicast-routing:next-hop-address": 1026 "192.0.2.5" 1027 }, 1028 "source-protocol":"isis:isis", 1029 "ietf-mpls:mpls-enabled":true, 1030 "ietf-mpls:mpls-local-label":16001, 1031 "ietf-ipv4-unicast-routing:destination-prefix": 1032 "198.51.100.1/32", 1033 "ietf-mpls:route-context":"SID-IDX:1" 1034 }, 1035 { 1036 "next-hop":{ 1037 "next-hop-list":{ 1038 "next-hop":[ 1039 { 1040 "outgoing-interface":"eth0", 1041 "ietf-mpls:index":"1", 1042 "ietf-mpls:backup-index":"2", 1043 "ietf-mpls:role":"primary-and-backup", 1044 "ietf-mpls:mpls-label-stack":{ 1045 "entry":[ 1046 { 1047 "id":1, 1048 "label":16002, 1049 "ttl":255 1050 } 1051 ] 1052 }, 1053 "ietf-ipv4-unicast-routing:address":"192.0.2.5" 1054 }, 1055 { 1056 "outgoing-interface":"eth1", 1057 "ietf-mpls:index":"2", 1058 "ietf-mpls:backup-index":"1", 1059 "ietf-mpls:role":"primary-and-backup", 1060 "ietf-mpls:mpls-label-stack":{ 1061 "entry":[ 1062 { 1063 "id":1, 1064 "label":16002, 1065 "ttl":255 1066 } 1067 ] 1068 }, 1069 "ietf-ipv4-unicast-routing:address":"192.0.2.13" 1070 } 1071 ] 1072 } 1073 }, 1074 "source-protocol":"isis:isis", 1075 "ietf-mpls:mpls-enabled":true, 1076 "ietf-mpls:mpls-local-label":16002, 1077 "ietf-ipv4-unicast-routing:destination-prefix": 1078 "198.51.100.2/32", 1079 "ietf-mpls:route-context":"SID-IDX:2" 1080 } 1081 ] 1082 } 1083 }, 1084 { 1085 "name":"RIB-V6", 1086 "address-family": 1087 "ietf-ipv6-unicast-routing:v6ur:ipv6-unicast", 1088 "routes":{ 1089 "route":[ 1090 { 1091 "next-hop":{ 1092 "outgoing-interface":"eth0", 1093 "ietf-mpls:mpls-label-stack":{ 1094 "entry":[ 1095 { 1096 "id":1, 1097 "label":16003, 1098 "ttl":255 1099 } 1100 ] 1101 }, 1102 "ietf-ipv6-unicast-routing:next-hop-address": 1103 "2001:db8:0:1::1" 1104 }, 1105 "source-protocol":"isis:isis", 1106 "ietf-mpls:mpls-enabled":true, 1107 "ietf-mpls:mpls-local-label":16001, 1108 "ietf-ipv6-unicast-routing:destination-prefix": 1109 "2001:db8:0:10::1/6", 1110 "ietf-mpls:route-context":"SID-IDX:1" 1111 }, 1112 { 1113 "next-hop":{ 1114 "next-hop-list":{ 1115 "next-hop":[ 1116 { 1117 "outgoing-interface":"eth0", 1118 "ietf-mpls:index":"1", 1119 "ietf-mpls:backup-index":"2", 1120 "ietf-mpls:role":"primary-and-backup", 1121 "ietf-mpls:mpls-label-stack":{ 1122 "entry":[ 1123 { 1124 "id":1, 1125 "label":16004, 1126 "ttl":255 1127 } 1128 ] 1129 }, 1130 "ietf-ipv6-unicast-routing:address": 1131 "2001:db8:0:1::1" 1132 }, 1133 { 1134 "outgoing-interface":"eth1", 1135 "ietf-mpls:index":"2", 1136 "ietf-mpls:backup-index":"1", 1137 "ietf-mpls:role":"primary-and-backup", 1138 "ietf-mpls:mpls-label-stack":{ 1139 "entry":[ 1140 { 1141 "id":1, 1142 "label":16004, 1143 "ttl":255 1144 } 1145 ] 1146 }, 1147 "ietf-ipv6-unicast-routing:address": 1148 "2001:db8:0:2::1" 1149 } 1150 ] 1151 } 1152 }, 1153 "source-protocol":"isis:isis", 1154 "ietf-mpls:mpls-enabled":true, 1155 "ietf-mpls:mpls-local-label":16004, 1156 "ietf-ipv6-unicast-routing:destination-prefix": 1157 "2001:db8:0:10::2/64", 1158 "ietf-mpls:route-context":"SID-IDX:2" 1159 } 1160 ] 1162 } 1163 }, 1164 { 1165 "name":"RIB-MPLS", 1166 "address-family":"ietf-mpls:mpls:mpls", 1167 "routes":{ 1168 "route":[ 1169 { 1170 "next-hop":{ 1171 "outgoing-interface":"eth0", 1172 "ietf-mpls:mpls-label-stack":{ 1173 "entry":[ 1174 { 1175 "id":1, 1176 "label":24002, 1177 "ttl":255 1178 } 1179 ] 1180 }, 1181 "ietf-ipv4-unicast-routing:next-hop-address": 1182 "192.0.2.5" 1183 }, 1184 "source-protocol":"rsvp:rsvp", 1185 "ietf-mpls:mpls-enabled":true, 1186 "ietf-mpls:mpls-local-label":24001, 1187 "ietf-mpls:destination-prefix":"24001", 1188 "ietf-mpls:route-context": 1189 "RSVP Src:198.51.100.3,Dst:198.51.100.4,T:10,L:1" 1190 } 1191 } 1192 } 1193 } 1194 ] 1195 }, 1196 "ietf-mpls:mpls":{ 1197 "mpls-label-blocks":{ 1198 "mpls-label-block":[ 1199 { 1200 "index":"mpls-srgb-label-block", 1201 "start-label":16000, 1202 "end-label":16500, 1203 "block-allocation-mode":"mpls:label-block-alloc-mode-manager" 1204 } 1205 ] 1206 }, 1207 "interfaces":{ 1208 "interface":[ 1209 { 1210 "name":"eth0", 1211 "mpls-enabled":true, 1212 "maximum-labeled-packet":1488 1213 }, 1214 { 1215 "name":"eth1", 1216 "mpls-enabled":true, 1217 "maximum-labeled-packet":1488 1218 } 1219 ] 1220 } 1221 } 1222 } 1223 } 1225 Figure 6: Foo bar. 1227 7. Contributors 1229 Igor Bryskin 1230 Huawei Technologies 1231 email: i_bryskin@yahoo.com 1233 Himanshu Shah 1234 Ciena 1235 email: hshah@ciena.com 1237 8. References 1239 8.1. Normative References 1241 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1242 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1243 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1244 . 1246 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1247 DOI 10.17487/RFC3688, January 2004, 1248 . 1250 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1251 the Network Configuration Protocol (NETCONF)", RFC 6020, 1252 DOI 10.17487/RFC6020, October 2010, 1253 . 1255 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1256 and A. Bierman, Ed., "Network Configuration Protocol 1257 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1258 . 1260 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1261 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1262 . 1264 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1265 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1266 . 1268 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1269 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1270 . 1272 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1273 "Common YANG Data Types for the Routing Area", RFC 8294, 1274 DOI 10.17487/RFC8294, December 2017, 1275 . 1277 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1278 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1279 . 1281 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1282 Access Control Model", STD 91, RFC 8341, 1283 DOI 10.17487/RFC8341, March 2018, 1284 . 1286 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1287 and R. Wilton, "Network Management Datastore Architecture 1288 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1289 . 1291 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1292 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1293 . 1295 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1296 Routing Management (NMDA Version)", RFC 8349, 1297 DOI 10.17487/RFC8349, March 2018, 1298 . 1300 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1301 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1302 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1303 July 2018, . 1305 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1306 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1307 . 1309 8.2. Informative References 1311 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1312 Label Switching Architecture", RFC 3031, 1313 DOI 10.17487/RFC3031, January 2001, 1314 . 1316 [RFC7424] Krishnan, R., Yong, L., Ghanwani, A., So, N., and B. 1317 Khasnabish, "Mechanisms for Optimizing Link Aggregation 1318 Group (LAG) and Equal-Cost Multipath (ECMP) Component Link 1319 Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424, 1320 January 2015, . 1322 Authors' Addresses 1324 Tarek Saad 1325 Juniper Networks 1327 Email: tsaad@juniper.net 1329 Kamran Raza 1330 Cisco Systems Inc 1332 Email: skraza@cisco.com 1334 Rakesh Gandhi 1335 Cisco Systems Inc 1337 Email: rgandhi@cisco.com 1339 Xufeng Liu 1340 Volta Networks 1342 Email: xufeng.liu.ietf@gmail.com 1343 Vishnu Pavan Beeram 1344 Juniper Networks 1346 Email: vbeeram@juniper.net