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
<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 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
<CODE BEGINS> 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";
}
}
}
}
}
<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
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
<CODE BEGINS> 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 */
}
}
<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
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., <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.
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]