TEAS Working Group V. Beeram Internet-Draft Juniper Networks Intended status: Standards Track T. Saad Expires: September 23, 2015 R. Gandhi Cisco Systems Inc X. Liu Ericsson H. Shah Ciena X. Chen Huawei Technologies R. Jones Brocade March 22, 2015 A YANG Data Model for Resource Reservation Protocol (RSVP) draft-saad-teas-yang-rsvp-01 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 23, 2015. Beeram, et al. Expires September 23, 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 23, 2015 [Page 2] Internet-Draft RSVP YANG Data Model March 2015 4. RSVP YANG Module . . . . . . . . . . . . . . . . . . . . . . 13 5. Appendix A: RSVP-TE YANG Model . . . . . . . . . . . . . . . 21 5.1. RSVP-TE Configuration Data . . . . . . . . . . . . . . . 21 5.2. RSVP-TE State Data . . . . . . . . . . . . . . . . . . . 24 5.3. RSVP-TE YANG Module . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 file "ietf-rsvp@2015-03-22.yang" module ietf-rsvp { namespace "urn:ietf:params:xml:ns:yang:ietf-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 2015-03-22 { description "Initial revision."; reference "RFC2205"; } /* RSVP features */ feature authentication { description "Indicates support for RSVP authentication"; } feature graceful-restart { description "Indicates support for RSVP graceful restart"; } Beeram, et al. Expires September 23, 2015 [Page 13] Internet-Draft RSVP YANG Data Model March 2015 feature refresh-reduction { 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."; description "RSVP graceful-restart parameters container"; leaf restart-time { type uint32; description "Graceful restart time (seconds)."; reference "RFC 5495: Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures"; } leaf recovery-time { type uint32; description "RSVP state recovery time"; } } } grouping authentication { description "RSVP authentication grouping"; container authentication { if-feature authentication; description "Configure RSVP authentication."; leaf key-chain { type string { length "1..32"; } description "Key chain name to authenticate RSVP signaling Beeram, et al. Expires September 23, 2015 [Page 14] Internet-Draft RSVP YANG Data Model March 2015 messages."; reference "RFC 2747: RSVP Cryptographic Authentication"; } leaf lifetime { type uint32 { range "30..86400"; } description "Life time for each security association"; reference "RFC 2747: RSVP Cryptographic Authentication"; } leaf window-size { type uint32 { range "1..64"; } description "Window-size to limit number of out-of-order messages."; reference "RFC 2747: RSVP Cryptographic Authentication"; } leaf challenge { type empty; description "Enable challenge messages."; reference "RFC 2747: RSVP Cryptographic Authentication"; } leaf retransmits { type uint32 { range "1..10000"; } description "Number of retransmits when messages are dropped."; reference "RFC 2747: RSVP Cryptographic Authentication"; } } } grouping signaling { description "RSVP signaling properties grouping"; container signaling { description Beeram, et al. Expires September 23, 2015 [Page 15] Internet-Draft RSVP YANG Data Model March 2015 "RSVP signaling properties container"; uses graceful-restart; container hello { if-feature hellos; description "Configure Hello parameters."; leaf interface-based { type empty; description "Enable interface-based Hello adjacency if present."; } leaf hello-interval { type uint32 { range "3000..30000"; } 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"; } leaf hello-misses { type uint32 { range "1..10"; } 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"; } } container path-err { description "RSVP path-state removal behavior"; leaf state-removal { type empty; description "State-Removal flag in Path Error message if present."; Beeram, et al. Expires September 23, 2015 [Page 16] Internet-Draft RSVP YANG Data Model March 2015 } } container refresh { description "RSVP refreshes properties"; leaf interval { type uint32; description "Set interval between successive refreshes"; } leaf missed { type uint32; description "Set max number of consecutive missed messages for state expiry"; } container reduction { if-feature refresh-reduction; description "Configure RSVP Refresh Reduction parameters."; leaf bundle-message-max-size { type uint32 { range "512..65000"; } description "Configure maximum size (bytes) of a single RSVP Bundle message."; } leaf disable { type empty; description "Disable refresh reduction if present."; } leaf reliable-ack-hold-time { type uint32 { range "100..5000"; } description "Configure hold time in milliseconds for sending RSVP ACK message(s)."; } leaf reliable-ack-max-size { type uint32 { range "20..65000"; } Beeram, et al. Expires September 23, 2015 [Page 17] Internet-Draft RSVP YANG Data Model March 2015 description "Configure max size of a single RSVP ACK message."; } leaf reliable-retransmit-time { type uint32 { range "100..10000"; } description "Configure min delay in milliseconds to wait for an ACK before a retransmit."; } leaf reliable-srefresh { type empty; description "Configure use of reliable messaging for summary refresh if present."; } leaf summary-max-size { type uint32 { range "20..65000"; } description "Configure max size (bytes) of a single RSVP summary refresh message."; } } } } } container rsvp { presence "Enable RSVP feature"; description "RSVP feature container"; container globals { description "RSVP global properties."; uses signaling; } container interfaces { description "RSVP interfaces container"; uses authentication; uses signaling; list interface { key "interface"; description "RSVP interfaces."; Beeram, et al. Expires September 23, 2015 [Page 18] Internet-Draft RSVP YANG Data Model March 2015 leaf interface { type if:interface-ref; description "RSVP interface."; } uses authentication; uses signaling; } } container sessions { description "RSVP sessions container"; list session { key "src_port dst_port source destination"; description "List of RSVP sessions"; leaf src_port { type uint16; 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 { description "RSVP neighbors container"; list neighbor { key "address"; description "List of RSVP neighbors"; leaf address { Beeram, et al. Expires September 23, 2015 [Page 19] Internet-Draft RSVP YANG Data Model March 2015 type inet:ip-address; description "Neighbor address"; } } } container interface-state { config "false"; description "RSVP interfaces state"; list session { key "interface"; description "RSVP interfaces state."; leaf interface { type if:interface-ref; description "RSVP interface."; } } } container sessions-state { config "false"; description "RSVP sessions state"; list session { key "src_port dst_port source destination"; description "List of RSVP sessions"; leaf src_port { type uint16; 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; Beeram, et al. Expires September 23, 2015 [Page 20] Internet-Draft RSVP YANG Data Model March 2015 description "RSVP destination address"; reference "RFC2205"; } } } container neighbors-state { config "false"; description "RSVP neighbors state"; list neighbor { key "address"; description "List of RSVP neighbors"; leaf address { type inet:ip-address; description "Neighbor 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 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 Beeram, et al. Expires September 23, 2015 [Page 21] Internet-Draft RSVP YANG Data Model March 2015 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 23, 2015 [Page 22] 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 23, 2015 [Page 23] 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 file "ietf-rsvp-te@2015-03-22.yang" 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; } organization "IETF TEAS Working Group"; contact "TBA"; description "This module contains the RSVP YANG data model."; revision 2015-03-22 { description "Initial revision."; reference "RFC3209"; } /* groupings for rsvp */ grouping signaling { description "RSVP-TE signaling properties"; Beeram, et al. Expires September 23, 2015 [Page 24] Internet-Draft RSVP YANG Data Model March 2015 container signaling { description "Configure RSVP signaling properties."; leaf egress-label { type ietf-te-psc-types:egress-label; description "Egress label type"; } } } grouping lsp-attributes { description "RSVP-TE LSP attributes properties"; leaf end-to-end-routing { type empty; description "End-to-end routing desired"; reference "RFC4920, RFC5420"; } leaf boundary-rerouting { type empty; description "Boundary rerouting desired"; reference "RFC4920, RFC5420"; } leaf segment-based-rerouting { type empty; description "Segment-based rerouting desired"; reference "RFC4920, RFC5420"; } leaf lsp-integrety-required { type empty; description "LSP integrity desired"; reference "RFC4875"; } leaf contiguous-lsp { type empty; description "Contiguous LSP"; reference "RFC5151"; } leaf lsp-stitching-desired { type empty; description "Stiticed LSP"; reference "RFC5150"; } leaf preplanned-lsp { type empty; Beeram, et al. Expires September 23, 2015 [Page 25] Internet-Draft RSVP YANG Data Model March 2015 description "Preplanned LSP"; reference "RFC6001"; } leaf non-php-desired { type empty; description "Non-PHP is desired"; reference "RFC6511"; } leaf oob-mapping { type empty; description "Mapping is done out-of-band"; reference "RFC6511"; } leaf entropy-label-cap { type empty; description "Entropy label capability"; reference "RFC6790"; } leaf oam-mep-entities-desired { type empty; description "OAM MEP entities desired"; reference "RFC7260"; } leaf oam-mip-entities-desired { type empty; description "OAM MIP entities desired"; reference "RFC7260"; } } grouping lsp-signaling-properties { description "LSP signaling properties."; uses lsp-attributes; leaf source { type inet:ip-address; description "LSP source address."; } container fast-reroute { presence "FRR local protection is desired."; description "FRR RSVP-TE properties container"; reference "RFC4859: Registry for RSVP-TE Session Flags"; leaf bandwidth-protection-desired { type empty; Beeram, et al. Expires September 23, 2015 [Page 26] Internet-Draft RSVP YANG Data Model March 2015 description "Request FRR bandwidth protection on LSRs if present."; } leaf node-protection-desired { type empty; description "Request FRR node protection on LSRs if present."; } } leaf se-style-desired { type empty; description "SE Style desired"; reference "RFC3209"; } leaf soft-preemption-desired { type empty; description "Soft-preemption is desired"; reference "RFC5712"; } leaf record-route-desired { type empty; description "Path recording is desired."; reference "RFC3209"; } leaf signaled-name { type string; description "Sets the session name to use in the session attribute object."; } container priority { description "Sets the setup/hold priority to use in the session attribute object."; leaf setup { type uint8 { range "0..7"; } description "RSVP session attributes setup priority"; } leaf hold { type uint8 { range "0..7"; } description Beeram, et al. Expires September 23, 2015 [Page 27] Internet-Draft RSVP YANG Data Model March 2015 "RSVP session attributes hold priority"; } } leaf soft-preemption { type empty; description "Requests soft-preemption in session attributes object at at traversed LSR(s)."; } } /* RSVP-TE global propeerties */ augment "/rsvp:rsvp/rsvp:globals" { description "RSVP-TE augmentation to RSVP globals"; container frr-local-revert { presence "Enable RSVP FRR local revertive recovery mode."; description "RSVP-TE global properties container"; leaf frr-local-revert-delay { type uint32; description "Time to wait after primary link is restored before node attempts local revertive procedures."; } } } augment "/ietf-te:te/ietf-te:tunnels/ietf-te:tunnel" { description "TBD"; uses lsp-signaling-properties; } /* Linkage to the base RSVP all links */ augment "/rsvp:rsvp/rsvp:interfaces" { description "TBD"; uses signaling; } /* Linkage to per RSVP link */ augment "/rsvp:rsvp/rsvp:interfaces/rsvp:interface" { description "TBD"; uses signaling; } Beeram, et al. Expires September 23, 2015 [Page 28] Internet-Draft RSVP YANG Data Model March 2015 /* TSAAD: add augmentation for sessions neighbors */ augment "/rsvp:rsvp/rsvp:sessions" { description "TBD"; /* To be added */ } augment "/rsvp:rsvp/rsvp:neighbors" { description "TBD"; /* To be added */ } augment "/rsvp:rsvp/rsvp:sessions-state" { description "TBD"; /* To be added */ } augment "/rsvp:rsvp/rsvp:neighbors-state" { description "TBD"; /* 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 Beeram, et al. Expires September 23, 2015 [Page 29] Internet-Draft RSVP YANG Data Model March 2015 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. 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. Beeram, et al. Expires September 23, 2015 [Page 30] Internet-Draft RSVP YANG Data Model March 2015 [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. [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 Beeram, et al. Expires September 23, 2015 [Page 31] Internet-Draft RSVP YANG Data Model March 2015 Tarek Saad Cisco Systems Inc Email: tsaad@cisco.com Rakesh Gandhi Cisco Systems Inc Email: rgandhi@cisco.com 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 23, 2015 [Page 32]