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 is one of: + for current x for deprecated o for obsolete is one of: rw for read-write configuration data ro for read-only non-configuration data -x for execution rpcs -n for notifications is the name of the node If the node is augmented into the tree from another module, its name is printed as : is one of: ? for an optional leaf or node ! for a presence container * for a leaf-list or list Brackets [] for a list's keys Curly braces {} 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 (":"). 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 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; } } } } } 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 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 */ } } 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., ) 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]