--- 1/draft-ietf-teas-yang-rsvp-08.txt 2018-05-08 20:13:09.416479229 -0700 +++ 2/draft-ietf-teas-yang-rsvp-09.txt 2018-05-08 20:13:09.492481062 -0700 @@ -1,96 +1,95 @@ TEAS Working Group V. Beeram Internet-Draft Juniper Networks Intended status: Standards Track T. Saad, Ed. -Expires: May 2, 2018 R. Gandhi +Expires: November 9, 2018 R. Gandhi Cisco Systems, Inc. X. Liu Jabil I. Bryskin Huawei Technologies H. Shah Ciena - October 29, 2017 + May 08, 2018 A YANG Data Model for Resource Reservation Protocol (RSVP) - draft-ietf-teas-yang-rsvp-08 + draft-ietf-teas-yang-rsvp-09 Abstract This document defines a YANG data model for the configuration and management of RSVP Protocol. The model covers the building blocks of the RSVP protocol that can be augmented and used by other RSVP extension models such as RVSP extensions to Traffic-Engineering (RSVP-TE). The model covers the 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/. + Drafts is at https://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 May 2, 2018. + This Internet-Draft will expire on November 9, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 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 + (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 2. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 2.1. Module Hierarchy . . . . . . . . . . . . . . . . . . . . 5 - 2.2. State Data Organization . . . . . . . . . . . . . . . . . 6 - 2.3. Configuration Inheritance . . . . . . . . . . . . . . . . 6 + 2.2. Configuration Inheritance . . . . . . . . . . . . . . . . 6 3. Model Organization . . . . . . . . . . . . . . . . . . . . . 7 3.1. RSVP Base YANG Model . . . . . . . . . . . . . . . . . . 7 3.1.1. Global Data . . . . . . . . . . . . . . . . . . . . . 8 - 3.1.2. Interface Data . . . . . . . . . . . . . . . . . . . 8 + 3.1.2. Interface Data . . . . . . . . . . . . . . . . . . . 9 3.1.3. Neighbor Data . . . . . . . . . . . . . . . . . . . . 9 3.1.4. Session Data . . . . . . . . . . . . . . . . . . . . 9 3.1.5. Tree Diagram . . . . . . . . . . . . . . . . . . . . 9 - 3.1.6. YANG Module . . . . . . . . . . . . . . . . . . . . . 13 - 3.2. RSVP Extended YANG Model . . . . . . . . . . . . . . . . 31 + 3.1.6. YANG Module . . . . . . . . . . . . . . . . . . . . . 14 + 3.2. RSVP Extended YANG Model . . . . . . . . . . . . . . . . 32 3.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 32 - 3.2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 33 + 3.2.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 34 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 5. Security Considerations . . . . . . . . . . . . . . . . . . . 44 - 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 44 + 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 45 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.1. Normative References . . . . . . . . . . . . . . . . . . 45 - 8.2. Informative References . . . . . . . . . . . . . . . . . 46 + 8.2. Informative References . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction YANG [RFC6020] is 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 @@ -164,145 +163,122 @@ | key-chain | ietf-key-chain | XX | +---------+----------------------+-----------+ Table 1: Prefixes and corresponding YANG modules 2. Design Considerations 2.1. Module Hierarchy The RSVP base YANG module augments the "control-plane-protocol" list - in ietf-routing [RFC8022] module with specific RSVP parameters in an + in ietf-routing [RFC8349] module with specific RSVP parameters in an "rsvp" container. It also defines an extensiion identity "rsvp" of base "rt:routing-protocol" to identify the RSVP protocol. - During modeling discussion, some RSVP features are categorized as - core to the functionality of the protocol, and hence, are supported - by all vendors claiming the support for RSVP. These features' - configuration and state were grouped in the RSVP base module. + Some RSVP features are categorized as core to the function of the + protocol that are supported by most vendors claiming support for RSVP + protocol. Such features configuration and state are grouped in the + RSVP base module. Other extended RSVP features are categorized as either optional or - providing additional knobs to provide better tune basic functionality - of the RSVP protocol. The support for extended RSVP features by all - vendors was considered optional. Such features were grouped in a - separate RSVP extended module. + providing knobs to better tune basic functionality of the RSVP + protocol. The support for extended RSVP features by all vendors is + considered optional. Such features are grouped in a separate RSVP + extended module. The augmentation of the RSVP model by other models (e.g. RSVP-TE for - MPLS or other technologies) are considered outside the scope of this - document and discussed in separate document(s). + MPLS or other technologies) are outside the scope of this document + and are discussed in separate document(s), e.g. + [I-D.ietf-teas-yang-rsvp-te]. +--------------+ Routing | ietf-routing | +--------------+ o | +-----------+ RSVP module | ietf-rsvp | +-----------+ o | RSVP extended | module +--------------------+ | ietf-rsvp-extended | +--------------------+ Figure 1: Relationship of RSVP and RSVP extended modules with other protocol modules The RSVP base model does not aim to be feature complete. The primary - intent is to cover a set of standard core features (listed below) - that are commonly in use. + intent is to cover a set of standard core features that are commonly + in use. For example: o Authentication ([RFC2747]) o Refresh Reduction ([RFC2961]) o Hellos ([RFC3209]) o Graceful Restart ([RFC3473], [RFC5063]) The extended RSVP YANG model covers non-basic configuration(s) for RSVP feature(s) as well as optional RSVP feature that are not a must for basic RSVP operation. -2.2. State Data Organization - - The Network Management Datastore Architecture (NMDA) - [I-D.dsdt-nmda-guidelines] addresses the "OpState" that was discussed - in the IETF. As per NMDA guidelines for new models and models that - are not concerned with the operational state of configuration - information, this revision of the draft adopts the NMDA proposal for - configuration and state data of this model. - -2.3. Configuration Inheritance +2.2. Configuration Inheritance The defined data model supports configuration inheritance for neighbors, and interfaces. Data elements defined in the main container (e.g. the container that encompasses the list of interfaces, or neighbors) are assumed to apply equally to all elements of the list, unless overridden explicitly for a certain element (e.g. interface). Vendors are expected to augment the above container(s) to provide the list of inheritance command for their implementations. 3. Model Organization - This document divides the RSVP model into two modules: the RSVP base - and extended. Each module covers the configuration, state, - notification and RPCs of data. The relationship between the - different modules is depicted in Figure 1. + This document divides the RSVP model into two modules: base and + extended RSVP modules. Each module covers configuration, state, + notifications and RPCs data. The relationship between the different + modules is depicted in Figure 1. 3.1. RSVP Base YANG Model - This section describes the RSVP base YANG data model. The container - "rsvp" is the top level container in this data model. The presence - of this container enables the RSVP protocol functionality. + The RSVP base YANG data model defines thee container "rsvp" as the + top level container in this data model. The presence of this + container enables the RSVP protocol functionality. Data for such state is contained under the respective "state" sub- container of the intended object (e.g. interface) as shown in Figure 2. module: ietf-rsvp +--rw rsvp! +--rw globals - +-- rw config - <> - . - +-- ro state - <> - <> . . +--rw interfaces - +-- rw config - <> . +-- ro state - <> - <> + <> . . +--rw neighbors - +-- rw config - <> . +-- ro state - <> <> . . +--rw sessions - +-- rw config - <> . +-- ro state - <> <> . rpcs: +--x global-rpc +--x interfaces-rpc +--x neighbors-rpc +--x sessions-rpc notifications: +--n global-notif +--n interfaces-notif @@ -312,42 +288,40 @@ Figure 2: RSVP high-level tree model view The following subsections provide overview of the parts of the model pertaining to configuration and state data. Configuration and state data are organized into those applicable globally (node scope), per interfaces, per neighbors, or per session. 3.1.1. Global Data - This branch of the data model covers global configuration and states - that control RSVP protocol behavior. + The global data branch of the model covers configuration and state + that are applicable the RSVP protocol behavior. 3.1.2. Interface Data - This branch of the data model covers configuration and state elements - relevant to one or all RSVP interfaces. Any data configuration - applied at the "interfaces" container level are equally applicable to - all interfaces - unless overridden by explicit configuration under a - specific interface. + The interface data branch of the data model covers configuration and + state elements relevant to one or all RSVP interfaces. Any data + configuration applied at the "interfaces" container level are equally + applicable to all interfaces - unless overridden by explicit + configuration under a specific interface. 3.1.3. Neighbor Data - This branch of the data model covers configuration of elements - relevant to RSVP neighbors. This would be discussed in detail in - future revisions. + The neighbor data branch of the data model covers configuration and + state elements relevant to RSVP neighbors. 3.1.4. Session Data - This branch of the data model covers configuration of elements - relevant to RSVP sessions. This would be discussed in detail in - future revisions. + The sessions data branch covers configuration of elements relevant to + RSVP sessions. 3.1.5. Tree Diagram module: ietf-rsvp augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol: +--rw rsvp! +--rw globals | +--rw sessions | | +--ro session* [local-index] @@ -2024,21 +2007,21 @@ name: ietf-rsvp-extended namespace: urn:ietf:params:xml:ns:yang:ietf- rsvp-extended prefix: ietf-rsvp-extendeed reference: RFC3209 5. 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 + [RFC8341] 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. @@ -2063,23 +2046,23 @@ Bin Wen Comcast Email: Bin_Wen@cable.comcast.com 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, . + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, . @@ -2088,67 +2071,67 @@ Extensions", RFC 2961, DOI 10.17487/RFC2961, 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, DOI 10.17487/RFC3209, December 2001, . [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- - Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI - 10.17487/RFC3473, January 2003, . + Traffic Engineering (RSVP-TE) Extensions", RFC 3473, + DOI 10.17487/RFC3473, January 2003, + . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, - DOI 10.17487/RFC3688, January 2004, . + DOI 10.17487/RFC3688, January 2004, + . [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, - DOI 10.17487/RFC6020, October 2010, . + DOI 10.17487/RFC6020, October 2010, + . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . - [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration - Protocol (NETCONF) Access Control Model", RFC 6536, DOI - 10.17487/RFC6536, March 2012, . + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", + RFC 6991, DOI 10.17487/RFC6991, July 2013, + . - [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC - 6991, DOI 10.17487/RFC6991, July 2013, . + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration + Access Control Model", STD 91, RFC 8341, + DOI 10.17487/RFC8341, March 2018, + . - [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing - Management", RFC 8022, DOI 10.17487/RFC8022, November - 2016, . + [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for + Routing Management (NMDA Version)", RFC 8349, + DOI 10.17487/RFC8349, March 2018, + . 8.2. Informative References - [I-D.dsdt-nmda-guidelines] - Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., - and R. Wilton, "Guidelines for YANG Module Authors - (NMDA)", draft-dsdt-nmda-guidelines-01 (work in progress), - May 2017. + [I-D.ietf-teas-yang-rsvp-te] + Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., + and H. Shah, "A YANG Data Model for RSVP-TE", draft-ietf- + teas-yang-rsvp-te-03 (work in progress), February 2018. Authors' Addresses Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net Tarek Saad (editor) Cisco Systems, Inc.