MPLS Working Group T. Saad Internet-Draft K. Raza Intended status: Standards Track R. Gandhi Expires:August 19, 2018April 13, 2019 Cisco Systems, Inc. X. LiuJabilVolta Networks V. Beeram Juniper NetworksFebruary 15,H. Shah Ciena I. Bryskin Huawei Technologies October 10, 2018 A YANG Data Model for MPLS Static LSPsdraft-ietf-mpls-static-yang-05draft-ietf-mpls-static-yang-06 Abstract This document contains the specification for the MPLS Static Label Switched Paths (LSPs) YANG model. The model allows for the provisioning of static LSP(s) on LER(s) and LSR(s) devices along a LSP path without the dependency on any signaling protocol. The MPLS Static LSP model augments the MPLS base YANG model with specific data to configure and manage MPLS Static LSP(s). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onAugust 19, 2018.April 13, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 2. MPLS Static LSP Model . . . . . . . . . . . . . . . . . . . . 4 2.1. Model Organization . . . . . . . . . . . . . . . . . . .3 1.3. MPLS Static LSPs4 2.2. Model Tree Diagram . . . . . . . . . . . . . . . . . . . 41.4. MPLS Static LSP2.3. Model Overview . . . . . . . . . . . . . . . . . . . . . 6 2.4. Model YANG Module(s) . . . . . . . . . . . . .6 2.. . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . .17 3.14 4. Security Considerations . . . . . . . . . . . . . . . . . . .18 4.14 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Normative References . . . . . . . . . . . . . . . . . . 15 5.2. Informative References . . . . . . . . . . . . . . . . .1816 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .1916 1. Introduction This document describes a YANG [RFC7950] data model for configuring and managing the Multiprotocol Label Switching (MPLS) [RFC3031] StaticLSPs feature.LSPs. The model allows the configuration of LER and LSR devices with the necessary MPLS cross-connects or bindings to realize an end-to-end LSP service. A static LSP is established by manually specifying incoming and outgoing MPLS label(s) and necessary forwarding information on each of the traversed Label Edge Router (LER) and Label Switched Router (LSR) devices (ingress, transit, or egress nodes) of the forwarding path. For example, on an ingress LER device, the model is used to associate a specific Forwarding Equivalence Class (FEC) of packets- e.g. matching a specific IP prefix in a Virtual Routing or Forwarding (VRF) instance- to an MPLS outgoing label imposition, next-hop(s) and respective outgoing interface(s) to forward the packet. On an LSR device, the model is used to create a binding that swaps the incoming label with an outgoing label and forwards the packet on one or multiple egress path(s). On an egress LER, it is used to create a binding that decapsulates the incoming MPLS label and performs forwarding based on the inner MPLS label (if present) or IP forwarding in the packet. The MPLS Static LSP YANG model isdefined in modulebroken into two modules "ietf-mpls- static" and "ietf-mpls-static-extended". The "ietf-mpls-static" module covers basic features for the configuration and management of unidirectional Static LSP(s), while "ietf-mpls-static-extended" covers extended features like the configuration and management of bidirectional Static LSP(s) and LSP admission control. The module "ietf-mpls-static" augments the MPLS Base YANG model defined in module "ietf-mpls" in[I-D.saad-mpls-static-yang].[I-D.ietf-mpls-base-yang]. 1.1. TerminologyIn this document, theThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14, RFC 2119 [RFC2119]. The following terms are defined14 [RFC2119] [RFC8174] when, and only when, they appear in[RFC6020]: o augment, o configuration data, o data model, oall capitals, as shown here. The terminology for describing YANG datanode, o feature, o mandatory node, o module, o schema tree, o state data, o RPC operation.models is found in [RFC7950]. 1.2. Acronyms and Abbreviations MPLS: Multiprotocol Label Switching LSP: Label Switched Path LSR: Label Switching Router LER: Label Edge Router FEC: Forwarding Equivalence Class NHLFE: Next Hop Label Forwarding Entry ILM: Incoming Label Map 2. MPLS Static LSP Model 2.1. Model Organization The base MPLS Static LSP model covers the core features with the minimal set of configuration parameters needed to manage and operate MPLS Static LSPs. Additional MPLS Static LSP parameters as well as optional feature(s) are grouped in a separate MPLS Static LSP extended model. The relationship between the MPLS base and other MPLS modules are shown in Figure 1. RoutingRIB +-----------+module +---------------+ v: importmodule|ietf-ribietf-routing | o: augment+-----------++---------------+ o | v MPLS base +-----------+ v: import module | ietf-mpls | o: augment +-----------+ o o | \ v v +------------------+ +--------------------+ MPLS Static | ietf-mpls-static | | ietf-mpls-ldp.yang | . . . LSP module +------------------+ +--------------------+ o | v +---------------------------+ Extended MPLS | ietf-mpls-static-extended | Static LSP +---------------------------+ module Figure 1: Relationship between MPLS modules1.3. MPLS Static LSPs2.2. Model Tree Diagram The MPLS Static andextendendextended LSP tree diagram as per [RFC8340] is shown in Figure 2. module: ietf-mpls-static augment /rt:routing/mpls:mpls: +--rw static-lsps +--rw static-lsp* [name] | +--rw name-> ../config/namestring | +--rw operation? mpls:mpls-operations-type | +--rwconfigin-segment | | +--rwname? stringfec | | +--rwoperation? mpls-operations-type(type)? |+--ro state| |+--ro name? string+--:(ip-prefix) | | |+--ro operation? mpls-operations-type| +--rw(out-segment)? | +--:(simple-path) | | +--rw simple-path |ip-prefix? inet:ip-prefix |+--rw config| | +--:(mpls-label) |+--rw next-hop? inet:ip-address| | | +--rwoutgoing-label?incoming-label? rt-types:mpls-label | | |+--rw outgoing-interface? if:interface-ref | | +--ro state+--:(tunnel) | |+--ro next-hop? inet:ip-address|| +--ro outgoing-label? rt-types:mpls-label+--rw tunnel? te:tunnel-ref | |+--ro outgoing-interface?+--rw incoming-interface? if:interface-ref |+--:(multiple-paths) |+--rwpathsout-segment | +--rwpath* [path-index](out-segment)? | +--:(nhlfe-single) | | +--rwpath-index -> ../config/path-indexnhlfe-single | | +--rwconfigremote-labels | | | +--rwpath-index? uint16remote-label* [index] | | | +--rwbackup-path-index? uint16index uint8 | | | +--rwnext-hop? inet:ip-address |label? rt-types:mpls-label | | +--rw outgoing-interface? if:interface-ref ||+--:(nhlfe-multiple) | +--rwloadshare? uint16 | |nhlfe-multiple | +--rwrole? enumeration | | +--ro state | | +--ro path-index? uint16 | | +--ro backup-path-index? uint16 | | +--ro next-hop? inet:ip-address |nhlfe* [index] |+--ro outgoing-interface? if:interface-ref+--rw index string | +--rw backup-index? string |+--ro+--rw loadshare? uint16 || +--ro role? enumeration |+--rwoutgoing-labelsrole? nhlfe-role | +--rwoutgoing-labels* [index]remote-labels |+--rw index -> ../config/index| +--rwconfigremote-label* [index] | | +--rwindex?index uint8 | | +--rw label? rt-types:mpls-label |+--ro state | +--ro index? uint8 | +--ro label? rt-types:mpls-label+--rw outgoing-interface? if:interface-ref +--rw mpls-static-ext:bandwidth? uint32 +--rw mpls-static-ext:lsp-priority-setup? uint8 +--rw mpls-static-ext:lsp-priority-hold? uint8 module: ietf-mpls-static-extended augment /rt:routing/mpls:mpls: +--rw bidir-static-lsps +--rw bidir-static-lsp* [name] +--rw name string +--rwconfig | +--rwforward-lsp? mpls-static:static-lsp-ref|+--rw reverse-lsp? mpls-static:static-lsp-ref+--ro state +--ro forward-lsp? mpls-static:static-lsp-ref +--ro reverse-lsp? mpls-static:static-lsp-refFigure 2: MPLS Static LSP tree diagram1.4. MPLS Static LSP2.3. Model Overview This document defines two YANGModule(s) Themodules for MPLS StaticLSPLSP(s) configuration and management: ietf-mpls-static.yang and ietf-mpls- static-extended.yang. The ietf-mpls-static moduleis shownimports the followinig modules: o ietf-inet-types defined inFigure 3. <CODE BEGINS> file "ietf-mpls-static@2017-07-02.yang" module ietf-mpls-static { namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-static"; prefix "mpls-static"; import ietf-mpls { prefix mpls; } import[RFC6991] o ietf-routing{ prefix "rt"; } importdefined in [RFC8349] o ietf-routing-types{ prefix "rt-types"; } import ietf-inet-types { prefix inet; } importdefined in [RFC8294] o ietf-interfaces{ prefix "if"; } /* Import TE generic types */ importdefined in [RFC8343] o ietf-mpls defined in [I-D.ietf-mpls-base-yang] o ietf-te{ prefix te; } organization "IETF MPLS Working Group"; contact "WG Web: <http://tools.ietf.org/wg/mpls/> WG List: <mailto:mpls@ietf.org> WG Chair: Loa Andersson <mailto:loa@pi.nu> WG Chair: Ross Callon <mailto:rcallon@juniper.net> WG Chair: George Swallow <mailto:swallow.ietf@gmail.com> Editor: Tarek Saad <mailto:tsaad@cisco.com> Editor: Kamran Raza <mailto:skraza@cisco.com> Editor: Rakesh Gandhi <mailto:rgandhi@cisco.com> Editor: Xufeng Liu <mailto: xufeng.liu.ietf@gmail.com> Editor: Vishnu Pavan Beeram <mailto:vbeeram@juniper.net> Editor: Himanshu Shah <mailto:hshah@ciena.com> Editor: Igor Bryskin <mailto: Igor.Bryskin@huawei.com> Editor: Xia Chen <mailto:jescia.chenxia@huawei.com> Editor: Raqib Jones <mailto:raqib@Brocade.com> Editor: Bin Wen <mailto:Bin_Wen@cable.comcast.com>"; description "This YANGdefined in [I-D.ietf-teas-yang-te] ietf-mpls-static moduleaugmentscontains the'ietf-routing' module with basic configurationfollowing high-level types andoperational state datagroupings: static-lsp-ref: A YANG reference type forMPLS static"; revision "2017-07-02" { description "Latest revision: - Addressed MPLS-RT review comments"; reference "RFC 3031: A YANG Data Model for Static MPLS LSPs"; } typedef static-lsp-ref { type leafref { path "/rt:routing/mpls:mpls/mpls-static:static-lsps/" + "mpls-static:static-lsp/mpls-static:name"; } description "This type isa static LSP that can be used by data modelsthat needto reference a configured staticLSP."; } typedef mpls-operations-type { type enumeration { enum impose-and-forward { description "Operation impose outgoing label(s) and forward to next-hop"; } enum pop-and-forward { description "Operation popLSP. in-segment: A YANG grouping that describes parameters of an incominglabel and forwardclass of FEC associated with a specific LSP as described in the MPLS architecture document [RFC3031]. The model allows the following types of traffic tonext-hop"; } enum pop-impose-and-forward { description "Operation pop incoming label, impose one or more outgoing label(s) and forwardbe mapped onto the static LSP on an ingress LER: o Unlabeled traffic destined tonext-hop"; } enum swap-and-forward { description "Operation swap incoming label,a specific prefix o Labeled traffic arriving withoutgoing label and forward to next-hop"; } enum pop-and-lookup { description "Operation pop incominga specific labeland performo Traffic carried on alookup"; } } description "MPLS operations types"; }TE tunnel whose LSP is statically created via this model. out-segment: A YANG groupingpath-basic_config { description "common definitions for statics"; leaf next-hop { type inet:ip-address; description "next hop IP addressthat describes parameters for theLSP"; } leaf outgoing-label { type rt-types:mpls-label; description "label value to push at the current hopforwarding path(s) and their associated attributes for an LSP. The model allows for theLSP"; } leaf outgoing-interface { type if:interface-ref; description "The outgoing interface"; } } grouping path-outgoing-labels_config { description "Path outgoing labels grouping"; leaf index { type uint8 { range "0..255"; } description "Index of the label. Index 0 indicates topfollowing cases: o single forwarding path or NHLFE o multiple forwarding path(s) or NHLFE(s), each of which can serve a primary, backup or both role(s). 2.4. Model YANG Module(s) Configuring LSPs through an LSR/LER involves thelabel stack"; } leaf label { type rt-types:mpls-label; description "The outgoingfollowing steps: o Enabling MPLS on MPLSlabelscapable interfaces. o Configuring in-segments and out-segments on LER(s) and LSR(s) traversed by the LSP. o Setting up the cross-connect per LSP toimpose"; } } grouping path-outgoing-labels { description "Path outgoing labels grouping"; container outgoing-labels { description "List of outgoing labels"; list outgoing-labels { key "index"; description "Outgoingassociate segments and/or to indicate connection origination and termination. o Optionally specifying labellist"; leaf index { type leafref { path "../config/index"; } description "Index of the label. Index 0 indicates top ofstack actions. o Optionally specifying segment traffic parameters. The objects covered by this model are derived from thelabel stack"; } container config { description "Configuration intended parameters"; uses path-outgoing-labels_config; } container state { config false; description "Configuration applied parametersIncoming Label Map (ILM) andstate"; uses path-outgoing-labels_config; } } } } grouping path-properties_configNext Hop Label Forwarding Entry (NHLFE) as specified in the MPLS architecture document [RFC3031]. The MPLS Static LSP module is shown in Figure 3. <CODE BEGINS> file "ietf-mpls-static@2018-10-04.yang" module ietf-mpls-static {description "MPLS path properties"; leaf path-indexyang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-static"; prefix "mpls-static"; import ietf-mpls {type uint16; description "Path identifier";prefix "mpls"; reference "draft-ietf-mpls-base-yang: MPLS Base YANG Data Model"; }leaf backup-path-indeximport ietf-routing {type uint16; description "Backup path identifier";prefix "rt"; reference "RFC8349: A YANG Data Model for Routing Management"; }leaf next-hopimport ietf-routing-types {type inet:ip-address; description "The address of the next-hop";prefix "rt-types"; reference "RFC6991: Common YANG Data Types"; }leaf outgoing-interfaceimport ietf-inet-types {type if:interface-ref; description "The outgoing interface";prefix inet; reference "RFC6991: Common YANG Data Types"; }leaf loadshareimport ietf-interfaces {type uint16; description "This value is used to compute a loadshare to perform un-equal load balancing when multiple outgoing path(s) are specified.prefix "if"; reference "RFC7223: Ashare is computed as a ratio of this number to the total under all configured path(s)."; } leaf role { type enumeration { enum PRIMARY { description "Path as primary traffic carrying"; } enum BACKUP { description "Path acts as backup";YANG Data Model for Interface Management"; }enum PRIMARY_AND_BACKUP/* Import TE Tunnel */ import ietf-te {description "Path acts as primaryprefix te; reference "draft-ietf-teas-yang-te: A YANG Data Model for Traffic Engineering Tunnels andbackup simultaneously"; } } description "The MPLS path role"; }Interfaces"; }grouping static-lsp-paths { description "Static LSP path grouping"; choice out-segment { description "Theorganization "IETF MPLSout-segment type choice"; case simple-path { container simple-path { description "Simple path container"; container config { description "Holds the intended configuration"; uses path-basic_config; } container state { config false;Working Group"; contact "WG Web: <http://tools.ietf.org/wg/mpls/> WG List: <mailto:mpls@ietf.org> WG Chair: Loa Andersson <mailto:loa@pi.nu> Editor: Tarek Saad <mailto:tsaad@cisco.com> Editor: Kamran Raza <mailto:skraza@cisco.com> Editor: Rakesh Gandhi <mailto:rgandhi@cisco.com> Editor: Xufeng Liu <mailto: xufeng.liu.ietf@gmail.com> Editor: Vishnu Pavan Beeram <mailto:vbeeram@juniper.net> Editor: Himanshu Shah <mailto:hshah@ciena.com> Editor: Igor Bryskin <mailto: Igor.Bryskin@huawei.com>"; description"Holds"This YANG module augments thestate and inuse configuration"; uses path-basic_config; } } } case multiple-paths { container paths { description "List of outgoing paths"; list path'ietf-routing' module with basic configuration and operational state data for MPLS static"; revision "2018-10-04" {key path-index;description"The list of MPLS paths associated with the FEC"; leaf path-index"Latest revision: - Addressed MPLS-RT review comments"; reference "RFC 3031: Multiprotocol Label Switching Architecture"; } typedef static-lsp-ref { type leafref { path"../config/path-index";"/rt:routing/mpls:mpls/mpls-static:static-lsps/" + "mpls-static:static-lsp/mpls-static:name"; } description"Index of the path";"This type is used by data models that need to reference configured static LSP."; }container configgrouping in-segment { description"Holds the intended configuration"; uses path-properties_config; }"In-segment grouping"; containerstatein-segment {config false;description"Holds the state and inuse configuration"; uses path-properties_config; } } uses path-outgoing-labels; } } } } grouping in-segment_config"MPLS incoming segment"; container fec { description"In-segment"Forwarding Equivalence Class grouping"; choice type { description"Basic FEC choice";"FEC type choices"; case ip-prefix { leaf ip-prefix { type inet:ip-prefix; description "An IP prefix"; } } case mpls-label { leaf incoming-label { type rt-types:mpls-label; description "label value on the incoming packet"; } } case tunnel { leaf tunnel { type te:tunnel-ref; description "TE tunnel FEC mapping"; } } } leaf incoming-interface { type if:interface-ref; description "Optional incoming interface if FEC is restricted to traffic incoming on a specific interface"; } } } } groupingin-segmentout-segment { description"In-segment"Out-segment grouping"; containerin-segmentout-segment { description "MPLSincomingoutgoing segment";container configchoice out-segment { description"Holds the intended configuration"; uses in-segment_config; }"The MPLS out-segment type choice"; case nhlfe-single { containerstatenhlfe-single {config false;description"Holds the state and inuse configuration";"Container for single NHLFE entry"; usesin-segment_config; } } } grouping static-lsp-top_config { description "Static LSP configuration grouping"; leaf name { type string; description "name to identify the LSP"; }mpls:nhlfe-single-contents; leafoperationoutgoing-interface { typempls-operations-type;if:interface-ref; description "TheMPLS operation to be executed on the incoming packet";outgoing interface"; } }grouping static-lsp-top} case nhlfe-multiple { container nhlfe-multiple { description"common definitions"Container forstatic LSPs"; container configmultiple NHLFE entries"; list nhlfe { key index; description"Holds the intended configuration";"MPLS NHLFE entry"; usesstatic-lsp-top_config; } container statempls:nhlfe-multiple-contents; leaf outgoing-interface {config false;type if:interface-ref; description"Holds the state and inuse configuration"; uses static-lsp-top_config;"The outgoing interface"; } } } } } } } augment "/rt:routing/mpls:mpls" { description "Augmentations for MPLS Static LSPs"; container static-lsps { description "Statically configured LSPs, without dynamic signaling"; list static-lsp { key name; description "list of defined static LSPs"; leaf name { typeleafref { path "../config/name"; }string; description "name to identify the LSP"; } leaf operation { type mpls:mpls-operations-type; description "The MPLS operation to be executed on the incoming packet"; } usesstatic-lsp-top;in-segment; usesstatic-lsp-paths;out-segment; } } } } <CODE ENDS> Figure 3: MPLS Static LSP YANG module The extended MPLS Static LSP module is shown in Figure 4. <CODE BEGINS> file"ietf-mpls-static-extended@2017-07-02.yang""ietf-mpls-static-extended@2018-10-04.yang" module ietf-mpls-static-extended { namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-static-extended"; prefix "mpls-static-ext"; import ietf-mpls { prefix "mpls"; } import ietf-routing { prefix "rt"; } import ietf-mpls-static { prefix "mpls-static"; } organization "IETF MPLS Working Group"; contact "WG Web: <http://tools.ietf.org/wg/mpls/> WG List: <mailto:mpls@ietf.org> WG Chair: Loa Andersson <mailto:loa@pi.nu>WG Chair: Ross Callon <mailto:rcallon@juniper.net> WG Chair: George Swallow <mailto:swallow.ietf@gmail.com>Editor: Tarek Saad <mailto:tsaad@cisco.com> Editor: Kamran Raza <mailto:skraza@cisco.com> Editor: Rakesh Gandhi <mailto:rgandhi@cisco.com> Editor: Xufeng Liu <mailto: xufeng.liu.ietf@gmail.com> Editor: Vishnu Pavan Beeram <mailto:vbeeram@juniper.net> Editor: Himanshu Shah <mailto:hshah@ciena.com> Editor: Igor Bryskin <mailto:Igor.Bryskin@huawei.com> Editor: Xia Chen <mailto:jescia.chenxia@huawei.com> Editor: Raqib Jones <mailto:raqib@Brocade.com> Editor: Bin Wen <mailto:Bin_Wen@cable.comcast.com>";Igor.Bryskin@huawei.com>"; description "This module contains the Extended MPLS YANG data model."; revision2017-03-10"2018-10-04" { description "Latest revision of MPLS extended yang module."; reference"RFC2205"; } /* RSVP features */ feature bandwidth { description "Indicates support for static LSP bandwidth allocation"; } grouping static-lsp-extended_config { description "Configuration parameters for MPLS extended parameters"; leaf bandwidth { type uint32; description "bandwidth in Mbps, e.g., using offline calculation"; } leaf lsp-priority-setup { type uint8 { range "0..7"; } description "LSP setup priority";"RFC2205"; }leaf lsp-priority-hold { type uint8/* RSVP features */ feature bandwidth {range "0..7"; }description"LSP hold priority"; }"Indicates support for static LSP bandwidth allocation"; } groupingbidir-static-lsp_configbidir-static-lsp { description"common definitions"grouping for top level list of static bidirectional LSPs"; leaf forward-lsp { type mpls-static:static-lsp-ref; description "Reference to a configured static forward LSP"; } leaf reverse-lsp { type mpls-static:static-lsp-ref; description "Reference to a configured static reverse LSP"; } }grouping bidir-static-lspaugment "/rt:routing/mpls:mpls/mpls-static:static-lsps" { description"grouping"Augmentation fortop level list ofstatic MPLS LSPs";container configleaf bandwidth { type uint32; description"Holds the intended configuration"; uses bidir-static-lsp_config;"bandwidth in Mbps, e.g., using offline calculation"; }container stateleaf lsp-priority-setup {config false; description "Holds the state and inuse configuration"; uses bidir-static-lsp_config;type uint8 { range "0..7"; } description "LSP setup priority"; }augment "/rt:routing/mpls:mpls/mpls-static:static-lsps"leaf lsp-priority-hold { type uint8 { range "0..7"; } description"RSVP signaling all interfaces configuration extensions"; uses static-lsp-extended_config;"LSP hold priority"; } } augment "/rt:routing/mpls:mpls" { description "Augmentations for MPLS Static LSPs"; container bidir-static-lsps { description "Statically configured LSPs, without dynamic signaling"; list bidir-static-lsp { key name; description "list of defined static LSPs"; leaf name { type string; description "name to identify the LSP"; } uses bidir-static-lsp; } } } } <CODE ENDS> Figure 4: Extended MPLS Static LSP YANG module2.3. IANA Considerations This document registers the following URIs in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-mpls-static XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-mpls-static-extended XML: N/A, the requested URI is an XML namespace. This document registers two YANG modules in the YANG Module Names registry [RFC6020]. name: ietf-mpls-static namespace:urn:ietf:params:xml:ns:yang:ietf- mpls-staticurn:ietf:params:xml:ns:yang:ietf-mpls-static prefix: ietf-mpls-static reference: RFC3031 name:ietf-mpls-static-extenededietf-mpls-static-extended namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-static-extended prefix:ietf- mpls-staticietf-mpls-static reference: RFC30313.4. Security Considerations The YANG module defined in thismemodocument is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. The NETCONF access control model[RFC6536][RFC8341] provides means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content. There area number ofcertain objects or data nodes that are defined inthethis YANG module which are writable/creatable/deletable(i.e., config true, which is the default). These data nodes mayand that can be considered sensitive or vulnerable in some network environments.Write operations (e.g., <edit-config>) to theseSpecifically, misconfiguration or manipulations of objects or datanodes without proper protectionnode(s) defined in this model, including: in-segment(s), out- segment(s) and their associated parameters that collectively allow the provisioning of MPLS LSP(s) and associated parameters on a LSR can potentially havea negative effect on network operations. 4.disastrous results. 5. References 5.1. Normative References[I-D.saad-mpls-static-yang][I-D.ietf-mpls-base-yang] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A YANG Data Model for MPLS Base", draft-ietf-mpls-base- yang-07 (work in progress), October 2018. [I-D.ietf-teas-yang-te] Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H.,Bryskin, I., Chen, X., Jones, R.,andB. Wen,I. Bryskin, "A YANG Data Model forMPLS Static LSPs", draft-saad-mpls-static- yang-03Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang-te-16 (work in progress),May 2016.July 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.[RFC6536][RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, <https://www.rfc-editor.org/info/rfc8294>. [RFC8341] Bierman, A. and M. Bjorklund, "Network ConfigurationProtocol (NETCONF)Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>. [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>. [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>. 5.2. Informative References [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC6536,8340, DOI10.17487/RFC6536,10.17487/RFC8340, March2012, <https://www.rfc-editor.org/info/rfc6536>.2018, <https://www.rfc-editor.org/info/rfc8340>. Authors' Addresses Tarek Saad Cisco Systems, Inc. Email: tsaad@cisco.com Kamran Raza Cisco Systems, Inc. Email: skraza@cisco.com Rakesh Gandhi Cisco Systems, Inc. Email: rgandhi@cisco.com Xufeng LiuJabilVolta Networks Email:Xufeng_Liu@jabil.comxufeng.liu.ietf@gmail.com Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net Himanshu Shah Ciena Email: hshah@ciena.com Igor Bryskin Huawei Technologies Email: Igor.Bryskin@huawei.com