MPLS / TE Model for Service Provider Networks
draft-openconfig-mpls-consolidated-model-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2015-03-09
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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

   <CODE BEGINS> 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
   }
   <CODE ENDS>

   <CODE BEGINS> 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

   }
   <CODE ENDS>

6.2.  MPLS LSP submodules

   <CODE BEGINS> 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

   <CODE ENDS>

   <CODE BEGINS> 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

   }
   <CODE ENDS>

   <CODE BEGINS> 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

   }
   <CODE ENDS>

6.3.  MPLS signaling protocol modules

   <CODE BEGINS> 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

   }
   <CODE ENDS>

   <CODE BEGINS> 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

   }
   <CODE ENDS>

   <CODE BEGINS> 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

   }
   <CODE ENDS>

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]