idnits 2.17.1 draft-saad-mpls-static-yang-03.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 (May 11, 2016) is 2900 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) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 1 error (**), 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 K. Raza 4 Intended status: Standards Track R. Gandhi 5 Expires: November 12, 2016 Cisco Systems Inc 6 X. Liu 7 Ericsson 8 V. Beeram 9 Juniper Networks 10 H. Shah 11 Ciena 12 I. Bryskin 13 X. Chen 14 Huawei Technologies 15 R. Jones 16 Brocade 17 B. Wen 18 Comcast 19 May 11, 2016 21 A YANG Data Model for MPLS Static LSPs 22 draft-saad-mpls-static-yang-03 24 Abstract 26 This document contains the specification for the MPLS Static Label 27 Switched Paths (LSPs) YANG model. The model allows for the 28 provisioning of static LSP(s) on LER(s) and LSR(s) devices along a 29 LSP path without the dependency on any signaling protocol. The MPLS 30 Static LSP model augments the MPLS base YANG model with specific data 31 to configure and manage MPLS Static LSP(s). 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). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 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." 48 This Internet-Draft will expire on November 12, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. MPLS Static LSPs Model Tree Diagram . . . . . . . . . . . 4 70 1.3. MPLS Static LSP YANG Module . . . . . . . . . . . . . . . 5 71 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 4.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 This document describes a YANG data model for configuring and 81 managing the Static LSPs feature. The model allows the configuration 82 of LER and LSR devices with the necessary MPLS cross-connects or 83 bindings to realize an end-to-end LSP service. 85 A static LSP is established by manually specifying incoming and 86 outgoing MPLS label(s) and necessary forwarding information on each 87 of the traversed Label Edge Router (LER) and Label Switched Router 88 (LSR) devices (ingress, transit, or egress nodes) of the forwarding 89 path. 91 For example, on an ingress LER device, the model is used to associate 92 a specific Forwarding Equivalence Class (FEC) of packets- e.g. 93 matching a specific IP prefix in a Virtual Routing or Forwarding 94 (VRF) instance- to an MPLS outgoing label imposition, next-hop(s) and 95 respective outgoing interface(s) to forward the packet. On an LSR 96 device, the model is used to create a binding that swaps the incoming 97 label with an outgoing label and forwards the packet on one or 98 multiple egress path(s). On an egress LER, it is used to create a 99 binding that decapsulates the incoming MPLS label and performs 100 forwarding based on the inner MPLS label (if present) or IP 101 forwarding in the packet. 103 The MPLS Static LSP YANG model is defined in module "ietf-mpls- 104 static" and augments the MPLS Base YANG model defined in module 105 "ietf-mpls" in [I-D.saad-mpls-base-yang]. The approach described 106 in [I-D.openconfig-netmod-opstate] is adopted to represent data 107 pertaining to configuration intended, applied state and derived state 108 data elements. Each container in the model holds a "config" and 109 "state" sub-container. The "config" sub-container is used to 110 represent the intended configurable parameters, and the state sub- 111 container is used to represent both the applied configurable 112 parameters and any derived state, such as counters or statistical 113 information. 115 1.1. Terminology 117 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 118 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 120 [RFC2119]. 122 The following terms are defined in [RFC6020]: 124 o augment, 126 o configuration data, 128 o data model, 130 o data node, 132 o feature, 134 o mandatory node, 136 o module, 138 o schema tree, 140 o state data, 142 o RPC operation. 144 1.2. MPLS Static LSPs Model Tree Diagram 146 The MPLS Static LSP tree diagram is shown in Figure 1. 148 module: ietf-mpls-static 149 augment /rt:routing/mpls:mpls: 150 +--rw static-lsps 151 +--rw static-lsp* [name] 152 +--rw name string 153 +--rw config 154 | +--rw in-segment 155 | | +--rw (type)? 156 | | +--:(ip-prefix) 157 | | | +--rw ip-prefix? inet:ip-prefix 158 | | +--:(mpls-label) 159 | | +--rw incoming-label? mpls:mpls-label 160 | +--rw operation? enumeration 161 | +--rw (out-segment)? 162 | +--:(simple-path) 163 | | +--rw next-hop? inet:ip-address 164 | | +--rw outgoing-label? mpls:mpls-label 165 | | +--rw outgoing-interface? if:interface-ref 166 | +--:(path-list) 167 | +--rw paths* [path-index] 168 | +--rw path-index uint16 169 | +--rw backup-path-index? uint16 170 | +--rw next-hop? inet:ip-address 171 | +--rw outgoing-labels* mpls:mpls-label 172 | +--rw outgoing-interface? if:interface-ref 173 | +--rw loadshare? uint16 174 | +--rw role? enumeration 175 +--ro state 176 +--ro in-segment 177 | +--ro (type)? 178 | +--:(ip-prefix) 179 | | +--ro ip-prefix? inet:ip-prefix 180 | +--:(mpls-label) 181 | +--ro incoming-label? mpls:mpls-label 182 +--ro operation? enumeration 183 +--ro (out-segment)? 184 +--:(simple-path) 185 | +--ro next-hop? inet:ip-address 186 | +--ro outgoing-label? mpls:mpls-label 187 | +--ro outgoing-interface? if:interface-ref 188 +--:(path-list) 189 +--ro paths* [path-index] 190 +--ro path-index uint16 191 +--ro backup-path-index? uint16 192 +--ro next-hop? inet:ip-address 193 +--ro outgoing-labels* mpls:mpls-label 194 +--ro outgoing-interface? if:interface-ref 195 +--ro loadshare? uint16 196 +--ro role? enumeration 198 Figure 1: MPLS Static LSP tree diagram 200 1.3. MPLS Static LSP YANG Module 202 file "ietf-mpls-static@2016-05-11.yang" 204 module ietf-mpls-static { 206 namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-static"; 208 prefix "mpls-static"; 210 import ietf-mpls { 211 prefix mpls; 212 } 214 import ietf-routing { 215 prefix "rt"; 216 } 218 import ietf-inet-types { 219 prefix inet; 220 } 222 import ietf-interfaces { 223 prefix "if"; 224 } 226 organization "IETF MPLS Working Group"; 228 contact 229 "WG Web: 231 WG List: 233 WG Chair: Loa Andersson 234 236 WG Chair: Ross Callon 237 239 WG Chair: George Swallow 240 242 Editor: Tarek Saad 243 245 Editor: Kamran Raza 246 248 Editor: Rakesh Gandhi 249 251 Editor: Xufeng Liu 252 254 Editor: Vishnu Pavan Beeram 255 257 Editor: Himanshu Shah 258 260 Editor: Igor Bryskin 261 263 Editor: Xia Chen 264 266 Editor: Raqib Jones 267 269 Editor: Bin Wen 270 "; 272 description 273 "This YANG module augments the 'ietf-routing' module with basic 274 configuration and operational state data for MPLS static"; 276 revision "2016-05-11" { 277 description 278 "Latest revision: 279 - Addressed MPLS-RT review comments"; 280 reference "RFC 3031: A YANG Data Model for Static MPLS LSPs"; 281 } 283 grouping path-basic_config { 284 description "common definitions for statics"; 286 leaf next-hop { 287 type inet:ip-address; 288 description "next hop IP address for the LSP"; 289 } 291 leaf outgoing-label { 292 type mpls:mpls-label; 293 description 294 "label value to push at the current hop for the 295 LSP"; 296 } 298 leaf outgoing-interface { 299 type if:interface-ref; 300 description 301 "The outgoing interface"; 302 } 304 } 306 grouping path-properties_config { 307 description 308 "MPLS path properties"; 309 leaf path-index { 310 type uint16; 311 description 312 "Path identifier"; 313 } 315 leaf backup-path-index { 316 type uint32; 317 description 318 "Backup path identifier"; 319 } 321 leaf next-hop { 322 type inet:ip-address; 323 description 324 "The address of the next-hop"; 325 } 327 leaf-list outgoing-labels { 328 type mpls:mpls-label; 329 ordered-by user; 330 description 331 "The outgoing MPLS labels to impose"; 332 } 334 leaf outgoing-interface { 335 type if:interface-ref; 336 description 337 "The outgoing interface"; 338 } 340 leaf loadshare { 341 type uint16; 342 description 343 "This value is used to compute a loadshare to perform un-equal 344 load balancing when multiple outgoing path(s) are specified. A 345 share is computed as a ratio of this number to the total under 346 all configured path(s)."; 347 } 349 leaf role { 350 type enumeration { 351 enum PRIMARY { 352 description 353 "Path as primary traffic carrying"; 354 } 355 enum BACKUP { 356 description 357 "Path acts as backup"; 358 } 359 enum PRIMARY_AND_BACKUP { 360 description 361 "Path acts as primary and backup simultaneously"; 362 } 363 } 364 description 365 "The MPLS path role"; 366 } 367 } 369 grouping static-lsp_config { 370 description "common definitions for static LSPs"; 372 container in-segment { 373 description 374 "MPLS incoming segment"; 375 choice type { 376 description 377 "Basic FEC choice"; 378 case ip-prefix { 379 leaf ip-prefix { 380 type inet:ip-prefix; 381 description "An IP prefix"; 382 } 383 } 384 case mpls-label { 385 leaf incoming-label { 386 type mpls:mpls-label; 387 description "label value on the incoming packet"; 388 } 389 } 390 } 391 } 393 leaf operation { 394 type enumeration { 395 enum impose-and-forward { 396 description 397 "Operation impose outgoing label(s) and forward to 398 next-hop"; 399 } 400 enum pop-and-forward { 401 description 402 "Operation pop incoming label and forward to next-hop"; 403 } 404 enum pop-impose-and-forward { 405 description 406 "Operation pop incoming label, impose one or more 407 outgoing label(s) and forward to next-hop"; 408 } 409 enum swap-and-forward { 410 description 411 "Operation swap incoming label, with outgoing label and 412 forward to next-hop"; 413 } 414 enum pop-and-lookup { 415 description 416 "Operation pop incoming label and perform a lookup"; 417 } 418 } 419 description 420 "The MPLS operation to be executed on the incoming packet"; 421 } 423 choice out-segment { 424 description "The MPLS out-segment type choice"; 425 case simple-path { 426 uses path-basic_config; 427 } 428 case path-list { 429 list paths { 430 key path-index; 431 description 432 "The list of MPLS paths associated with the FEC"; 433 uses path-properties_config; 434 } 435 } 436 } 437 } 439 grouping static-lsp { 440 description "grouping for top level list of static LSPs"; 441 container config { 442 description 443 "Holds the intended configuration"; 444 uses static-lsp_config; 445 } 446 container state { 447 config false; 448 description 449 "Holds the state and inuse configuration"; 450 uses static-lsp_config; 451 } 452 } 454 augment "/rt:routing/mpls:mpls" { 455 description "Augmentations for MPLS Static LSPs"; 456 container static-lsps { 457 description 458 "Statically configured LSPs, without dynamic signaling"; 459 list static-lsp { 460 key name; 461 description "list of defined static LSPs"; 463 leaf name { 464 type string; 465 description "name to identify the LSP"; 466 } 467 uses static-lsp; 468 } 469 } 470 } 471 } 473 475 Figure 2: MPLS Static LSP YANG module 477 2. IANA Considerations 479 This document registers the following URIs in the IETF XML registry 480 [RFC3688]. Following the format in [RFC3688], the following 481 registration is requested to be made. 483 URI: urn:ietf:params:xml:ns:yang:ietf-mpls-static XML: N/A, the 484 requested URI is an XML namespace. 486 This document registers a YANG module in the YANG Module Names 487 registry [RFC6020]. 489 name: ietf-mpls-static namespace: urn:ietf:params:xml:ns:yang:ietf- 490 mpls-static prefix: ietf-mpls-static reference: RFC3031 492 3. Security Considerations 494 The YANG module defined in this memo is designed to be accessed via 495 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 496 secure transport layer and the mandatory-to-implement secure 497 transport is SSH [RFC6242]. The NETCONF access control model 498 [RFC6536] provides means to restrict access for particular NETCONF 499 users to a pre-configured subset of all available NETCONF protocol 500 operations and content. 502 There are a number of data nodes defined in the YANG module which are 503 writable/creatable/deletable (i.e., config true, which is the 504 default). These data nodes may be considered sensitive or vulnerable 505 in some network environments. Write operations (e.g., ) 506 to these data nodes without proper protection can have a negative 507 effect on network operations. 509 4. References 511 4.1. Normative References 513 [I-D.saad-mpls-base-yang] 514 Raza, K., Gandhi, R., Liu, X., Beeram, V., Saad, T., Chen, 515 X., Jones, R., and B. Wen, "A YANG Data Model for MPLS 516 Base and Static LSPs", draft-saad-mpls-base-yang-00 517 (work in progress), November 2016. 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 521 RFC2119, March 1997, 522 . 524 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 525 DOI 10.17487/RFC3688, January 2004, 526 . 528 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 529 the Network Configuration Protocol (NETCONF)", RFC 6020, 530 DOI 10.17487/RFC6020, October 2010, 531 . 533 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 534 and A. Bierman, Ed., "Network Configuration Protocol 535 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 536 . 538 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 539 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 540 . 542 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 543 Protocol (NETCONF) Access Control Model", RFC 6536, DOI 544 10.17487/RFC6536, March 2012, 545 . 547 4.2. Informative References 549 [I-D.openconfig-netmod-opstate] 550 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 551 of Operational State Data in YANG", draft-openconfig- 552 netmod-opstate-01 (work in progress), July 2015. 554 Authors' Addresses 556 Tarek Saad 557 Cisco Systems Inc 559 Email: tsaad@cisco.com 561 Kamran Raza 562 Cisco Systems Inc 564 Email: skraza@cisco.com 566 Rakesh Gandhi 567 Cisco Systems Inc 569 Email: rgandhi@cisco.com 570 Xufeng Liu 571 Ericsson 573 Email: xufeng.liu.ietf@gmail.com 575 Vishnu Pavan Beeram 576 Juniper Networks 578 Email: vbeeram@juniper.net 580 Himanshu Shah 581 Ciena 583 Email: hshah@ciena.com 585 Igor Bryskin 586 Huawei Technologies 588 Email: Igor.Bryskin@huawei.com 590 Xia Chen 591 Huawei Technologies 593 Email: jescia.chenxia@huawei.com 595 Raqib Jones 596 Brocade 598 Email: raqib@Brocade.com 600 Bin Wen 601 Comcast 603 Email: Bin_Wen@cable.comcast.com