Network Working Group J. George Internet-Draft Google Intended status: Informational L. Fang Expires: September 10, 2015 Microsoft E. Osborne Level 3 R. Shakir BT March 9, 2015 MPLS / TE Model for Service Provider Networks draft-openconfig-mpls-consolidated-model-00 Abstract This document defines a framework for a YANG data model for configuring and managing label switched paths, including the signaling protocols, traffic engineering, and operational aspects based on carrier and content provider operational requirements. 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 http://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 on September 10, 2015. Copyright Notice Copyright (c) 2015 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 (http://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 George, et al. Expires September 10, 2015 [Page 1] Internet-Draft MPLS / TE Model March 2015 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. 1. Introduction This document describes a YANG [RFC6020] data model for MPLS and traffic engineering, covering label switched path (LSP) configuration, as well as signaling protocol configuration. The model is intended to be vendor-neutral, in order to allow operators to manage MPLS in heterogeneous environments with routers supplied by multiple vendors. The model is also intended to be readily mapped to existing implementations, however, to facilitate support from as large a set of routing hardware and software vendors as possible. 1.1. Goals and approach The focus area of the first version of the model is to set forth a framework for MPLS, with hooks into which information specific to various signaling-protocols can be added. The framework is built around functionality from a network operator perspective rather than a signaling protocol-centric approach. For example, a traffic- engineered LSP will have configuration relating to its path computation method, regardless of whether it is signaled with RSVP-TE or with segment routing. Thus, rather than creating separate per- signaling protocol models and trying to stitch them under a common umbrella, this framework focuses on functionality, and adds siginaling protocol-specific information under it where applicable. This model does not (in the current iteration) aim to be feature complete (i.e., cover all possible aspects or features of MPLS). Rather its development is driven by examination of actual production configurations in use across a number of operator network deployments. Configuration items that are deemed to be widely available in existing major implementations are included in the model. Those configuration items that are only available from a single implementation are omitted from the model with the expectation they will be available in companion modules that augment the current model. This allows clarity in identifying data that is part of the vendor-neutral model. Where possible, naming in the model follows conventions used in available standards documents, and otherwise tries to be self- explanatory with sufficient descriptions of the intended behavior. Similarly, configuration data value constraints and default values, George, et al. Expires September 10, 2015 [Page 2] Internet-Draft MPLS / TE Model March 2015 where used, are based on recommendations in current standards documentation. Since implementations vary widely in this respect, this version of the model specifies only a limited set of defaults and ranges with the expectation of being more prescriptive in future versions based on actual operator use. Note that this version of the model is a work-in-progress in several respects. Although we present a complete framework for MPLS and traffic engineering from an operational perspective, some signaling protocol configuration will be completed in future revisions. In addition, operational state data for MPLS LSPs is not included in this version, but will be added in the next revision. 2. Model overview The overall MPLS model is defined across several YANG modules and submodules but at a high level is organized into 3 main sections: o global -- configuration affecting MPLS behavior which exists independently of the underlying signaling protocol or label switched path configuration. o signaling protocols -- configuration specific to signaling protocols used to setup and manage label switched paths. o label switched paths -- configuration specific to instantiating and managing individual label switched paths. The top level of the model is shown in the tree view below: +--rw mpls! +--rw global | ... +--rw signaling-protocols | ... +--rw lsps ... 2.1. MPLS global overview The global section of the framework provides configuration control for MPLS items which exist independently of an individual label switched path or signaling protocol. These standalone items are applicable to the entire logical routing device, and establish fundamental configuration such as specific device interfaces where MPLS forwarding will be permitted. Timers are also specified which determine the length of time an LSP must be present before considered viable for forwarding use (mpls-lsp-install-delay), and the length of George, et al. Expires September 10, 2015 [Page 3] Internet-Draft MPLS / TE Model March 2015 time between LSP teardown and removal of the LSP from the network element's forwarding information base (mpls-lsp-cleanup- delay). Also specified are the name to value mappings of MPLS administrative groups (mpls-admin-groups). +--rw mpls! +--rw global +--rw mpls-interfaces* [interface-name] | +--rw interface-name string | +--rw interface-admin-groups* -> /mpls/global/... +--rw mpls-lsp-install-delay? uint16 +--rw mpls-lsp-cleanup-delay? uint16 +--rw mpls-admin-groups* [admin-group-name] +--rw admin-group-name string +--rw admin-group-value? uint32 2.2. Signaling protocol overview The signaling protocol section of the framework provides configuration elements for configuring three major methods of signaling label switched paths: RSVP, segment routing, and label distribution protocol (LDP). Configuration of RSVP is centered around interfaces on the device which participate in the protocol. A key focus is to expose common RSVP configuration parameters which are used to enhance scale and reliability (refresh-reduction, refresh- reduction-reliable). From the same principles, configuration is available to configure the sensitivity of IGP flooding events upon bandwidth change on an RSVP interface (ted-update-threshold). Also specified are options to configure RSVP soft-preemption (soft- preemption), and for MPLS protection (link-protection). Containers for specifying signaling via segment routing and LDP are also present. Specific subelements will be added for those protocols, as well as for BGP labeled unicast, in the next revision. George, et al. Expires September 10, 2015 [Page 4] Internet-Draft MPLS / TE Model March 2015 +--rw mpls! +--rw signaling-protocols +--rw rsvp | +--rw interfaces* [interface-name] | | +--rw interface-name string | | +--rw hello-interval? uint16 | | +--rw refresh-reduction? boolean | | +--rw refresh-reduction-reliable? boolean | | +--rw subscription? mplst:percentage | | +--rw ted-update-threshold? mplst:percentage | | +--rw link-protection! | | +--rw link-protection-only? boolean | | +--rw bypass-optimize-interval? uint16 | +--rw soft-preemption! | +--rw soft-preemption-timeout? uint16 +--rw segment-routing +--rw ldp +--rw timers 2.3. LSP overview This part of the framework contains LSP information. At the high level, LSPs are split into three categories: traffic-engineering- capable (constrained-path), non-traffic-engineered determined by the IGP (unconstrained-path), and hop-by-hop configured (static). +--rw mpls! +--rw lsps +--rw constrained-path | ... +--rw unconstrained-path | ... +--rw static-lsps ... The first two categories, constrained-path and unconstrained-path are the ones for which multiple signaling protocols exist, and are organized in protocol-specific and protocol-independent sections. For example, traffic-engineered, constrained path, LSPs may be set up using RSVP-TE or segment routing, and unconstrained LSPs that follow the IGP path may be signaled with LDP or with segment routing. IGP- determined LSPs may also be signaled by RSVP but this usage is not considered in the current version of the model. A portion of the data model for constrained path traffic-engineered LSPs is shown below: George, et al. Expires September 10, 2015 [Page 5] Internet-Draft MPLS / TE Model March 2015 +--rw mpls! +--rw lsps +--rw constrained-path +--rw path-information | +--rw path* [path-name] | +--rw path-name string | +--rw hop* [address] | ... +--rw label-switched-path* [signaled-name] +--rw signaled-name string +--rw lsp-description? string +--rw path-computation-method | +--rw path-computation? identityref | +--rw explicit-path | | ... | +--rw queried-path | | ... | +--rw locally-computed | ... +--rw path-attributes | +--rw metric? te-metric-type | +--rw bandwidth | | ... | +--rw lsp-placement-constraints | | ... | +--rw protection | ... +--rw path-setup +--rw rsvp! | ... +--rw segment-routing! ... Similarly, the partial model for non-traffic-engineered, or IGP- based, LSPs is shown below: +--rw mpls! +--rw lsps +--rw unconstrained-path +--rw path-setup-protocol +--rw ldp! | ... +--rw segment-routing! ... George, et al. Expires September 10, 2015 [Page 6] Internet-Draft MPLS / TE Model March 2015 3. Example use cases 3.1. Traffic engineered p2p LSP signaled with RSVP A possible scenario may be the establishment of a mesh of traffic- engineered LSPs where RSVP signaling is desired, and the LSPs use a local constrained path calculation to determine their path. These LSPs would fall into the category of a constrained-path LSP. The LSP will specify the path setup method as RSVP inside the path-setup container, indicating the LSP desires RSVP signaling. The LSP would be configured as locally-computed under the path-computation-method container, specifying the use of cspf (use-cspf). Additional attributes such as bandwidth (explicit or auto), protection style, and placement constraints are available in the path-attributes container. The structure to support these is shown in the constrained-path portion of the data model below: George, et al. Expires September 10, 2015 [Page 7] Internet-Draft MPLS / TE Model March 2015 +--rw mpls! +--rw lsps +--rw constrained-path +--rw path-information | +--rw path* [path-name] | +--rw path-name string | +--rw hop* [address] | ... +--rw label-switched-path* [signaled-name] +--rw signaled-name string +--rw lsp-description? string +--rw path-computation-method | +--rw path-computation? identityref | +--rw explicit-path | | ... | +--rw queried-path | | ... | +--rw locally-computed | ... +--rw path-attributes | +--rw metric? te-metric-type | +--rw bandwidth | | ... | +--rw lsp-placement-constraints | | ... | +--rw protection | ... +--rw path-setup +--rw rsvp! | ... +--rw segment-routing! ... 3.2. Traffic engineered LSP signaled with SR A possible scenario may be the establishment of disjoint paths in a network where there is no requirement for per-LSP state to be held on midpoint nodes within the network, or RSVP-TE is unsuitable (as described in [I-D.ietf-spring-segment-routing-mpls] and [I-D.shakir-rtgwg-sr-performance-engineered-lsps]). Such LSPs fall in the constrained-path category. Similar to any other traffic engineered LSPs, the path computation method must be specified. Path attributes, such as the as lsp- placement-constraints (expressed as administrative groups) or metric must be defined. Finally, the path must be specified in a signaling- protocol specific manner appropriate for SR. The same configuration elements from the tree above apply in this case, except that path setup is done by the head- end by building a label stack, rather than signaled. George, et al. Expires September 10, 2015 [Page 8] Internet-Draft MPLS / TE Model March 2015 3.3. IGP-congruent LDP-signaled LSP A possible scenario may be the establishment of a full mesh of LSPs. When traffic engineering is not an objective, no constraints are placed on the end-to-end path, and the best- effort path can be setup using LDP signaling simply for label distribution. The LSPs follow IGP-computed paths, and fall in the unconstrained-path category in the model. Protocol-specific configuration pertaining to the signaling protocol used, such as the FEC definition and metrics assigned are in the path- setup-protocol portion of the model. The relevant part of the model for this case is shown below: +--rw mpls! +--rw lsps +--rw unconstrained-path +--rw path-setup-protocol +--rw ldp! +--rw tunnel +--rw tunnel-type? mplst:tunnel-type +--rw ldp-type? enumeration +--rw p2p-lsp | +--rw fec-address* inet:ip-prefix +--rw p2mp-lsp +--rw mp2mp-lsp A common operational issue encountered when using LDP is traffic blackholing under the following scenario: when an IGP failure occurs, LDP is not aware of it as these are two protocols running independently, resulting in traffic blackholing at the IGP failure point even though LDP is up and running. "LDP-IGP synchronization" [RFC5443] can be used to cost out the IGP failing point/segment to avoid the blackholing issue. The LDP-IGP synchronization function will be incorporated in a future version of this document. Note that targeted LDP sessions are not discussed in this use case, and will be incorporated as a separate use case in a future version of this document. 4. Security Considerations MPLS configuration has a significant impact on network operations, and as such any related protocol or model carries potential security risks. YANG data models are generally designed to be used with the NETCONF protocol over an SSH transport. This provides an authenticated and secure channel over which to transfer BGP configuration and George, et al. Expires September 10, 2015 [Page 9] Internet-Draft MPLS / TE Model March 2015 operational data. Note that use of alternate transport or data encoding (e.g., JSON over HTTPS) would require similar mechanisms for authenticating and securing access to configuration data. Most of the data elements in the configuration model could be considered sensitive from a security standpoint. Unauthorized access or invalid data could cause major disruption. 5. IANA Considerations This YANG data model and the component modules currently use a temporary ad-hoc namespace. If and when it is placed on redirected for the standards track, an appropriate namespace URI will be registered in the IETF XML Registry" [RFC3688]. The MPLS YANG modules will be registered in the "YANG Module Names" registry [RFC6020]. 6. YANG modules The modules and submodules comprising the MPLS configuration and operational model are currently organized as depcited below. +-------+ +---------------->| MPLS |<--------------+ | +-------+ | | ^ | | | | +----+-----+ +--------+-------+ +-----+-----+ | TE LSPs | | IGP-based LSPs | |static LSPs| | | | | | | +----------+ +----------------+ +-----------+ ^ ^ ^ ^ | +----------------+ | +--------+ | | | | | +------+ +-+---+-+ +--+--+ +---+ RSVP | |SEGMENT| | LDP | +------+ |ROUTING| +-----+ +-------+ The base MPLS module includes submodules describing the three different types of support LSPs, i.e., traffic-engineered (constrained-path), IGP congruent (unconstrained-path), and static. The signaling protocol specific parts of the model are described in separate modules for RSVP, segment routing, and LDP. As mentioned earlier, support for BGP labeled unicast is also planned in a future revision. George, et al. Expires September 10, 2015 [Page 10] Internet-Draft MPLS / TE Model March 2015 A module defining various reusable MPLS types is included, and these modules also make use of the standard Internet types, such as IP addresses, as defined in RFC 6991 [RFC6991]. 6.1. MPLS base modules file mpls.yang module mpls { yang-version "1"; // namespace namespace "http://openconfig.net/yang/mpls"; prefix "mpls"; // import some basic types import mpls-types { prefix mplst; } import mpls-rsvp { prefix rsvp; } import mpls-sr { prefix sr; } import mpls-ldp { prefix ldp; } // include submodules include mpls-te; include mpls-igp; include mpls-static; // meta organization "OpenConfig working group"; contact "OpenConfig working group netopenconfig@googlegroups.com"; description "This module provides data definitions for configuration of Multiprotocol Label Switching (MPLS) and associated protocols for signaling and traffic engineering. RFC 3031: Multiprotocol Label Switching Architecture The MPLS / TE data model consists of several modules and submodules as shown below. The top-level MPLS module describes the overall framework. Three types of LSPs are supported: i) traffic-engineered (or constrained-path) George, et al. Expires September 10, 2015 [Page 11] Internet-Draft MPLS / TE Model March 2015 ii) IGP-congruent (LSPs that follow the IGP path) iii) static LSPs which are not signaled The structure of each of these LSP configurations is defined in corresponding submodules. Companion modules define the relevant configuration and operational data specific to key signaling protocols used in operational practice. +-------+ +---------------->| MPLS |<--------------+ | +-------+ | | ^ | | | | +----+-----+ +--------+-------+ +-----+-----+ | TE LSPs | | IGP-based LSPs | |static LSPs| | | | | | | +----------+ +----------------+ +-----------+ ^ ^ ^ ^ | +----------------+ | +--------+ | | | | | +------+ +-+---+-+ +--+--+ +---+ RSVP | |SEGMENT| | LDP | +------+ |ROUTING| +-----+ +-------+ "; revision "2014-12-12" { description "Initial revision"; reference "TBD"; } // extension statements // feature statements // identity statements // grouping statements grouping path-setup-common { description "common definitions for all signaling protocols"; // TODO: not clear we really need this leaf path-setup-type { George, et al. Expires September 10, 2015 [Page 12] Internet-Draft MPLS / TE Model March 2015 type identityref { base mplst:path-setup-protocol; } description "path setup protocol to use with the LSP"; } } grouping mpls-administrative-groups { description "global level definitions for MPLS link admin groups"; list mpls-admin-groups { key admin-group-name; description "configuration of value to name mapping for mpls affinities/admin-groups"; leaf admin-group-name { type string; description "name for mpls admin-group"; } leaf admin-group-value { type uint32; description "value for mpls admin-group"; } } } grouping mpls-global { description "global level definitions for MPLS protocol operation"; // TODO: this should be made a reference to an interface in the // interfaces model // TODO - should probably have as key the interface name, also // need an easy way to specify all interfaces and to exclude // interfaces. list mpls-interfaces { key interface-name; description "interfaces for which MPLS is enabled"; leaf interface-name { type string; George, et al. Expires September 10, 2015 [Page 13] Internet-Draft MPLS / TE Model March 2015 description "reference to interface name"; // TODO: add ref to interface model } leaf-list interface-admin-groups { type leafref { path "/mpls:mpls/mpls:global/mpls:mpls-admin-groups/" + "mpls:admin-group-name"; } description "list of configured admin-groups on the interface"; } } leaf mpls-lsp-install-delay { type uint16 { range 0..3600; } units seconds; description "delay the use of newly installed lsp for a specified amount of time."; } leaf mpls-lsp-cleanup-delay { type uint16; units seconds; description "delay the removal of old lsp for a specified amount of time"; } } container mpls { presence "top-level container for MPLS config and operational state"; description "Anchor point for mpls configuration and operational data"; container global { description "general mpls configuration across LSP and tunnel types"; uses mpls-global; uses mpls-administrative-groups; } container signaling-protocols { George, et al. Expires September 10, 2015 [Page 14] Internet-Draft MPLS / TE Model March 2015 description "top-level signaling protocol configuration"; uses rsvp:rsvp-global; uses sr:sr-global; uses ldp:ldp-global; } container lsps { description "LSP definitions and configuration"; container constrained-path { description "traffic-engineered LSPs supporting different path computation and signaling methods"; uses mpls-te-global; uses path-definitions; list label-switched-path { key signaled-name; description "list of defined TE LSPs"; uses te-lsp-common; uses te-lsp-setup; } } container unconstrained-path { description "LSPs that use the IGP-determined path, i.e., non traffic-engineered, or non constrained-path"; uses igp-lsp-common; uses igp-lsp-setup; } container static-lsps { description "statically configured LSPs, without dynamic signaling"; uses static-lsp-main; } } } // augment statements // rpc statements George, et al. Expires September 10, 2015 [Page 15] Internet-Draft MPLS / TE Model March 2015 // notification statements } file mpls-types.yang module mpls-types { yang-version "1"; // namespace namespace "http://openconfig.net/yang/mpls-types"; prefix "mplst"; // meta organization "OpenConfig working group"; contact "OpenConfig working group netopenconfig@googlegroups.com"; description "General types for MPLS / TE data model"; revision "2015-02-01" { description "Initial revision"; reference "TBD"; } // extension statements // feature statements // identity statements // using identities rather than enum types to simplify adding new // signaling protocols as they are introduced and supported identity path-setup-protocol { description "base identity for supported MPLS signaling protocols"; } identity path-setup-rsvp { base path-setup-protocol; George, et al. Expires September 10, 2015 [Page 16] Internet-Draft MPLS / TE Model March 2015 description "RSVP-TE signaling protocol"; } identity path-setup-sr { base path-setup-protocol; description "Segment routing"; } identity path-setup-ldp { base path-setup-protocol; description "lDP - RFC 5036"; } // typedef statements typedef percentage { type uint8 { range "0..100"; } description "Integer indicating a percentage value"; } typedef mpls-label { type union { type uint32 { range 16..1048575; } type enumeration { enum IPV4_EXPLICIT_NULL { value 0; description "valid at the bottom of the label stack, indicates that stack must be popped and packet forwarded based on IPv4 header"; } enum ROUTER_ALERT { value 1; description "allowed anywhere in the label stack except the bottom, local router delivers packet to the local CPU when this label is at the top of the stack"; } enum IPV6_EXPLICIT_NULL { value 2; description "valid at the bottom of the label stack, indicates that stack must be popped and packet forwarded based on IPv6 header"; } George, et al. Expires September 10, 2015 [Page 17] Internet-Draft MPLS / TE Model March 2015 enum IMPLICIT_NULL { value 3; description "assigned by local LSR but not carried in packets"; } enum ENTROPY_LABEL_INDICATOR { value 7; description "Entropy label indicator, to allow an LSR to distinguish between entropy label and applicaiton labels RFC 6790"; } } } description "type for MPLS label value encoding"; reference "RFC 3032 - MPLS Label Stack Encoding"; } typedef tunnel-type { type enumeration { enum P2P { description "point-to-point label-switched-path"; } enum P2MP { description "point-to-multipoint label-switched-path"; } enum MP2MP { description "multipoint-to-multipoint label-switched-path"; } } description "defines the tunnel type for the LSP"; reference "RFC 6388 - Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths RFC 4875 - Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"; } // grouping statements // data definition statements // augment statements // rpc statements // notification statements George, et al. Expires September 10, 2015 [Page 18] Internet-Draft MPLS / TE Model March 2015 } 6.2. MPLS LSP submodules file mpls-te.yang submodule mpls-te { yang-version "1"; belongs-to "mpls" { prefix "mpls"; } // import some basic types import ietf-inet-types { prefix inet; } import mpls-types { prefix mplst; } import mpls-rsvp { prefix rsvp; } import mpls-sr { prefix sr; } // meta organization "OpenConfig working group"; contact "OpenConfig working group netopenconfig@googlegroups.com"; description "Configuration related to constrained-path LSPs and traffic engineering. These definitions are not specific to a particular signaling protocol or mechanism (see related submodules for signaling protocol-specific configuration)."; revision "2014-07-07" { description "Initial revision"; reference "TBD"; } // extension statements // feature statements // identity statements George, et al. Expires September 10, 2015 [Page 19] Internet-Draft MPLS / TE Model March 2015 // using identities for path comp method, though enums may also // be appropriate if we decided these are the primary computation // mechanisms in future. identity path-computation-method { description "base identity for supported path computation mechanisms"; } identity locally-computed { base path-computation-method; description "indicates a constrained-path LSP in which the path is computed by the local LER"; } identity externally-queried { base path-computation-method; description "constrained-path LSP in which the path is obtained by querying an external source, such as a PCE server"; } identity explicitly-defined { base path-computation-method; description "constrained-path LSP in which the path is explicitly specified as a collection of strict or/and loose hops"; } // typedef statements typedef mpls-hop-type { type enumeration { enum LOOSE { description "loose hop in an explicit path"; } enum STRICT { description "strict hop in an explicit path"; } } description "enumerated type for specifying loose or strict paths"; } typedef te-metric-type { type union { type enumeration { enum IGP { description "set the LSP metric to track the underlying IGP metric"; George, et al. Expires September 10, 2015 [Page 20] Internet-Draft MPLS / TE Model March 2015 } } type uint32; } description "union type for setting the LSP TE metric to a static value, or to track the IGP metric"; } typedef cspf-tie-breaking { type enumeration { enum RANDOM { description "CSPF calculation selects a random path among multiple equal-cost paths to the destination"; } enum LEAST_FILL { description "CSPF calculation selects the path with greatest available bandwidth"; } enum MOST_FILL { description "CSPF calculation selects the path with the least available bandwidth"; } } default RANDOM; description "type to indicate the CSPF selection policy when multiple equal cost paths are available"; } typedef mpls-protection-style { type enumeration { enum UNPROTECTED { description "no protection is desired for the lsp"; } enum LINK-PROTECTION-REQUESTED { description "link protection is desired for the lsp"; } enum LINK-NODE-PROTECTION-REQUESTED { description "node and link protection is desired for the lsp"; } } default UNPROTECTED; description "Specifies the protection type for the LSP"; } // grouping statements grouping te-lsp-common { George, et al. Expires September 10, 2015 [Page 21] Internet-Draft MPLS / TE Model March 2015 description "common definitions for traffic-engineered LSPs"; leaf signaled-name { type string; description "LSP name, also carried in signaling messages when appropriate"; } leaf lsp-description { type string; description "optional text description for the LSP"; } container path-computation-method { description "select and configure the way the LSP path is computed"; leaf path-computation { type identityref { base path-computation-method; } description "path computation method to use with the LSP"; } uses te-lsp-comp-explicit; uses te-lsp-comp-queried; uses te-lsp-comp-local; } container path-attributes { description "general path attribute settings for TE-LSP tunnels"; // XXX - no, this is also there for LDP - also removed the // reference to "igp metric" as this is going to be confusing, // unless we mandate for the LSP to have the same metric as the // Igp, which is going to be hard with some vendors // implementations. leaf metric { type te-metric-type; description "LSP metric, either explicit or IGP"; } container bandwidth { description "bandwidth specification for the LSP"; choice lsp-bandwidth { default explicit; George, et al. Expires September 10, 2015 [Page 22] Internet-Draft MPLS / TE Model March 2015 description "select how bandwidth for the LSP will be specified and managed"; case explicit { leaf set-bandwidth { type uint32; description "set bandwidth explicitly, e.g., using offline calculation"; } } case auto { container auto-bandwidth { presence "presence of this container indicates auto-bandwidth is enabled for the LSP"; description "configure auto-bandwidth operation in which devices automatically adjust bandwidth to meet requirements"; leaf min-bw { type uint32; description "set the minimum bandwidth in Mbps for an auto-bandwidth LSP"; } leaf max-bw { type uint32; description "set the maximum bandwidth in Mbps for an auto-bandwidth LSP"; } leaf adjust-interval { type uint32; description "time in seconds between adjustments to LSP bandwidth"; } leaf adjust-threshold { type mplst:percentage; description "percentage difference between the LSP's specified bandwidth and its current bandwidth allocation -- if the difference is greater than the specified percentage, auto-bandwidth adjustment is triggered"; } container overflow { presence "presence of this element indicates overflow George, et al. Expires September 10, 2015 [Page 23] Internet-Draft MPLS / TE Model March 2015 is configured for the lsp"; description "configuration for mpls lsp bandwidth overflow adjustment"; leaf overflow-threshold { type mplst:percentage; description "bandwidth percentage change to trigger an overflow event"; } leaf trigger-event-count { type uint16; description "number of consecutive overflow sample events needed to trigger an overflow adjustment"; } } container underflow { presence "presence of this element indicates underflow is configured for the lsp"; description "configuration for mpls lsp bandwidth underflow adjustment"; leaf underflow-threshold { type mplst:percentage; description "bandwidth percentage change to trigger and underflow event"; } leaf trigger-event-count { type uint16; description "number of consecutive underflow sample events needed to trigger an underflow adjustment"; } } } } } } container lsp-placement-constraints { description George, et al. Expires September 10, 2015 [Page 24] Internet-Draft MPLS / TE Model March 2015 "constraints on lsp routing such as admin-groups"; container admin-groups { description "Include/Exclude constraints for link affinities"; list exclude-groups { key admin-group-name; description "list of admin-groups to exclude in path calculation"; leaf admin-group-name { type leafref { path "/mpls/global/mpls-admin-groups/" + "admin-group-name"; } description "name of the admin group -- references a defined admin group"; } } list include-all-groups { key admin-group-name; description "list of admin-groups of which all must be included"; leaf admin-group-name { type leafref { path "/mpls/global/mpls-admin-groups/" + "admin-group-name"; } description "name of the admin group -- references a defined admin group"; } } list include-any-groups { key admin-group-name; description "list of admin-groups of which one must be included"; leaf admin-group-name { George, et al. Expires September 10, 2015 [Page 25] Internet-Draft MPLS / TE Model March 2015 type leafref { path "/mpls/global/mpls-admin-groups/" + "admin-group-name"; } description "name of the admin group -- references a defined admin group"; } } } } container protection { description "failure protection properties for the LSP"; leaf protection-style-requested { type mpls-protection-style { } description "style of mpls frr protection desired. both facility backup and one-to-one are options"; } } } } // TODO - note that this is only currently defined for // RSVP-like entities grouping te-lsp-comp-explicit { description "definitions for LSPs in which hops are explicitly specified"; container explicit-path { description "LSP with explicit path specification"; leaf path-name { type leafref { path "/mpls/lsps/constrained-path/" + "path-information/path/path-name"; require-instance true; } description "reference to a defined path"; } } } grouping te-lsp-comp-queried { description "definitons for LSPs computed by querying a remote service, e.g., PCE server"; George, et al. Expires September 10, 2015 [Page 26] Internet-Draft MPLS / TE Model March 2015 container queried-path { description "LSP with path queried from an external server"; leaf path-computation-server { type inet:ip-address; description "Address of the external path computation server"; } } } grouping te-lsp-comp-local { description "definitons for locally-computed LSPs"; container locally-computed { description "LSP with path computed by local ingress LSR"; leaf use-cspf { type boolean; description "Flag to enable CSPF for locally computed LSPs"; } leaf cspf-tiebreaker { type cspf-tie-breaking; description "Determine the tie-breaking method to choose between equally desirable paths during CSFP computation"; } } } grouping path-definitions { description "describe path configuration for specifying LSP hops"; container path-information { description "common information for MPLS path definition"; list path { key path-name; description "specification of LSP path"; leaf path-name { type string; description "identifier for the LSP path"; } George, et al. Expires September 10, 2015 [Page 27] Internet-Draft MPLS / TE Model March 2015 list hop { key address; description "specification of the strict and loose hops in the path"; leaf address { type inet:ip-address; description "router hop for the LSP path"; } leaf type { type mpls-hop-type; description "strict or loose hop"; } } } } } grouping te-lsp-setup { description "signaling protocol configuration for traffic engineered LSPs"; container path-setup { description "select and configure the signaling method for the LSP"; // uses path-setup-common; uses rsvp:te-lsp-rsvp-setup; uses sr:te-lsp-sr-setup; } } grouping mpls-te-global { description "global level defintions for mpls traffic engineered LSPs"; } // data definition statements // augment statements // rpc statements // notification statements } George, et al. Expires September 10, 2015 [Page 28] Internet-Draft MPLS / TE Model March 2015 file mpls-igp.yang submodule mpls-igp { yang-version "1"; belongs-to "mpls" { prefix "mpls"; } // import some basic types import mpls-ldp { prefix ldp; } import mpls-sr { prefix sr; } // meta organization "OpenConfig working group"; contact "OpenConfig working group netopenconfig@googlegroups.com"; description "Configuration generic configuration parameters for IGP-congruent LSPs"; revision "2014-07-07" { description "Initial revision"; reference "TBD"; } // extension statements // feature statements // identity statements // typedef statements // grouping statements grouping igp-lsp-common { George, et al. Expires September 10, 2015 [Page 29] Internet-Draft MPLS / TE Model March 2015 description "common definitions for IGP-congruent LSPs"; // container path-attributes { // description "general path attribute settings for IGP-based // LSPs"; //} } grouping igp-lsp-setup { description "signaling protocol definitions for IGP-based LSPs"; container path-setup-protocol { description "select and configure the signaling method for the LSP"; // uses path-setup-common; uses ldp:igp-lsp-ldp-setup; uses sr:igp-lsp-sr-setup; } } // data definition statements // augment statements // rpc statements // notification statements } file mpls-static.yang submodule mpls-static { yang-version "1"; belongs-to "mpls" { prefix "mpls"; } // import some basic types import mpls-types {prefix mplst; } George, et al. Expires September 10, 2015 [Page 30] Internet-Draft MPLS / TE Model March 2015 import ietf-inet-types { prefix inet; } // meta organization "OpenConfig working group"; contact "OpenConfig working group netopenconfig@googlegroups.com"; description "Defines static LSP configuration"; revision "2015-02-01" { description "Initial revision"; reference "TBD"; } // extension statements // feature statements // identity statements // typedef statements // grouping statements grouping static-lsp-common { description "common definitions for static LSPs"; leaf next-hop { type inet:ip-address; description "next hop IP address for the LSP"; } leaf incoming-label { type mplst:mpls-label; description "label value on the incoming packet"; } leaf push-label { type mplst:mpls-label; description "label value to push at the current hop for the LSP"; } } George, et al. Expires September 10, 2015 [Page 31] Internet-Draft MPLS / TE Model March 2015 grouping static-lsp-main { description "grouping for top level list of static LSPs"; list label-switched-path { key name; description "list of defined static LSPs"; leaf name { type string; description "name to identify the LSP"; } // TODO: separation into ingress, transit, egress may help // to figure out what exactly is configured, but need to // consider whether implementations can support the // separation container ingress { description "Static LSPs for which the router is an ingress node"; uses static-lsp-common; } container transit { description "static LSPs for which the router is a transit node"; uses static-lsp-common; } container egress { description "static LSPs for which the router is a egress node"; uses static-lsp-common; } } } // data definition statements // augment statements // rpc statements // notification statements George, et al. Expires September 10, 2015 [Page 32] Internet-Draft MPLS / TE Model March 2015 } 6.3. MPLS signaling protocol modules file mpls-rsvp.yang module mpls-rsvp { yang-version "1"; // namespace namespace "http://openconfig.net/yang/rsvp"; prefix "rsvp"; // import some basic types import ietf-inet-types { prefix inet; } import mpls-types { prefix mplst; } // meta organization "OpenConfig working group"; contact "OpenConfig working group netopenconfig@googlegroups.com"; description "Configuration for RSVP signaling, including global protocol parameters and LSP-specific configuration for constrained-path LSPs"; revision "2014-07-07" { description "Initial revision"; reference "TBD"; } // extension statements // feature statements // identity statements // typedef statements // grouping statements George, et al. Expires September 10, 2015 [Page 33] Internet-Draft MPLS / TE Model March 2015 grouping rsvp-global { description "Global RSVP protocol configuration"; container rsvp { description "RSVP global signaling protocol configuration"; // interfaces, bw percentages, hello timers, etc goes here"; list interfaces { key interface-name; description "list of per-interface RSVP configurations"; // TODO: update to interface ref -- move to separate // augmentation. leaf interface-name { type string; description "references a configured IP interface"; } leaf hello-interval { type uint16 { range 0..60000; } units milliseconds; description "set the interval in ms between RSVP hello messages"; } // TODO: confirm that the described semantics are supported // on various implementations. Finer grain configuration // will be vendor-specific leaf refresh-reduction { type boolean; default true; description "enables all RSVP refresh reduction message bundling, RSVP message ID, reliable message delivery and summary refresh"; reference "RFC 2961 RSVP Refresh Overhead Reduction Extensions"; } leaf refresh-reduction-reliable { type boolean; default true; description "enables RSVP refresh reduction reliable delivery and message_ID"; reference "RFC 2961 RSVP Refresh Overhead Reduction Extensions"; George, et al. Expires September 10, 2015 [Page 34] Internet-Draft MPLS / TE Model March 2015 } leaf subscription { type mplst:percentage; description "percentage of the interface bandwidth that RSVP can reserve"; } leaf ted-update-threshold { type mplst:percentage; description "percentage of interface bandwidth change that triggers an update event into the IGP TED"; } // TODO: this may need to be moved to common TE LSP config container link-protection { description "link-protection (NHOP) related configuration"; presence "presence of this container indicates facility protection is configured on the interface"; leaf link-protection-only { type boolean; default false; description "disables node protection on this interface, and forces only link protection"; } leaf bypass-optimize-interval { type uint16; units seconds; description "interval between periodic optimization of the bypass LSPs"; // note: this is interface specific on juniper // on iox, this is global. need to resolve. } // to be completed, things like enabling link protection, // optimization times, etc. } } container soft-preemption { description "options relating to RSVP soft preemption"; presence "presence of this container enables RSVP soft preemption on a node"; leaf soft-preemption-timeout { type uint16 { George, et al. Expires September 10, 2015 [Page 35] Internet-Draft MPLS / TE Model March 2015 range 0..300; } default 0; description "timeout value for soft preemption to revert to hard preemption"; } } } } grouping te-tunnel-rsvp { description "defintiions for RSVP-signaled LSP tunnel types, .e.g., applicable to point-to-point LSPs"; container tunnel { description "contains configuration stanzas for different LSP tunnel types (P2P, P2MP, etc.)"; leaf tunnel-type { type mplst:tunnel-type; description "specifies the type of LSP, e.g., P2P or P2MP"; } container p2p-lsp { when "tunnel-type = 'P2P'" { description "container active when LSP tunnel type is point to point"; } description "properties of point-to-point tunnels"; leaf destination { type inet:ip-address; description "destination egress node for the LSP"; } leaf tunnel-local-id { type union { type uint32; type string; } description "locally signficant optional identifier for the LSP; may be a numerical or string value"; } leaf soft-preemption { type boolean; description "enables RSVP soft-preemption on this LSP"; default false; George, et al. Expires September 10, 2015 [Page 36] Internet-Draft MPLS / TE Model March 2015 } } // p2p-lsp container p2mp-lsp { when "tunnel-type = 'P2MP'" { description "container is active when LSP tunnel type is point to multipoint"; } description "properties of point-to-multipoint tunnels"; leaf-list destination { type inet:ip-address; description "list of destinations / egress nodes for the multipoint LSP tunnel"; } } } } grouping te-lsp-rsvp-setup { description "data definitions for RSVP-signalled LSPs"; container rsvp { presence "Presence of this container sets the LSP to use RSVP signaling"; description "Configuration for RSVP-signalled TE LSPs"; container path-specification { description "Definition of primary/backup paths for purpose of signaling the LSP"; } leaf setup-priority { type uint8 { range 0..7; } default 7; description "preemption priority during LSP setup, lower is higher priority; default 7 indicates that LSP will not preempt established LSPs during setup"; } leaf hold-priority { type uint8 { George, et al. Expires September 10, 2015 [Page 37] Internet-Draft MPLS / TE Model March 2015 range 0..7; } default 0; description "preemption priority once the LSP is established, lower is higher priority; default 0 indicates that other LSPs will not preempt the LSPs once established"; } leaf retry-timer { type uint16 { range 1..600; } units seconds; description "sets the time between attempts to establish the LSP"; } //TODO: add other RSPV parms: optimize delay, switchover delay, // etc. // include tunnel (p2p, p2mp, etc). uses te-tunnel-rsvp; } } // data definition statements // augment statements // rpc statements // notification statements } file mpls-sr.yang module mpls-sr { yang-version "1"; // namespace namespace "http://openconfig.net/yang/sr"; prefix "sr"; // import some basic types George, et al. Expires September 10, 2015 [Page 38] Internet-Draft MPLS / TE Model March 2015 import ietf-inet-types { prefix inet; } import mpls-types { prefix mplst; } // meta organization "OpenConfig working group"; contact "OpenConfig working group netopenconfig@googlegroups.com"; description "Configuration for MPLS with segment routing-based LSPs, including global parameters, and LSP-specific configuration for both constrained-path and IGP-congruent LSPs"; revision "2014-07-07" { description "Initial revision"; reference "TBD"; } // extension statements // feature statements // identity statements // typedef statements // grouping statements grouping sr-global { description "global segment routing signaling configuration"; container segment-routing { description "SR global signaling config"; } } grouping te-tunnel-sr { description "defintiions for SR-signaled LSP tunnel types, .e.g., applicable to point-to-point LSPs"; container tunnel { description "contains configuration stanzas for different LSP tunnel types (P2P, P2MP, etc.)"; George, et al. Expires September 10, 2015 [Page 39] Internet-Draft MPLS / TE Model March 2015 leaf tunnel-type { type mplst:tunnel-type; description "specifies the type of LSP, e.g., P2P or P2MP"; } container p2p-lsp { when "tunnel-type = 'P2P'" { description "container active when LSP tunnel type is point to point"; } description "Config for point-to-point tunnels"; // fill out the configuration details per segment // routing requrements } } } grouping te-lsp-sr-setup { description "data definitions for SR signaling"; container segment-routing { presence "Presence of this container sets the LSP to use SR signaling"; description "Configuration for signaling SR-based TE LSPs"; uses te-tunnel-sr; } } grouping igp-tunnel-sr { description "defintiions for SR-signaled, IGP-based LSP tunnel types"; container tunnel { description "contains configuration stanzas for different LSP tunnel types (P2P, P2MP, etc.)"; leaf tunnel-type { type mplst:tunnel-type; description "specifies the type of LSP, e.g., P2P or P2MP"; } container p2p-lsp { George, et al. Expires September 10, 2015 [Page 40] Internet-Draft MPLS / TE Model March 2015 when "tunnel-type = 'P2P'" { description "container active when LSP tunnel type is point to point"; } description "properties of point-to-point tunnels"; leaf-list fec-address { type inet:ip-prefix; description "Address prefix for packets sharing the same forwarding equivalence class for the IGP-based LSP"; } } } } grouping igp-lsp-sr-setup { description "grouping for SR-IGP path setup for IGP-congruent LSPs"; container segment-routing { presence "Presence of this container sets the LSP to use SR signaling"; description "segment routing signaling extensions for IGP-confgruent LSPs"; uses igp-tunnel-sr; } } // data definition statements // augment statements // rpc statements // notification statements } file mpls-ldp.yang module mpls-ldp { yang-version "1"; George, et al. Expires September 10, 2015 [Page 41] Internet-Draft MPLS / TE Model March 2015 // namespace namespace "http://openconfig.net/yang/ldp"; prefix "ldp"; // import some basic types import ietf-inet-types { prefix inet; } import mpls-types { prefix mplst; } // meta organization "OpenConfig working group"; contact "OpenConfig working group netopenconfig@googlegroups.com"; description "Configuration of Label Distribution Protocol global and LSP- specific parameters for IGP-congruent LSPs"; revision "2014-07-07" { description "Initial revision"; reference "TBD"; } // extension statements // feature statements // identity statements // typedef statements // grouping statements grouping ldp-global { description "global LDP signaling configuration"; container ldp { description "LDP global signaling configuration"; container timers { description "LDP timers"; } } } George, et al. Expires September 10, 2015 [Page 42] Internet-Draft MPLS / TE Model March 2015 grouping igp-tunnel-ldp { description "common defintiions for LDP-signaled LSP tunnel types"; container tunnel { description "contains configuration stanzas for different LSP tunnel types (P2P, P2MP, etc.)"; leaf tunnel-type { type mplst:tunnel-type; description "specifies the type of LSP, e.g., P2P or P2MP"; } leaf ldp-type { type enumeration { enum BASIC { description "basic hop-by-hop LSP"; } enum TARGETED { description "tLDP LSP"; } } description "specify basic or targeted LDP LSP"; } container p2p-lsp { when "tunnel-type = 'P2P'" { description "container active when LSP tunnel type is point to point"; } description "properties of point-to-point tunnels"; leaf-list fec-address { type inet:ip-prefix; description "Address prefix for packets sharing the same forwarding equivalence class for the IGP-based LSP"; } } container p2mp-lsp { when "tunnel-type = 'P2MP'" { description "container is active when LSP tunnel type is point to multipoint"; } description "properties of point-to-multipoint tunnels"; George, et al. Expires September 10, 2015 [Page 43] Internet-Draft MPLS / TE Model March 2015 // TODO: specify group/source, etc. } container mp2mp-lsp { when "tunnel-type = 'MP2MP'" { description "container is active when LSP tunnel type is multipoint to multipoint"; } description "properties of multipoint-to-multipoint tunnels"; // TODO: specify group/source, etc. } } } grouping igp-lsp-ldp-setup { description "grouping for LDP setup attributes"; container ldp { presence "Presence of this container sets the LSP to use LDP signaling"; description "LDP signaling setup for IGP-congruent LSPs"; // include tunnel (p2p, p2mp, ...) uses igp-tunnel-ldp; } } // data definition statements // augment statements // rpc statements // notification statements } George, et al. Expires September 10, 2015 [Page 44] Internet-Draft MPLS / TE Model March 2015 7. Contributing Authors The following people contributed significantly to this document and are listed below: Ina Minei Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: inaminei@google.com Anees Shaikh Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: aashaikh@google.com Phil Bedard Cox Communications Atlanta, GA 30319 US Email: phil.bedard@cox.com 8. Acknowledgements The authors are grateful for valuable contributions to this document and the associated models from: Ebben Aires, Deepak Bansal, Nabil Bitar, Feihong Chen, Mazen Khaddam. 9. References [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. George, et al. Expires September 10, 2015 [Page 45] Internet-Draft MPLS / TE Model March 2015 [I-D.ietf-spring-segment-routing-mpls] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., and E. Crabbe, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-00 (work in progress), December 2014. [I-D.shakir-rtgwg-sr-performance-engineered-lsps] Shakir, R., Vernals, D., and A. Capello, "Performance Engineered LSPs using the Segment Routing Data-Plane", draft-shakir-rtgwg-sr-performance-engineered-lsps-00 (work in progress), July 2013. [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009. Authors' Addresses Joshua George Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 US Email: jgeorge@google.com Luyuan Fang Microsoft 205 108th Ave. NE, Suite 400 Bellevue, WA US Email: lufang@microsoft.com Eric Osborne Level 3 Email: eric.osborne@level3.com George, et al. Expires September 10, 2015 [Page 46] Internet-Draft MPLS / TE Model March 2015 Rob Shakir BT pp. C3L, BT Centre 81, Newgate Street London EC1A 7AJ UK Email: rob.shakir@bt.com URI: http://www.bt.com/ George, et al. Expires September 10, 2015 [Page 47]