TEAS Working Group V. Beeram
Internet-Draft Juniper Networks
Intended status: Standards Track T. Saad
Expires: September 9, 2015 R. Gandhi
Cisco Systems Inc
X. Liu
Ericsson
H. Shah
Ciena
X. Chen
Huawei Technologies
R. Jones
Brocade
March 08, 2015
A YANG Data Model for Resource Reservation Protocol (RSVP)
draft-saad-teas-yang-rsvp-00
Abstract
This document defines a YANG data model for the configuration and
management of RSVP Protocol. The model defines generic RSVP protocol
building blocks that can be augmented and used by other RSVP
extension models such as RVSP extensions to Traffic-Engineering
(RSVP-TEE). The model covers the RSVP protocol configuration,
operational state, remote procedural calls, and event notifications
data.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2015.
Beeram, et al. Expires September 9, 2015 [Page 1]
Internet-Draft RSVP YANG Data Model March 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4
1.4. Open Issues and Next Steps . . . . . . . . . . . . . . . 5
2. Design Considerations . . . . . . . . . . . . . . . . . . . . 5
2.1. Base Model . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Feature Set . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Configuration Inheritance . . . . . . . . . . . . . . . . 6
2.4. Vendor Configuration Models . . . . . . . . . . . . . . . 7
3. Model Organization . . . . . . . . . . . . . . . . . . . . . 7
3.1. RSVP Configuration Data . . . . . . . . . . . . . . . . . 8
3.1.1. Global Configuration Data . . . . . . . . . . . . . . 8
3.1.2. Interface Configuration Data . . . . . . . . . . . . 9
3.1.3. Session Configuration Data . . . . . . . . . . . . . 10
3.1.4. Neighbor Configuration Data . . . . . . . . . . . . . 11
3.2. RSVP State Data . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. Global State Data . . . . . . . . . . . . . . . . . . 11
3.2.2. Interface State Data . . . . . . . . . . . . . . . . 11
3.2.3. Neighbor State Data . . . . . . . . . . . . . . . . . 11
3.2.4. Session State Data . . . . . . . . . . . . . . . . . 11
3.3. RSVP RPC Data . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Global RPC Data . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Interface RPC Data . . . . . . . . . . . . . . . . . 12
3.4.2. Neighbor RPC Data . . . . . . . . . . . . . . . . . . 12
3.4.3. Session RPC Data . . . . . . . . . . . . . . . . . . 12
3.5. RSVP Notification Data . . . . . . . . . . . . . . . . . 12
3.5.1. Global Notification Data . . . . . . . . . . . . . . 12
3.5.2. Interface Notification Data . . . . . . . . . . . . . 12
3.5.3. Neighbor Notification Data . . . . . . . . . . . . . 12
3.5.4. Session Notification Data . . . . . . . . . . . . . . 13
Beeram, et al. Expires September 9, 2015 [Page 2]
Internet-Draft RSVP YANG Data Model March 2015
4. RSVP YANG Module . . . . . . . . . . . . . . . . . . . . . . 13
5. Appendix A: RSVP-TE YANG Model . . . . . . . . . . . . . . . 20
5.1. RSVP-TE Configuration Data . . . . . . . . . . . . . . . 21
5.2. RSVP-TE State Data . . . . . . . . . . . . . . . . . . . 23
5.3. RSVP-TE YANG Module . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
YANG [RFC6020] a data definition language that was introduced to
define the contents of a conceptual data store that allows networked
devices to be managed using NETCONF [RFC6241]. YANG is proving
relevant beyond its initial confines, as bindings to other interfaces
(e.g. ReST) and encoding other than XML (e.g. JSON) are being
defined. Furthermore, YANG data models can be used as the basis of
implementation for other interface, such as CLI and programmatic
APIs. This document defines a YANG data model that can be used to
configure and manage RSVP protocol. This model covers generic
protocol building blocks that can be augmented and used by other RSVP
extension models- such as extensions for signaling RSVP-TE packet (or
other technology specific) Label Switched Paths (LSP)s.
1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
1.2. Tree Diagram
A simplified graphical representation of the data model is presented
in each section of the model. The following notations are used for
the YANG model data tree representation.
Beeram, et al. Expires September 9, 2015 [Page 3]
Internet-Draft RSVP YANG Data Model March 2015
<status> <flags> <name> <opts> <type>
<status> is one of:
+ for current
x for deprecated
o for obsolete
<flags> is one of:
rw for read-write configuration data
ro for read-only non-configuration data
-x for execution rpcs
-n for notifications
<name> is the name of the node
If the node is augmented into the tree from another module, its name
is printed as <prefix>:<name>
<opts> is one of:
? for an optional leaf or node
! for a presence container
* for a leaf-list or list
Brackets [<keys>] for a list's keys
Curly braces {<condition>} for optional feature that make node
conditional
Colon : for marking case nodes
Ellipses ("...") subtree contents not shown
Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
<type> is the name of the type for leafs and leaf-lists.
1.3. Prefixes in Data Node Names
In this document, names of data nodes and other data model objects
are prefixed using the standard prefix associated with the
corresponding YANG imported modules, as shown in Table 1.
+--------+-----------------+-----------+
| Prefix | YANG module | Reference |
+--------+-----------------+-----------+
| yang | ietf-yang-types | [RFC6991] |
| inet | ietf-inet-types | [RFC6991] |
+--------+-----------------+-----------+
Table 1: Prefixes and corresponding YANG modules
Beeram, et al. Expires September 9, 2015 [Page 4]
Internet-Draft RSVP YANG Data Model March 2015
1.4. Open Issues and Next Steps
This is the initial version of the RSVP basic and RSVP-TE modules.
It is expected that this model will still evolve and that RSVP-TE
data model to be published in its own draft in the next revision.
The current revision of the model focuses mostly on configuration
data, but future revisions are expected to cover data forRSVP states,
RPCs, and notifications.
During discussions, some of the RSVP features were debated whether
they should be present in the base RSVP model or in extension RSVP
model (e.g. RSVP-TE model), given such features were defined in
extension drafts for GMPLS or RSVP-TE states. For example, the RSVP
Hello extensions defined in [RFC3209] with extensions to RSVP for TE
states. However, RSVP Hello extension can equally apply to non RSVP-
TE states too, and some vendor implementations, allow it to be
enabled independently of RSVP-TE.
2. Design Considerations
2.1. Base Model
The model discussed in this document covers Standard RSVP [RFC2205]
and other generic enhancements that pertain to the base protocol
operation. RSVP-TE [RFC3209] and other traffic-engineering specific
enhancements have been deliberately left out of this model to enable
users to configure just the base RSVP protocol features in scenarios
where traffic-engineering is not enabled/required. The RSVP traffic-
engineering model is an augmentation to the RSVP base model and
expected to be discussed in separate document(s). However, in this
revision of the document, the packet RSVP-TE model is presented in
Appendix A. Currently, the RSVP-TE module is presented as part of
this draft, and is mostly packet centric. It is expected that the
RSVP-TE YANG model will move to a separate document in the next
revision.
Beeram, et al. Expires September 9, 2015 [Page 5]
Internet-Draft RSVP YANG Data Model March 2015
TE basic +---------+ ^: import
module | ietf-te | o: augment
+---------+
| o
| |
v |
+--------------+
RSVP-TE module | ietf-rsvp-te |o . . .
+--------------+ \
^ | \
| o +-------------------+
+-----------+ | ietf-rsvp-otn-te |
RSVP module | ietf-rsvp | +-------------------+
+-----------+ RSVP-TE with OTN
extensions
(shown for illustration
not in this document)
Figure 1: Relationship of RSVP and RSVP-TE modules with other
protocol modules
2.2. Feature Set
The model discussed in this version of the document does not aim to
be feature complete. The primary intent is to cover a set of
standard generic features (listed below) that are commonly in use.
o Authentication ([RFC2747])
o Refresh Reduction ([RFC2961])
o Hellos ([RFC3209])
o Graceful Restart ([RFC3473], [RFC5063])
2.3. Configuration Inheritance
The defined data model supports configuration inheritance for
tunnels, paths, and interfaces. Data elements defined in the main
container (e.g. that encompasses the list of tunnels, interfaces, or
paths) are assumed to apply equally to all elements of the list,
unless overridden explicitly for a certain element (e.g. tunnel,
interface or path). Vendors are expected to augment the above
container(s) to provide the list of inheritance command for their
implementations.
Beeram, et al. Expires September 9, 2015 [Page 6]
Internet-Draft RSVP YANG Data Model March 2015
2.4. Vendor Configuration Models
There two main popular types of routing protocol configuration that
vendors may support:
o protocol centric - all the protocol related configuration is
contained within the protocol itself. Configuration belonging to
multiple instances of the protocol running in different routing-
instances (e.g. VRFs) are contained under the default routing
instance [I-D.ietf-netmod-routing-cfg]:
o VRF centric - all the protocol related configuration for a
routing- instance is contained within this routing-instance.
There is still an ongoing debate on whether to accommodate both
approaches or to pick just one. The model proposed in this document
will adhere to the final outcome of this discussion.
3. Model Organization
This model defines configuration, state, execution, and notifications
data for RSVP globals, interfaces, neighbors and sessions properties.
The container "rsvp" is the top level container in this data model.
The presence of this container is expected to enable RSVP protocol
functionality.
Beeram, et al. Expires September 9, 2015 [Page 7]
Internet-Draft RSVP YANG Data Model March 2015
module: ietf-rsvp
+--rw rsvp!
+--rw globals
.
.
+--rw interfaces
.
.
+--rw neighbors
.
.
+--rw sessions
.
.
+--ro globals-state
.
.
+--ro interfaces-state
.
.
+--ro neighbors-state
.
.
+--ro sessions-state
.
.
rpcs:
+--x global-rpc
+--x interfaces-rpc
+--x neighbors-rpc
+--x sessions-rpc
notifications:
+--n global-notif
+--n interfaces-notif
+--n neighbors-notif
+--n sessions-notif
3.1. RSVP Configuration Data
The following subsections provide overview of the parts of the model
pertaining to configuration data.
3.1.1. Global Configuration Data
This branch of the data model covers configuration of elements that
control RSVP protocol behavior.
Beeram, et al. Expires September 9, 2015 [Page 8]
Internet-Draft RSVP YANG Data Model March 2015
module: ietf-rsvp
+--rw rsvp!
+--rw globals
| +--rw signaling
| +--rw graceful-restart! {graceful-restart}?
| | +--rw restart-time? uint32
| | +--rw recovery-time? uint32
| +--rw hello {hellos}?
| | +--rw interface-based? empty
| | +--rw hello-interval? uint32
| | +--rw hello-misses? uint32
| +--rw path-err
| | +--rw state-removal? empty
| +--rw refresh
| +--rw interval? uint32
| +--rw missed? uint32
| +--rw reduction {refresh-reduction}?
| +--rw bundle-message-max-size? uint32
| +--rw disable? empty
| +--rw reliable-ack-hold-time? uint32
| +--rw reliable-ack-max-size? uint32
| +--rw reliable-retransmit-time? uint32
| +--rw reliable-srefresh? empty
| +--rw summary-max-size? uint32
3.1.2. Interface Configuration Data
This branch of the data model covers configuration of elements
relevant to RSVP interfaces.
module: ietf-rsvp
+--rw rsvp!
+--rw interfaces
| +--rw authentication {authentication}?
| | +--rw key-chain? string
| | +--rw lifetime? uint32
| | +--rw window-size? uint32
| | +--rw challenge? empty
| | +--rw retransmits? uint32
| +--rw signaling
| | +--rw graceful-restart! {graceful-restart}?
| | | +--rw restart-time? uint32
| | | +--rw recovery-time? uint32
| | +--rw hello {hellos}?
| | | +--rw interface-based? empty
| | | +--rw hello-interval? uint32
| | | +--rw hello-misses? uint32
| | +--rw path-err
Beeram, et al. Expires September 9, 2015 [Page 9]
Internet-Draft RSVP YANG Data Model March 2015
| | | +--rw state-removal? empty
| | +--rw refresh
| | +--rw interval? uint32
| | +--rw missed? uint32
| | +--rw reduction {refresh-reduction}?
| | +--rw bundle-message-max-size? uint32
| | +--rw disable? empty
| | +--rw reliable-ack-hold-time? uint32
| | +--rw reliable-ack-max-size? uint32
| | +--rw reliable-retransmit-time? uint32
| | +--rw reliable-srefresh? empty
| | +--rw summary-max-size? uint32
| +--rw interface* [interface]
| +--rw interface if:interface-ref
| +--rw authentication {authentication}?
| | +--rw key-chain? string
| | +--rw lifetime? uint32
| | +--rw window-size? uint32
| | +--rw challenge? empty
| | +--rw retransmits? uint32
| +--rw signaling
| +--rw graceful-restart! {graceful-restart}?
| | +--rw restart-time? uint32
| | +--rw recovery-time? uint32
| +--rw hello {hellos}?
| | +--rw interface-based? empty
| | +--rw hello-interval? uint32
| | +--rw hello-misses? uint32
| +--rw path-err
| | +--rw state-removal? empty
| +--rw refresh
| +--rw interval? uint32
| +--rw missed? uint32
| +--rw reduction {refresh-reduction}?
| +--rw bundle-message-max-size? uint32
| +--rw disable? empty
| +--rw reliable-ack-hold-time? uint32
| +--rw reliable-ack-max-size? uint32
| +--rw reliable-retransmit-time? uint32
| +--rw reliable-srefresh? empty
| +--rw summary-max-size? uint32
3.1.3. Session Configuration Data
This branch of the data model covers configuration of elements
relevant to RSVP neighbors. This would be discussed in detail in
future revisions.
Beeram, et al. Expires September 9, 2015 [Page 10]
Internet-Draft RSVP YANG Data Model March 2015
module: ietf-rsvp
+--rw rsvp!
+--rw sessions
| +--rw session* [src_port dst_port source destination]
| +--rw src_port uint16
| +--rw dst_port uint16
| +--rw source inet:ip-address
| +--rw destination inet:ip-address
3.1.4. Neighbor Configuration Data
This branch of the data model covers configuration of elements
relevant to RSVP sessions. This would be discussed in detail in
future revisions.
module: ietf-rsvp
+--rw rsvp!
+--rw neighbors
| +--rw neighbor* [address]
| +--rw address inet:ip-address
3.2. RSVP State Data
The following subsections provide overview of the parts of the model
that hold state data.
3.2.1. Global State Data
This branch of the model covers global State Data. This would be
discussed in detail in future revisions.
3.2.2. Interface State Data
This branch of the model covers state data for RSVP interfaces. This
would be discussed in detail in future revisions.
3.2.3. Neighbor State Data
This branch of the model covers state data for RSVP neighbors. This
would be discussed in detail in future revisions.
3.2.4. Session State Data
This branch of the model covers state data for RSVP sessions. This
would be discussed in detail in future revisions.
Beeram, et al. Expires September 9, 2015 [Page 11]
Internet-Draft RSVP YANG Data Model March 2015
3.3. RSVP RPC Data
The following subsections provide overview of the parts of the model
pertaining to RPC data.
3.4. Global RPC Data
This branch of the model covers RPC execution commands for triggering
actions on global RSVP Data. This would be discussed in detail in
future revisions.
3.4.1. Interface RPC Data
This branch of the model covers RPC execution commands for RSVP
interfaces. This would be discussed in detail in future revisions.
3.4.2. Neighbor RPC Data
This branch of the model covers RPC execution commands for RSVP
neighbors. This would be discussed in detail in future revisions.
3.4.3. Session RPC Data
This branch of the model covers RPC execution commands for RSVP
sessions. This would be discussed in detail in future revisions
3.5. RSVP Notification Data
The following subsections provide overview of the parts of the model
pertaining to notification data.
3.5.1. Global Notification Data
This branch of the model covers notifications pertaining to global
RSVP data. This would be discussed in detail in future revisions.
3.5.2. Interface Notification Data
This branch of the model covers notifications pertaining to RSVP
interfaces. This would be discussed in detail in future revisions.
3.5.3. Neighbor Notification Data
This branch of the model covers notifications pertaining to RSVP
neighbors. This would be discussed in detail in future revisions.
Beeram, et al. Expires September 9, 2015 [Page 12]
Internet-Draft RSVP YANG Data Model March 2015
3.5.4. Session Notification Data
This branch of the model covers notifications pertaining to RSVP
sessions. This would be discussed in detail in future revisions
4. RSVP YANG Module
<CODE BEGINS>
module ietf-rsvp {
namespace "urn:ietf:params:xml:ns:yang:rsvp";
/* Replace with IANA when assigned */
prefix "rsvp";
/* import ietf-inet-types { prefix inet; } */
import ietf-interfaces {
prefix "if";
}
import ietf-inet-types {
prefix inet;
}
organization
"IETF TEAS Working Group";
contact "TBA";
description
"This module contains the RSVP YANG data model.";
revision 2014-12-17 {
description "Initial revision.";
}
/* RSVP features */
feature authentication {
description
"Indicates support for RSVP authentication";
}
feature graceful-restart {
description
"Indicates support for RSVP graceful restart";
}
feature refresh-reduction {
Beeram, et al. Expires September 9, 2015 [Page 13]
Internet-Draft RSVP YANG Data Model March 2015
description
"Indicates support for RSVP refresh reduction";
}
feature hellos {
description
"Indicates support for RSVP hellos";
}
grouping graceful-restart {
description "Configure RSVP Graceful-Restart parameters.";
container graceful-restart {
if-feature graceful-restart;
presence "Enable RSVP graceful restart on the node.";
leaf restart-time {
description
"Graceful restart time (seconds).";
reference
"RFC 5495: Description of the Resource
Reservation Protocol - Traffic-Engineered (RSVP-TE)
Graceful Restart Procedures";
type uint32;
}
leaf recovery-time {
description
"";
type uint32;
}
}
}
grouping authentication {
container authentication {
if-feature authentication;
description
"Configure RSVP authentication.";
leaf key-chain {
description
"Key chain name to authenticate RSVP signaling
messages.";
reference
"RFC 2747: RSVP Cryptographic Authentication";
type string {
length "1..32";
}
}
leaf lifetime {
Beeram, et al. Expires September 9, 2015 [Page 14]
Internet-Draft RSVP YANG Data Model March 2015
description
"Life time for each security association";
reference
"RFC 2747: RSVP Cryptographic Authentication";
type uint32 {
range "30..86400";
}
}
leaf window-size {
description
"Window-size to limit number of out-of-order
messages.";
reference
"RFC 2747: RSVP Cryptographic Authentication";
type uint32 {
range "1..64";
}
}
leaf challenge {
description
"Enable challenge messages.";
reference
"RFC 2747: RSVP Cryptographic Authentication";
type empty;
}
leaf retransmits {
description
"Number of retransmits when messages are dropped.";
reference
"RFC 2747: RSVP Cryptographic Authentication";
type uint32 {
range "1..10000";
}
}
}
}
grouping signaling {
container signaling {
uses graceful-restart;
container hello {
if-feature hellos;
description "Configure Hello parameters.";
leaf interface-based {
description "Enable interface-based
Hello adjacency if present.";
type empty;
}
Beeram, et al. Expires September 9, 2015 [Page 15]
Internet-Draft RSVP YANG Data Model March 2015
leaf hello-interval {
description
"Configure interval between successive Hello
messages in milliseconds.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP
Tunnels RFC 5495: Description of the Resource
Reservation Protocol - Traffic-Engineered
(RSVP-TE) Graceful Restart Procedures";
type uint32 {
range "3000..30000";
}
}
leaf hello-misses {
description
"Configure max number of consecutive missed
Hello messages.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP
Tunnels.
RFC 5495: Description of the Resource
Reservation Protocol - Traffic-Engineered
(RSVP-TE)
Graceful Restart Procedures";
type uint32 {
range "1..10";
}
}
}
container path-err {
leaf state-removal {
description
"State-Removal flag in Path Error message
if present.";
type empty;
}
}
container refresh {
leaf interval {
description
"Set interval between successive refreshes";
type uint32;
}
leaf missed {
description
"Set max number of consecutive missed messages
Beeram, et al. Expires September 9, 2015 [Page 16]
Internet-Draft RSVP YANG Data Model March 2015
for state expiry";
type uint32;
}
container reduction {
if-feature refresh-reduction;
description
"Configure RSVP Refresh Reduction parameters.";
leaf bundle-message-max-size {
description
"Configure maximum size (bytes) of a single
RSVP Bundle message.";
type uint32 {
range "512..65000";
}
}
leaf disable {
description
"Disable refresh reduction if present.";
type empty;
}
leaf reliable-ack-hold-time {
description
"Configure hold time in milliseconds for
sending RSVP ACK message(s).";
type uint32 {
range "100..5000";
}
}
leaf reliable-ack-max-size {
description
"Configure max size of a single RSVP ACK
message.";
type uint32 {
range "20..65000";
}
}
leaf reliable-retransmit-time {
description
"Configure min delay in milliseconds to wait
for an ACK before a retransmit.";
type uint32 {
range "100..10000";
}
}
leaf reliable-srefresh {
description
"Configure use of reliable messaging fori
Beeram, et al. Expires September 9, 2015 [Page 17]
Internet-Draft RSVP YANG Data Model March 2015
summary refresh if present.";
type empty;
}
leaf summary-max-size {
description
"Configure max size (bytes) of a single RSVP
summary refresh message.";
type uint32 {
range "20..65000";
}
}
}
}
}
}
container rsvp {
presence "Enable RSVP feature";
container globals {
description "RSVP global properties.";
uses signaling;
}
container interfaces {
uses authentication;
uses signaling;
list interface {
key "interface";
description
"RSVP interfaces.";
leaf interface {
description
"RSVP interface.";
type if:interface-ref;
}
uses authentication;
uses signaling;
}
}
container sessions {
list session {
key "src_port dst_port source destination";
leaf src_port {
type uint16;
description "RSVP source port";
reference "RFC2205";
Beeram, et al. Expires September 9, 2015 [Page 18]
Internet-Draft RSVP YANG Data Model March 2015
}
leaf dst_port {
type uint16;
description "RSVP destination port";
reference "RFC2205";
}
leaf source {
type inet:ip-address;
description "RSVP source address";
reference "RFC2205";
}
leaf destination {
type inet:ip-address;
description "RSVP destination address";
reference "RFC2205";
}
}
}
container neighbors {
list neighbor {
key "address";
leaf address {
type inet:ip-address;
}
}
}
container interface-state {
config "false";
list session {
key "interface";
description
"RSVP interfaces.";
leaf interface {
description
"RSVP interface.";
type if:interface-ref;
}
}
}
container sessions-state {
config "false";
list session {
key "src_port dst_port source destination";
leaf src_port {
type uint16;
Beeram, et al. Expires September 9, 2015 [Page 19]
Internet-Draft RSVP YANG Data Model March 2015
description "RSVP source port";
reference "RFC2205";
}
leaf dst_port {
type uint16;
description "RSVP destination port";
reference "RFC2205";
}
leaf source {
type inet:ip-address;
description "RSVP source address";
reference "RFC2205";
}
leaf destination {
type inet:ip-address;
description "RSVP destination address";
reference "RFC2205";
}
}
}
container neighbors-state {
config "false";
list neighbor {
key "address";
leaf address {
type inet:ip-address;
}
}
}
}
}
<CODE ENDS>
5. Appendix A: RSVP-TE YANG Model
This section includes the initial version of the YANG model for the
extensions to the RSVP protocol to signal Traffic-Engineering (RSVP-
TE) Label Switched Paths (LSPs). The initial version of the RSVP-TE
YANG module covers data items specific to packet technology. It is
expected, however, that RSVP-TE YANG models for technology specific
data (e.g. OTN or WDM) will be defined in separate modules and in
other drafts in future revisions.
This model imports and augments the base RSVP YANG model (presented
in section 4 (Section 4). It also imports and augments the TE YANG
Beeram, et al. Expires September 9, 2015 [Page 20]
Internet-Draft RSVP YANG Data Model March 2015
model defined in [draft-saad-teas-yang-te-00] to enable configuration
of RSVP-TE attributes on TE tunnels.
5.1. RSVP-TE Configuration Data
The following subsections provide overview of the parts of the RSVP-
TE model pertaining to configuration data.
There are tree types of configuration data nodes in this module:
o those augmenting or extending the base RSVP module
o those augmenting or extending the base TE module
o those that are specific to the RSVP-TE module
Below is a YANG tree representation for data items defined in the
RSVP-TE module:
Beeram, et al. Expires September 9, 2015 [Page 21]
Internet-Draft RSVP YANG Data Model March 2015
module: ietf-rsvp-te
augment /rsvp:rsvp/rsvp:globals:
+--rw frr-local-revert!
+--rw frr-local-revert-delay? uint32
augment /ietf-te:te/ietf-te:tunnels/ietf-te:tunnel:
+--rw end-to-end-routing? empty
+--rw boundary-rerouting? empty
+--rw segment-based-rerouting? empty
+--rw lsp-integrety-required? empty
+--rw contiguous-lsp? empty
+--rw lsp-stitching-desired? empty
+--rw preplanned-lsp? empty
+--rw non-php-desired? empty
+--rw oob-mapping? empty
+--rw entropy-label-cap? empty
+--rw oam-mep-entities-desired? empty
+--rw oam-mip-entities-desired? empty
+--rw source? inet:ip-address
+--rw fast-reroute!
| +--rw bandwidth-protection-desired? empty
| +--rw node-protection-desired? empty
+--rw se-style-desired? empty
+--rw soft-preemption-desired? empty
+--rw record-route-desired? empty
+--rw signaled-name? string
+--rw priority
| +--rw setup? uint8
| +--rw hold? uint8
+--rw soft-preemption? empty
augment /rsvp:rsvp/rsvp:interfaces:
+--rw signaling
+--rw egress-label? ietf-te-psc-types:egress-label
augment /rsvp:rsvp/rsvp:interfaces/rsvp:interface:
+--rw signaling
+--rw egress-label? ietf-te-psc-types:egress-label
augment /rsvp:rsvp/rsvp:sessions:
augment /rsvp:rsvp/rsvp:neighbors:
augment /rsvp:rsvp/rsvp:sessions-state:
augment /rsvp:rsvp/rsvp:neighbors-state:
rpcs:
+---x sessions-rpc
+---x interfaces-rpc
notifications:
+---n sessions-notif
+---n interfaces-notif
Beeram, et al. Expires September 9, 2015 [Page 22]
Internet-Draft RSVP YANG Data Model March 2015
5.2. RSVP-TE State Data
It is expected that operational/state RSVP-TE data will extend the
RSVP and TE basic data. This will be detailed in future revisions.
5.3. RSVP-TE YANG Module
<CODE BEGINS>
module ietf-rsvp-te {
namespace "urn:ietf:params:xml:ns:yang:ietf-rsvp-te";
prefix "rsvp-te";
import ietf-rsvp {
prefix rsvp;
}
/* Import TE packet specific types */
import ietf-te-psc-types {
prefix ietf-te-psc-types;
}
import ietf-te {
prefix ietf-te;
}
import ietf-inet-types {
prefix inet;
}
/* groupings for rsvp */
grouping signaling {
container signaling {
description "Configure RSVP signaling properties.";
leaf egress-label {
type ietf-te-psc-types:egress-label;
}
}
}
grouping lsp-attributes {
leaf end-to-end-routing {
reference "RFC4920, RFC5420";
type empty;
}
leaf boundary-rerouting {
Beeram, et al. Expires September 9, 2015 [Page 23]
Internet-Draft RSVP YANG Data Model March 2015
reference "RFC4920, RFC5420";
type empty;
}
leaf segment-based-rerouting {
reference "RFC4920, RFC5420";
type empty;
}
leaf lsp-integrety-required {
reference "RFC4875";
type empty;
}
leaf contiguous-lsp {
reference "RFC5151";
type empty;
}
leaf lsp-stitching-desired {
reference "RFC5150";
type empty;
}
leaf preplanned-lsp {
reference "RFC6001";
type empty;
}
leaf non-php-desired {
reference "RFC6511";
type empty;
}
leaf oob-mapping {
reference "RFC6511";
type empty;
}
leaf entropy-label-cap {
reference "RFC6790";
type empty;
}
leaf oam-mep-entities-desired {
reference "RFC7260";
type empty;
}
leaf oam-mip-entities-desired {
reference "RFC7260";
type empty;
}
}
grouping lsp-signaling-properties {
description "LSP signaling properties.";
uses lsp-attributes;
Beeram, et al. Expires September 9, 2015 [Page 24]
Internet-Draft RSVP YANG Data Model March 2015
leaf source {
description
"LSP source address.";
type inet:ip-address;
}
container fast-reroute {
presence "FRR local protection is desired.";
reference
"RFC4859: Registry for RSVP-TE Session Flags";
leaf bandwidth-protection-desired {
description
"Request FRR bandwidth protection on LSRs if
present.";
type empty;
}
leaf node-protection-desired {
description
"Request FRR node protection on LSRs if present.";
type empty;
}
}
leaf se-style-desired {
description "SE Style desired";
reference "RFC3209";
type empty;
}
leaf soft-preemption-desired {
description "Soft-preemption is desired";
reference "RFC5712";
type empty;
}
leaf record-route-desired {
description "Path recording is desired.";
reference "RFC3209";
type empty;
}
leaf signaled-name {
description
"Sets the session name to use in the session attribute
object.";
type string;
}
container priority {
description
"Sets the setup/hold priority to use in the session
attribute object.";
leaf setup {
type uint8 {
Beeram, et al. Expires September 9, 2015 [Page 25]
Internet-Draft RSVP YANG Data Model March 2015
range "0..7";
}
}
leaf hold {
type uint8 {
range "0..7";
}
}
}
leaf soft-preemption {
description
"Requests soft-preemption in session
attributes object at
at traversed LSR(s).";
type empty;
}
}
/* RSVP-TE global propeerties */
augment "/rsvp:rsvp/rsvp:globals" {
container frr-local-revert {
presence "Enable RSVP FRR local revertive recovery mode.";
leaf frr-local-revert-delay {
description
"Time to wait after primary link is restored
before node attempts local revertive procedures.";
type uint32;
}
}
}
augment "/ietf-te:te/ietf-te:tunnels/ietf-te:tunnel" {
uses lsp-signaling-properties;
}
/* Linkage to the base RSVP all links */
augment "/rsvp:rsvp/rsvp:interfaces" {
uses signaling;
}
/* Linkage to per RSVP link */
augment "/rsvp:rsvp/rsvp:interfaces/rsvp:interface" {
uses signaling;
}
/* TSAAD: add augmentation for sessions neighbors */
augment "/rsvp:rsvp/rsvp:sessions" {
Beeram, et al. Expires September 9, 2015 [Page 26]
Internet-Draft RSVP YANG Data Model March 2015
/* To be added */
}
augment "/rsvp:rsvp/rsvp:neighbors" {
/* To be added */
}
augment "/rsvp:rsvp/rsvp:sessions-state" {
/* To be added */
}
augment "/rsvp:rsvp/rsvp:neighbors-state" {
/* To be added */
}
}
<CODE ENDS>
6. IANA Considerations
This document registers the following URIs in the IETF XML registry
[RFC3688]. Following the format in [RFC3688], the following
registration is requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-rsvp XML: N/A, the requested
URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-rsvp-te XML: N/A, the requested
URI is an XML namespace.
This document registers a YANG module in the YANG Module Names
registry [RFC6020].
name: ietf-rsvp namespace: urn:ietf:params:xml:ns:yang:ietf-rsvp
prefix: ietf-rsvp reference: RFC3209
name: ietf-rsvp-te namespace: urn:ietf:params:xml:ns:yang:ietf-rsvp-
te prefix: ietf-rsvp-te reference: RFC3209
7. Security Considerations
The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
secure transport layer and the mandatory-to-implement secure
transport is SSH [RFC6242]. The NETCONF access control model
[RFC6536] provides means to restrict access for particular NETCONF
users to a pre-configured subset of all available NETCONF protocol
operations and content.
Beeram, et al. Expires September 9, 2015 [Page 27]
Internet-Draft RSVP YANG Data Model March 2015
There are a number of data nodes defined in the YANG module which are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., <edit-config>)
to these data nodes without proper protection can have a negative
effect on network operations.
8. Acknowledgement
The authors would like to thank Lou Berger for reviewing and
providing valuable feedback on this document.
9. References
9.1. Normative References
[I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-17 (work in
progress), March 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC5063] Satyanarayana, A. and R. Rahman, "Extensions to GMPLS
Resource Reservation Protocol (RSVP) Graceful Restart",
RFC 5063, October 2007.
Beeram, et al. Expires September 9, 2015 [Page 28]
Internet-Draft RSVP YANG Data Model March 2015
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March
2012.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013.
[draft-saad-teas-yang-te-00]
Saad, T., Ed., Gandhi, R., Liu, X., Beeram, V., Shah, H.,
Chen, X., and R. Jones, "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", March 2015.
9.2. Informative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
Authors' Addresses
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Tarek Saad
Cisco Systems Inc
Email: tsaad@cisco.com
Rakesh Gandhi
Cisco Systems Inc
Email: rgandhi@cisco.com
Beeram, et al. Expires September 9, 2015 [Page 29]
Internet-Draft RSVP YANG Data Model March 2015
Xufeng Liu
Ericsson
Email: xufeng.liu@ericsson.com
Himanshu Shah
Ciena
Email: tsaad@cisco.com
Xia Chen
Huawei Technologies
Email: jescia.chenxia@huawei.com
Raqib Jones
Brocade
Email: raqib@Brocade.com
Beeram, et al. Expires September 9, 2015 [Page 30]