[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02

TEAS Working Group                                             V. Beeram
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                                 T. Saad
Expires: September 9, 2015                                     R. Gandhi
                                                       Cisco Systems Inc
                                                                  X. Liu
                                                                Ericsson
                                                                 H. Shah
                                                                   Ciena
                                                                 X. Chen
                                                     Huawei Technologies
                                                                R. Jones
                                                                 Brocade
                                                          March 08, 2015


       A YANG Data Model for Resource Reservation Protocol (RSVP)
                      draft-saad-teas-yang-rsvp-00

Abstract

   This document defines a YANG data model for the configuration and
   management of RSVP Protocol.  The model defines generic RSVP protocol
   building blocks that can be augmented and used by other RSVP
   extension models such as RVSP extensions to Traffic-Engineering
   (RSVP-TEE).  The model covers the RSVP protocol configuration,
   operational state, remote procedural calls, and event notifications
   data.

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 9, 2015.






Beeram, et al.          Expires September 9, 2015               [Page 1]


Internet-Draft            RSVP YANG Data Model                March 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
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Tree Diagram  . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Prefixes in Data Node Names . . . . . . . . . . . . . . .   4
     1.4.  Open Issues and Next Steps  . . . . . . . . . . . . . . .   5
   2.  Design Considerations . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Base Model  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Feature Set . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Configuration Inheritance . . . . . . . . . . . . . . . .   6
     2.4.  Vendor Configuration Models . . . . . . . . . . . . . . .   7
   3.  Model Organization  . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  RSVP Configuration Data . . . . . . . . . . . . . . . . .   8
       3.1.1.  Global Configuration Data . . . . . . . . . . . . . .   8
       3.1.2.  Interface Configuration Data  . . . . . . . . . . . .   9
       3.1.3.  Session Configuration Data  . . . . . . . . . . . . .  10
       3.1.4.  Neighbor Configuration Data . . . . . . . . . . . . .  11
     3.2.  RSVP State Data . . . . . . . . . . . . . . . . . . . . .  11
       3.2.1.  Global State Data . . . . . . . . . . . . . . . . . .  11
       3.2.2.  Interface State Data  . . . . . . . . . . . . . . . .  11
       3.2.3.  Neighbor State Data . . . . . . . . . . . . . . . . .  11
       3.2.4.  Session State Data  . . . . . . . . . . . . . . . . .  11
     3.3.  RSVP RPC Data . . . . . . . . . . . . . . . . . . . . . .  12
     3.4.  Global RPC Data . . . . . . . . . . . . . . . . . . . . .  12
       3.4.1.  Interface RPC Data  . . . . . . . . . . . . . . . . .  12
       3.4.2.  Neighbor RPC Data . . . . . . . . . . . . . . . . . .  12
       3.4.3.  Session RPC Data  . . . . . . . . . . . . . . . . . .  12
     3.5.  RSVP Notification Data  . . . . . . . . . . . . . . . . .  12
       3.5.1.  Global Notification Data  . . . . . . . . . . . . . .  12
       3.5.2.  Interface Notification Data . . . . . . . . . . . . .  12
       3.5.3.  Neighbor Notification Data  . . . . . . . . . . . . .  12
       3.5.4.  Session Notification Data . . . . . . . . . . . . . .  13



Beeram, et al.          Expires September 9, 2015               [Page 2]


Internet-Draft            RSVP YANG Data Model                March 2015


   4.  RSVP YANG Module  . . . . . . . . . . . . . . . . . . . . . .  13
   5.  Appendix A: RSVP-TE YANG Model  . . . . . . . . . . . . . . .  20
     5.1.  RSVP-TE Configuration Data  . . . . . . . . . . . . . . .  21
     5.2.  RSVP-TE State Data  . . . . . . . . . . . . . . . . . . .  23
     5.3.  RSVP-TE YANG Module . . . . . . . . . . . . . . . . . . .  23
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
   8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  28
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  28
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   YANG [RFC6020] a data definition language that was introduced to
   define the contents of a conceptual data store that allows networked
   devices to be managed using NETCONF [RFC6241].  YANG is proving
   relevant beyond its initial confines, as bindings to other interfaces
   (e.g.  ReST) and encoding other than XML (e.g.  JSON) are being
   defined.  Furthermore, YANG data models can be used as the basis of
   implementation for other interface, such as CLI and programmatic
   APIs.  This document defines a YANG data model that can be used to
   configure and manage RSVP protocol.  This model covers generic
   protocol building blocks that can be augmented and used by other RSVP
   extension models- such as extensions for signaling RSVP-TE packet (or
   other technology specific) Label Switched Paths (LSP)s.

1.1.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

1.2.  Tree Diagram

   A simplified graphical representation of the data model is presented
   in each section of the model.  The following notations are used for
   the YANG model data tree representation.











Beeram, et al.          Expires September 9, 2015               [Page 3]


Internet-Draft            RSVP YANG Data Model                March 2015


   <status> <flags> <name> <opts> <type>

    <status> is one of:
      +  for current
      x  for deprecated
      o  for obsolete

    <flags> is one of:
      rw  for read-write configuration data
      ro  for read-only non-configuration data
      -x  for execution rpcs
      -n  for notifications

    <name> is the name of the node

   If the node is augmented into the tree from another module, its name
   is printed as <prefix>:<name>

    <opts> is one of:
      ? for an optional leaf or node
      ! for a presence container
      * for a leaf-list or list
      Brackets [<keys>] for a list's keys
      Curly braces {<condition>} for optional feature that make node
   conditional
      Colon : for marking case nodes
      Ellipses ("...") subtree contents not shown

      Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

    <type> is the name of the type for leafs and leaf-lists.

1.3.  Prefixes in Data Node Names

   In this document, names of data nodes and other data model objects
   are prefixed using the standard prefix associated with the
   corresponding YANG imported modules, as shown in Table 1.

                   +--------+-----------------+-----------+
                   | Prefix | YANG module     | Reference |
                   +--------+-----------------+-----------+
                   | yang   | ietf-yang-types | [RFC6991] |
                   | inet   | ietf-inet-types | [RFC6991] |
                   +--------+-----------------+-----------+

               Table 1: Prefixes and corresponding YANG modules




Beeram, et al.          Expires September 9, 2015               [Page 4]


Internet-Draft            RSVP YANG Data Model                March 2015


1.4.  Open Issues and Next Steps

   This is the initial version of the RSVP basic and RSVP-TE modules.
   It is expected that this model will still evolve and that RSVP-TE
   data model to be published in its own draft in the next revision.
   The current revision of the model focuses mostly on configuration
   data, but future revisions are expected to cover data forRSVP states,
   RPCs, and notifications.

   During discussions, some of the RSVP features were debated whether
   they should be present in the base RSVP model or in extension RSVP
   model (e.g.  RSVP-TE model), given such features were defined in
   extension drafts for GMPLS or RSVP-TE states.  For example, the RSVP
   Hello extensions defined in [RFC3209] with extensions to RSVP for TE
   states.  However, RSVP Hello extension can equally apply to non RSVP-
   TE states too, and some vendor implementations, allow it to be
   enabled independently of RSVP-TE.

2.  Design Considerations

2.1.  Base Model

   The model discussed in this document covers Standard RSVP [RFC2205]
   and other generic enhancements that pertain to the base protocol
   operation.  RSVP-TE [RFC3209] and other traffic-engineering specific
   enhancements have been deliberately left out of this model to enable
   users to configure just the base RSVP protocol features in scenarios
   where traffic-engineering is not enabled/required.  The RSVP traffic-
   engineering model is an augmentation to the RSVP base model and
   expected to be discussed in separate document(s).  However, in this
   revision of the document, the packet RSVP-TE model is presented in
   Appendix A.  Currently, the RSVP-TE module is presented as part of
   this draft, and is mostly packet centric.  It is expected that the
   RSVP-TE YANG model will move to a separate document in the next
   revision.
















Beeram, et al.          Expires September 9, 2015               [Page 5]


Internet-Draft            RSVP YANG Data Model                March 2015


     TE basic       +---------+        ^: import
     module         | ietf-te |        o: augment
                    +---------+
                       |   o
                       |   |
                       v   |
                    +--------------+
     RSVP-TE module | ietf-rsvp-te |o . . .
                    +--------------+         \
                       ^   |                  \
                       |   o               +-------------------+
                    +-----------+          | ietf-rsvp-otn-te  |
     RSVP module    | ietf-rsvp |          +-------------------+
                    +-----------+             RSVP-TE with OTN
                                              extensions
                                             (shown for illustration
                                              not in this document)

       Figure 1: Relationship of RSVP and RSVP-TE modules with other
                             protocol modules

2.2.  Feature Set

   The model discussed in this version of the document does not aim to
   be feature complete.  The primary intent is to cover a set of
   standard generic features (listed below) that are commonly in use.

   o  Authentication ([RFC2747])

   o  Refresh Reduction ([RFC2961])

   o  Hellos ([RFC3209])

   o  Graceful Restart ([RFC3473], [RFC5063])

2.3.  Configuration Inheritance

   The defined data model supports configuration inheritance for
   tunnels, paths, and interfaces.  Data elements defined in the main
   container (e.g. that encompasses the list of tunnels, interfaces, or
   paths) are assumed to apply equally to all elements of the list,
   unless overridden explicitly for a certain element (e.g. tunnel,
   interface or path).  Vendors are expected to augment the above
   container(s) to provide the list of inheritance command for their
   implementations.






Beeram, et al.          Expires September 9, 2015               [Page 6]


Internet-Draft            RSVP YANG Data Model                March 2015


2.4.  Vendor Configuration Models

   There two main popular types of routing protocol configuration that
   vendors may support:

   o  protocol centric - all the protocol related configuration is
      contained within the protocol itself.  Configuration belonging to
      multiple instances of the protocol running in different routing-
      instances (e.g.  VRFs) are contained under the default routing
      instance [I-D.ietf-netmod-routing-cfg]:

   o  VRF centric - all the protocol related configuration for a
      routing- instance is contained within this routing-instance.

   There is still an ongoing debate on whether to accommodate both
   approaches or to pick just one.  The model proposed in this document
   will adhere to the final outcome of this discussion.

3.  Model Organization

   This model defines configuration, state, execution, and notifications
   data for RSVP globals, interfaces, neighbors and sessions properties.

   The container "rsvp" is the top level container in this data model.
   The presence of this container is expected to enable RSVP protocol
   functionality.

























Beeram, et al.          Expires September 9, 2015               [Page 7]


Internet-Draft            RSVP YANG Data Model                March 2015


   module: ietf-rsvp
      +--rw rsvp!
         +--rw globals
            .
            .
         +--rw interfaces
            .
            .
         +--rw neighbors
            .
            .
         +--rw sessions
            .
            .
         +--ro globals-state
            .
            .
         +--ro interfaces-state
            .
            .
         +--ro neighbors-state
            .
            .
         +--ro sessions-state
            .
            .
      rpcs:
         +--x global-rpc
         +--x interfaces-rpc
         +--x neighbors-rpc
         +--x sessions-rpc
      notifications:
         +--n global-notif
         +--n interfaces-notif
         +--n neighbors-notif
         +--n sessions-notif


3.1.  RSVP Configuration Data

   The following subsections provide overview of the parts of the model
   pertaining to configuration data.

3.1.1.  Global Configuration Data

   This branch of the data model covers configuration of elements that
   control RSVP protocol behavior.




Beeram, et al.          Expires September 9, 2015               [Page 8]


Internet-Draft            RSVP YANG Data Model                March 2015


   module: ietf-rsvp
      +--rw rsvp!
         +--rw globals
         |  +--rw signaling
         |     +--rw graceful-restart! {graceful-restart}?
         |     |  +--rw restart-time?    uint32
         |     |  +--rw recovery-time?   uint32
         |     +--rw hello {hellos}?
         |     |  +--rw interface-based?   empty
         |     |  +--rw hello-interval?    uint32
         |     |  +--rw hello-misses?      uint32
         |     +--rw path-err
         |     |  +--rw state-removal?   empty
         |     +--rw refresh
         |        +--rw interval?    uint32
         |        +--rw missed?      uint32
         |        +--rw reduction {refresh-reduction}?
         |           +--rw bundle-message-max-size?    uint32
         |           +--rw disable?                    empty
         |           +--rw reliable-ack-hold-time?     uint32
         |           +--rw reliable-ack-max-size?      uint32
         |           +--rw reliable-retransmit-time?   uint32
         |           +--rw reliable-srefresh?          empty
         |           +--rw summary-max-size?           uint32

3.1.2.  Interface Configuration Data

   This branch of the data model covers configuration of elements
   relevant to RSVP interfaces.

   module: ietf-rsvp
      +--rw rsvp!
         +--rw interfaces
         |  +--rw authentication {authentication}?
         |  |  +--rw key-chain?     string
         |  |  +--rw lifetime?      uint32
         |  |  +--rw window-size?   uint32
         |  |  +--rw challenge?     empty
         |  |  +--rw retransmits?   uint32
         |  +--rw signaling
         |  |  +--rw graceful-restart! {graceful-restart}?
         |  |  |  +--rw restart-time?    uint32
         |  |  |  +--rw recovery-time?   uint32
         |  |  +--rw hello {hellos}?
         |  |  |  +--rw interface-based?   empty
         |  |  |  +--rw hello-interval?    uint32
         |  |  |  +--rw hello-misses?      uint32
         |  |  +--rw path-err



Beeram, et al.          Expires September 9, 2015               [Page 9]


Internet-Draft            RSVP YANG Data Model                March 2015


         |  |  |  +--rw state-removal?   empty
         |  |  +--rw refresh
         |  |     +--rw interval?    uint32
         |  |     +--rw missed?      uint32
         |  |     +--rw reduction {refresh-reduction}?
         |  |        +--rw bundle-message-max-size?    uint32
         |  |        +--rw disable?                    empty
         |  |        +--rw reliable-ack-hold-time?     uint32
         |  |        +--rw reliable-ack-max-size?      uint32
         |  |        +--rw reliable-retransmit-time?   uint32
         |  |        +--rw reliable-srefresh?          empty
         |  |        +--rw summary-max-size?           uint32
         |  +--rw interface* [interface]
         |     +--rw interface         if:interface-ref
         |     +--rw authentication {authentication}?
         |     |  +--rw key-chain?     string
         |     |  +--rw lifetime?      uint32
         |     |  +--rw window-size?   uint32
         |     |  +--rw challenge?     empty
         |     |  +--rw retransmits?   uint32
         |     +--rw signaling
         |        +--rw graceful-restart! {graceful-restart}?
         |        |  +--rw restart-time?    uint32
         |        |  +--rw recovery-time?   uint32
         |        +--rw hello {hellos}?
         |        |  +--rw interface-based?   empty
         |        |  +--rw hello-interval?    uint32
         |        |  +--rw hello-misses?      uint32
         |        +--rw path-err
         |        |  +--rw state-removal?   empty
         |        +--rw refresh
         |           +--rw interval?    uint32
         |           +--rw missed?      uint32
         |           +--rw reduction {refresh-reduction}?
         |              +--rw bundle-message-max-size?    uint32
         |              +--rw disable?                    empty
         |              +--rw reliable-ack-hold-time?     uint32
         |              +--rw reliable-ack-max-size?      uint32
         |              +--rw reliable-retransmit-time?   uint32
         |              +--rw reliable-srefresh?          empty
         |              +--rw summary-max-size?           uint32

3.1.3.  Session Configuration Data

   This branch of the data model covers configuration of elements
   relevant to RSVP neighbors.  This would be discussed in detail in
   future revisions.




Beeram, et al.          Expires September 9, 2015              [Page 10]


Internet-Draft            RSVP YANG Data Model                March 2015


   module: ietf-rsvp
      +--rw rsvp!
         +--rw sessions
         |  +--rw session* [src_port dst_port source destination]
         |     +--rw src_port       uint16
         |     +--rw dst_port       uint16
         |     +--rw source         inet:ip-address
         |     +--rw destination    inet:ip-address

3.1.4.  Neighbor Configuration Data

   This branch of the data model covers configuration of elements
   relevant to RSVP sessions.  This would be discussed in detail in
   future revisions.

   module: ietf-rsvp
      +--rw rsvp!
         +--rw neighbors
         |  +--rw neighbor* [address]
         |     +--rw address    inet:ip-address

3.2.  RSVP State Data

   The following subsections provide overview of the parts of the model
   that hold state data.

3.2.1.  Global State Data

   This branch of the model covers global State Data.  This would be
   discussed in detail in future revisions.

3.2.2.  Interface State Data

   This branch of the model covers state data for RSVP interfaces.  This
   would be discussed in detail in future revisions.

3.2.3.  Neighbor State Data

   This branch of the model covers state data for RSVP neighbors.  This
   would be discussed in detail in future revisions.

3.2.4.  Session State Data

   This branch of the model covers state data for RSVP sessions.  This
   would be discussed in detail in future revisions.






Beeram, et al.          Expires September 9, 2015              [Page 11]


Internet-Draft            RSVP YANG Data Model                March 2015


3.3.  RSVP RPC Data

   The following subsections provide overview of the parts of the model
   pertaining to RPC data.

3.4.  Global RPC Data

   This branch of the model covers RPC execution commands for triggering
   actions on global RSVP Data.  This would be discussed in detail in
   future revisions.

3.4.1.  Interface RPC Data

   This branch of the model covers RPC execution commands for RSVP
   interfaces.  This would be discussed in detail in future revisions.

3.4.2.  Neighbor RPC Data

   This branch of the model covers RPC execution commands for RSVP
   neighbors.  This would be discussed in detail in future revisions.

3.4.3.  Session RPC Data

   This branch of the model covers RPC execution commands for RSVP
   sessions.  This would be discussed in detail in future revisions

3.5.  RSVP Notification Data

   The following subsections provide overview of the parts of the model
   pertaining to notification data.

3.5.1.  Global Notification Data

   This branch of the model covers notifications pertaining to global
   RSVP data.  This would be discussed in detail in future revisions.

3.5.2.  Interface Notification Data

   This branch of the model covers notifications pertaining to RSVP
   interfaces.  This would be discussed in detail in future revisions.

3.5.3.  Neighbor Notification Data

   This branch of the model covers notifications pertaining to RSVP
   neighbors.  This would be discussed in detail in future revisions.






Beeram, et al.          Expires September 9, 2015              [Page 12]


Internet-Draft            RSVP YANG Data Model                March 2015


3.5.4.  Session Notification Data

   This branch of the model covers notifications pertaining to RSVP
   sessions.  This would be discussed in detail in future revisions

4.  RSVP YANG Module

<CODE BEGINS>
module ietf-rsvp {

    namespace "urn:ietf:params:xml:ns:yang:rsvp";

    /* Replace with IANA when assigned */
    prefix "rsvp";

    /* import ietf-inet-types { prefix inet; } */
    import ietf-interfaces {
        prefix "if";
    }

    import ietf-inet-types {
        prefix inet;
    }

    organization
        "IETF TEAS Working Group";

    contact "TBA";

    description
        "This module contains the RSVP YANG data model.";

    revision 2014-12-17 {
        description "Initial revision.";
    }

    /* RSVP features */
    feature authentication {
        description
            "Indicates support for RSVP authentication";
    }

    feature graceful-restart {
        description
            "Indicates support for RSVP graceful restart";
    }

    feature refresh-reduction {



Beeram, et al.          Expires September 9, 2015              [Page 13]


Internet-Draft            RSVP YANG Data Model                March 2015


        description
            "Indicates support for RSVP refresh reduction";
    }

    feature hellos {
        description
            "Indicates support for RSVP hellos";
    }

    grouping graceful-restart {
        description "Configure RSVP Graceful-Restart parameters.";
        container graceful-restart {
            if-feature graceful-restart;
            presence "Enable RSVP graceful restart on the node.";

            leaf restart-time {
                description
                    "Graceful restart time (seconds).";
                reference
                    "RFC 5495: Description of the Resource
                    Reservation Protocol - Traffic-Engineered (RSVP-TE)
                    Graceful Restart Procedures";
                type uint32;
            }
            leaf recovery-time {
                description
                    "";
                type uint32;
            }
        }
    }

    grouping authentication {
        container authentication {
            if-feature authentication;
            description
                "Configure RSVP authentication.";
            leaf key-chain {
                description
                    "Key chain name to authenticate RSVP signaling
                    messages.";
                reference
                    "RFC 2747: RSVP Cryptographic Authentication";
                type string {
                     length "1..32";
                }
            }
            leaf lifetime {



Beeram, et al.          Expires September 9, 2015              [Page 14]


Internet-Draft            RSVP YANG Data Model                March 2015


                description
                    "Life time for each security association";
                reference
                    "RFC 2747: RSVP Cryptographic Authentication";
                type uint32 {
                     range "30..86400";
                }
            }
            leaf window-size {
                description
                    "Window-size to limit number of out-of-order
                    messages.";
                reference
                    "RFC 2747: RSVP Cryptographic Authentication";
                type uint32 {
                    range "1..64";
                }
            }
            leaf challenge {
                description
                    "Enable challenge messages.";
                reference
                    "RFC 2747: RSVP Cryptographic Authentication";
                type empty;
            }
            leaf retransmits {
                description
                    "Number of retransmits when messages are dropped.";
                reference
                    "RFC 2747: RSVP Cryptographic Authentication";
                 type uint32 {
                    range "1..10000";
                 }
            }
        }
    }

    grouping signaling {
        container signaling {
            uses graceful-restart;
            container hello {
                if-feature hellos;
                description "Configure Hello parameters.";
                leaf interface-based {
                     description "Enable interface-based
                                  Hello adjacency if present.";
                     type empty;
                }



Beeram, et al.          Expires September 9, 2015              [Page 15]


Internet-Draft            RSVP YANG Data Model                March 2015


                leaf hello-interval {
                    description
                        "Configure interval between successive Hello
                         messages in milliseconds.";
                    reference
                        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP
                        Tunnels RFC 5495: Description of the Resource
                        Reservation Protocol - Traffic-Engineered
                        (RSVP-TE) Graceful Restart Procedures";
                    type uint32 {
                        range "3000..30000";
                    }
                }
                leaf hello-misses {
                    description
                        "Configure max number of consecutive missed
                        Hello messages.";
                    reference
                        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP
                        Tunnels.
                        RFC 5495: Description of the Resource
                        Reservation Protocol - Traffic-Engineered
                        (RSVP-TE)
                        Graceful Restart Procedures";
                    type uint32 {
                         range "1..10";
                    }
                }
            }

            container path-err {
                leaf state-removal {
                    description
                        "State-Removal flag in Path Error message
                        if present.";
                    type empty;
                }
            }

            container refresh {
                leaf interval {
                    description
                        "Set interval between successive refreshes";
                    type uint32;
                }
                leaf missed {
                    description
                        "Set max number of consecutive missed messages



Beeram, et al.          Expires September 9, 2015              [Page 16]


Internet-Draft            RSVP YANG Data Model                March 2015


                        for state expiry";
                    type uint32;
                }

                container reduction {
                    if-feature refresh-reduction;
                    description
                        "Configure RSVP Refresh Reduction parameters.";
                    leaf bundle-message-max-size {
                        description
                            "Configure maximum size (bytes) of a single
                            RSVP Bundle message.";
                        type uint32 {
                            range "512..65000";
                        }
                    }
                    leaf disable {
                        description
                            "Disable refresh reduction if present.";
                        type empty;
                    }
                    leaf reliable-ack-hold-time {
                        description
                            "Configure hold time in milliseconds for
                            sending RSVP ACK message(s).";
                        type uint32 {
                            range "100..5000";
                        }
                    }
                    leaf reliable-ack-max-size {
                        description
                            "Configure max size of a single RSVP ACK
                            message.";
                        type uint32 {
                            range "20..65000";
                        }
                    }
                    leaf reliable-retransmit-time {
                        description
                            "Configure min delay in milliseconds to wait
                            for an ACK before a retransmit.";
                        type uint32 {
                            range "100..10000";
                        }
                    }
                    leaf reliable-srefresh {
                        description
                            "Configure use of reliable messaging fori



Beeram, et al.          Expires September 9, 2015              [Page 17]


Internet-Draft            RSVP YANG Data Model                March 2015


                            summary refresh if present.";
                        type empty;
                    }
                    leaf summary-max-size {
                        description
                            "Configure max size (bytes) of a single RSVP
                            summary refresh message.";
                        type uint32 {
                            range "20..65000";
                        }
                    }
                }
            }
        }
    }

    container rsvp {
        presence "Enable RSVP feature";

        container globals {
            description "RSVP global properties.";
            uses signaling;
        }

        container interfaces {
            uses authentication;
            uses signaling;
            list interface {
                key "interface";
                description
                    "RSVP interfaces.";
                leaf interface {
                     description
                        "RSVP interface.";
                     type if:interface-ref;
                }
                uses authentication;
                uses signaling;
            }
        }

        container sessions {
            list session {
                key "src_port dst_port source destination";
                leaf src_port {
                    type uint16;
                    description "RSVP source port";
                    reference "RFC2205";



Beeram, et al.          Expires September 9, 2015              [Page 18]


Internet-Draft            RSVP YANG Data Model                March 2015


                }
                leaf dst_port {
                    type uint16;
                    description "RSVP destination port";
                    reference "RFC2205";
                }
                leaf source {
                    type inet:ip-address;
                    description "RSVP source address";
                    reference "RFC2205";
                }
                leaf destination {
                    type inet:ip-address;
                    description "RSVP destination address";
                    reference "RFC2205";
                }
            }
        }

        container neighbors {
            list neighbor {
                key "address";
                leaf address {
                    type inet:ip-address;
                }
            }
        }

        container interface-state {
            config "false";
            list session {
                key "interface";
                description
                    "RSVP interfaces.";
                leaf interface {
                     description
                        "RSVP interface.";
                     type if:interface-ref;
                }
            }
        }

        container sessions-state {
            config "false";
            list session {
                key "src_port dst_port source destination";
                leaf src_port {
                    type uint16;



Beeram, et al.          Expires September 9, 2015              [Page 19]


Internet-Draft            RSVP YANG Data Model                March 2015


                    description "RSVP source port";
                    reference "RFC2205";
                }
                leaf dst_port {
                    type uint16;
                    description "RSVP destination port";
                    reference "RFC2205";
                }
                leaf source {
                    type inet:ip-address;
                    description "RSVP source address";
                    reference "RFC2205";
                }
                leaf destination {
                    type inet:ip-address;
                    description "RSVP destination address";
                    reference "RFC2205";
                }
            }
        }

        container neighbors-state {
            config "false";
            list neighbor {
                key "address";
                leaf address {
                    type inet:ip-address;
                }
            }
        }
    }
}

<CODE ENDS>

5.  Appendix A: RSVP-TE YANG Model

   This section includes the initial version of the YANG model for the
   extensions to the RSVP protocol to signal Traffic-Engineering (RSVP-
   TE) Label Switched Paths (LSPs).  The initial version of the RSVP-TE
   YANG module covers data items specific to packet technology.  It is
   expected, however, that RSVP-TE YANG models for technology specific
   data (e.g.  OTN or WDM) will be defined in separate modules and in
   other drafts in future revisions.

   This model imports and augments the base RSVP YANG model (presented
   in section 4 (Section 4).  It also imports and augments the TE YANG




Beeram, et al.          Expires September 9, 2015              [Page 20]


Internet-Draft            RSVP YANG Data Model                March 2015


   model defined in [draft-saad-teas-yang-te-00] to enable configuration
   of RSVP-TE attributes on TE tunnels.

5.1.  RSVP-TE Configuration Data

   The following subsections provide overview of the parts of the RSVP-
   TE model pertaining to configuration data.

   There are tree types of configuration data nodes in this module:

   o  those augmenting or extending the base RSVP module

   o  those augmenting or extending the base TE module

   o  those that are specific to the RSVP-TE module

   Below is a YANG tree representation for data items defined in the
   RSVP-TE module:

































Beeram, et al.          Expires September 9, 2015              [Page 21]


Internet-Draft            RSVP YANG Data Model                March 2015


   module: ietf-rsvp-te
   augment /rsvp:rsvp/rsvp:globals:
      +--rw frr-local-revert!
         +--rw frr-local-revert-delay?   uint32
   augment /ietf-te:te/ietf-te:tunnels/ietf-te:tunnel:
      +--rw end-to-end-routing?         empty
      +--rw boundary-rerouting?         empty
      +--rw segment-based-rerouting?    empty
      +--rw lsp-integrety-required?     empty
      +--rw contiguous-lsp?             empty
      +--rw lsp-stitching-desired?      empty
      +--rw preplanned-lsp?             empty
      +--rw non-php-desired?            empty
      +--rw oob-mapping?                empty
      +--rw entropy-label-cap?          empty
      +--rw oam-mep-entities-desired?   empty
      +--rw oam-mip-entities-desired?   empty
      +--rw source?                     inet:ip-address
      +--rw fast-reroute!
      |  +--rw bandwidth-protection-desired?   empty
      |  +--rw node-protection-desired?        empty
      +--rw se-style-desired?           empty
      +--rw soft-preemption-desired?    empty
      +--rw record-route-desired?       empty
      +--rw signaled-name?              string
      +--rw priority
      |  +--rw setup?   uint8
      |  +--rw hold?    uint8
      +--rw soft-preemption?            empty
   augment /rsvp:rsvp/rsvp:interfaces:
      +--rw signaling
         +--rw egress-label?   ietf-te-psc-types:egress-label
   augment /rsvp:rsvp/rsvp:interfaces/rsvp:interface:
      +--rw signaling
         +--rw egress-label?   ietf-te-psc-types:egress-label
   augment /rsvp:rsvp/rsvp:sessions:
   augment /rsvp:rsvp/rsvp:neighbors:
   augment /rsvp:rsvp/rsvp:sessions-state:
   augment /rsvp:rsvp/rsvp:neighbors-state:
   rpcs:
      +---x sessions-rpc
      +---x interfaces-rpc
   notifications:
      +---n sessions-notif
      +---n interfaces-notif






Beeram, et al.          Expires September 9, 2015              [Page 22]


Internet-Draft            RSVP YANG Data Model                March 2015


5.2.  RSVP-TE State Data

   It is expected that operational/state RSVP-TE data will extend the
   RSVP and TE basic data.  This will be detailed in future revisions.

5.3.  RSVP-TE YANG Module

  <CODE BEGINS>
  module ietf-rsvp-te {

      namespace "urn:ietf:params:xml:ns:yang:ietf-rsvp-te";

      prefix "rsvp-te";

      import ietf-rsvp {
          prefix rsvp;
      }

      /* Import TE packet specific types */
      import ietf-te-psc-types {
          prefix ietf-te-psc-types;
      }

      import ietf-te {
          prefix ietf-te;
      }

      import ietf-inet-types {
          prefix inet;
      }

      /* groupings for rsvp */
      grouping signaling {
          container signaling {
              description "Configure RSVP signaling properties.";
              leaf egress-label {
                  type ietf-te-psc-types:egress-label;
              }
          }

      }

      grouping lsp-attributes {
          leaf end-to-end-routing {
              reference "RFC4920, RFC5420";
              type empty;
          }
          leaf boundary-rerouting {



Beeram, et al.          Expires September 9, 2015              [Page 23]


Internet-Draft            RSVP YANG Data Model                March 2015


              reference "RFC4920, RFC5420";
              type empty;
          }
          leaf segment-based-rerouting {
              reference "RFC4920, RFC5420";
              type empty;
          }
          leaf lsp-integrety-required {
              reference "RFC4875";
              type empty;
          }
          leaf contiguous-lsp {
              reference "RFC5151";
              type empty;
          }
          leaf lsp-stitching-desired {
              reference "RFC5150";
              type empty;
          }
          leaf preplanned-lsp {
              reference "RFC6001";
              type empty;
          }
          leaf non-php-desired {
              reference "RFC6511";
              type empty;
          }
          leaf oob-mapping {
              reference "RFC6511";
              type empty;
          }
          leaf entropy-label-cap {
              reference "RFC6790";
              type empty;
          }
          leaf oam-mep-entities-desired {
              reference "RFC7260";
              type empty;
          }
          leaf oam-mip-entities-desired {
              reference "RFC7260";
              type empty;
          }
      }

      grouping lsp-signaling-properties {
          description "LSP signaling properties.";
          uses lsp-attributes;



Beeram, et al.          Expires September 9, 2015              [Page 24]


Internet-Draft            RSVP YANG Data Model                March 2015


          leaf source {
              description
                  "LSP source address.";
              type inet:ip-address;
          }
          container fast-reroute {
              presence "FRR local protection is desired.";
              reference
                  "RFC4859: Registry for RSVP-TE Session Flags";
              leaf bandwidth-protection-desired {
                  description
                      "Request FRR bandwidth protection on LSRs if
                      present.";
                  type empty;
              }
              leaf node-protection-desired {
                  description
                      "Request FRR node protection on LSRs if present.";
                  type empty;
              }
          }
          leaf se-style-desired {
              description "SE Style desired";
              reference "RFC3209";
              type empty;
          }
          leaf soft-preemption-desired {
              description "Soft-preemption is desired";
              reference "RFC5712";
              type empty;
          }
          leaf record-route-desired {
              description "Path recording is desired.";
              reference "RFC3209";
              type empty;
          }
          leaf signaled-name {
              description
                  "Sets the session name to use in the session attribute
                   object.";
              type string;
          }
          container priority {
              description
                  "Sets the setup/hold priority to use in the session
                   attribute object.";
              leaf setup {
                  type uint8 {



Beeram, et al.          Expires September 9, 2015              [Page 25]


Internet-Draft            RSVP YANG Data Model                March 2015


                       range "0..7";
                  }
              }
              leaf hold {
                  type uint8 {
                       range "0..7";
                  }
              }
          }
          leaf soft-preemption {
              description
                  "Requests soft-preemption in session
                   attributes object at
                   at traversed LSR(s).";
              type empty;
          }
      }


      /* RSVP-TE global propeerties */
      augment "/rsvp:rsvp/rsvp:globals" {
          container frr-local-revert {
              presence "Enable RSVP FRR local revertive recovery mode.";
              leaf frr-local-revert-delay {
                  description
                      "Time to wait after primary link is restored
                      before node attempts local revertive procedures.";
                  type uint32;
              }
          }
      }

      augment "/ietf-te:te/ietf-te:tunnels/ietf-te:tunnel" {
          uses lsp-signaling-properties;
      }

      /* Linkage to the base RSVP all links */
      augment "/rsvp:rsvp/rsvp:interfaces" {
          uses signaling;
      }

      /* Linkage to per RSVP link */
      augment "/rsvp:rsvp/rsvp:interfaces/rsvp:interface" {
          uses signaling;
      }

      /* TSAAD: add augmentation for sessions neighbors */
      augment "/rsvp:rsvp/rsvp:sessions" {



Beeram, et al.          Expires September 9, 2015              [Page 26]


Internet-Draft            RSVP YANG Data Model                March 2015


          /* To be added */
      }

      augment "/rsvp:rsvp/rsvp:neighbors" {
          /* To be added */
      }

      augment "/rsvp:rsvp/rsvp:sessions-state" {
          /* To be added */
      }

      augment "/rsvp:rsvp/rsvp:neighbors-state" {
          /* To be added */
      }
  }
  <CODE ENDS>

6.  IANA Considerations

   This document registers the following URIs in the IETF XML registry
   [RFC3688].  Following the format in [RFC3688], the following
   registration is requested to be made.

   URI: urn:ietf:params:xml:ns:yang:ietf-rsvp XML: N/A, the requested
   URI is an XML namespace.

   URI: urn:ietf:params:xml:ns:yang:ietf-rsvp-te XML: N/A, the requested
   URI is an XML namespace.

   This document registers a YANG module in the YANG Module Names
   registry [RFC6020].

   name: ietf-rsvp namespace: urn:ietf:params:xml:ns:yang:ietf-rsvp
   prefix: ietf-rsvp reference: RFC3209

   name: ietf-rsvp-te namespace: urn:ietf:params:xml:ns:yang:ietf-rsvp-
   te prefix: ietf-rsvp-te reference: RFC3209

7.  Security Considerations

   The YANG module defined in this memo is designed to be accessed via
   the NETCONF protocol [RFC6241].  The lowest NETCONF layer is the
   secure transport layer and the mandatory-to-implement secure
   transport is SSH [RFC6242].  The NETCONF access control model
   [RFC6536] provides means to restrict access for particular NETCONF

   users to a pre-configured subset of all available NETCONF protocol
   operations and content.



Beeram, et al.          Expires September 9, 2015              [Page 27]


Internet-Draft            RSVP YANG Data Model                March 2015


   There are a number of data nodes defined in the YANG module which are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., <edit-config>)
   to these data nodes without proper protection can have a negative
   effect on network operations.

8.  Acknowledgement

   The authors would like to thank Lou Berger for reviewing and
   providing valuable feedback on this document.

9.  References

9.1.  Normative References

   [I-D.ietf-netmod-routing-cfg]
              Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
              Management", draft-ietf-netmod-routing-cfg-17 (work in
              progress), March 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, January 2000.

   [RFC2961]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
              and S. Molendini, "RSVP Refresh Overhead Reduction
              Extensions", RFC 2961, April 2001.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC5063]  Satyanarayana, A. and R. Rahman, "Extensions to GMPLS
              Resource Reservation Protocol (RSVP) Graceful Restart",
              RFC 5063, October 2007.






Beeram, et al.          Expires September 9, 2015              [Page 28]


Internet-Draft            RSVP YANG Data Model                March 2015


   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, June 2011.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536, March
              2012.

   [RFC6991]  Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
              July 2013.

   [draft-saad-teas-yang-te-00]
              Saad, T., Ed., Gandhi, R., Liu, X., Beeram, V., Shah, H.,
              Chen, X., and R. Jones, "A YANG Data Model for Traffic
              Engineering Tunnels and Interfaces", March 2015.

9.2.  Informative References

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

Authors' Addresses

   Vishnu Pavan Beeram
   Juniper Networks

   Email: vbeeram@juniper.net


   Tarek Saad
   Cisco Systems Inc

   Email: tsaad@cisco.com


   Rakesh Gandhi
   Cisco Systems Inc

   Email: rgandhi@cisco.com




Beeram, et al.          Expires September 9, 2015              [Page 29]


Internet-Draft            RSVP YANG Data Model                March 2015


   Xufeng Liu
   Ericsson

   Email: xufeng.liu@ericsson.com


   Himanshu Shah
   Ciena

   Email: tsaad@cisco.com


   Xia Chen
   Huawei Technologies

   Email: jescia.chenxia@huawei.com


   Raqib Jones
   Brocade

   Email: raqib@Brocade.com





























Beeram, et al.          Expires September 9, 2015              [Page 30]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/