MPLS Working Group X. Zhang Internet-Draft D. Dhody Intended status: Standards Track Huawei Technologies Expires: September 4, 2015 March 3, 2015 A generic YANG Data Model for Label Switch Path (LSP). draft-zhang-mpls-lspdb-yang-00 Abstract This document defines a generic YANG data model for the Label Switch Paths (LSPs). The data model includes the operational state of LSP (LSP-DB). It is expected that this modules will be augmented by additional YANG modules defining data models for signalling protocol and other functions. 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 4, 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. Zhang & Dhody Expires September 4, 2015 [Page 1] Internet-Draft LSPDB-YANG March 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Prefixes in Data Node Names . . . . . . . . . . . . . . . . . 4 5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. The Design of LSP-DB Data Model . . . . . . . . . . . . . . . 5 6.1. The Lsp-entry Lists . . . . . . . . . . . . . . . . . . . 5 6.2. Incoming/Outgoing Containers . . . . . . . . . . . . . . 6 6.3. Primary/Backup Lists . . . . . . . . . . . . . . . . . . 6 7. The LSP-DB YANG Module . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Manageability Considerations . . . . . . . . . . . . . . . . 13 9.1. Control of Function and Policy . . . . . . . . . . . . . 13 9.2. Information and Data Models . . . . . . . . . . . . . . . 13 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 13 9.6. Impact On Network Operations . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path (LSP) has various common attributes irrespective of the protocol and signalling mechanism (For example, RSVP-TE, LDP, BGP, PCEP etc). The objective of this document is to write a high level generic LSP database module to capture these common attributes. Thus this document defines YANG [RFC6020] data model for a generic high-level tree structures of MPLS and GMPLS LSPs. Further modules augmenting this data model with specific signalling protocol, technology or advanced features will be handled in a separate document A possible relationship is roughly depicted in the figure below. Zhang & Dhody Expires September 4, 2015 [Page 2] Internet-Draft LSPDB-YANG March 2015 +---------------+ | Generic LSPDB | | ietf-lspdb | +-------^-------+ | --------------------------------------------- | | | | | | | | +----+----+ +-------+-------+ +----+----+ +--+--+ | LDP-LSP | | BGP-LSP | | TE-LSP | | SR | | | | | | | | | +---------+ +---------------+ +----^----+ +--^--+ | | ----------- | | | | +----+----+ +--+--+ | RSVP-TE | | SR- | | | | TE | +----^----+ +--^--+ | | | | ----------- | +----+----+ | PCEP | | | +---------+ This document contains a specification of the base LSPDB YANG module, "ietf-lspdb". 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Tree Diagrams A graphical representation of the complete data tree is presented in Section 6. The meaning of the symbols in these diagrams is as follows and as per [I-D.ietf-netmod-rfc6087bis]: o Brackets "[" and "]" enclose list keys. o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional. Zhang & Dhody Expires September 4, 2015 [Page 3] Internet-Draft LSPDB-YANG March 2015 o Abbreviations before data node names: "rw" means configuration (read-write), and "ro" state data (read-only). o Symbols after data node names: "?" means an optional node and "*" denotes a "list" or "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 4. Prefixes in Data Node Names In this document, names of data nodes and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1. +--------+-----------------+-----------+ | Prefix | YANG module | Reference | +--------+-----------------+-----------+ | yang | ietf-yang-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] | | if | ietf-interfaces | [RFC7223] | +--------+-----------------+-----------+ Table 1: Prefixes and corresponding YANG modules 5. Objectives This section describes some of the design objectives for the model: o In case of existing implementations, it needs to map the data model defined in this document to their proprietary native data model. To facilitate such mappings, the data model should be simple. o The data model should be suitable for new implementations to use as is. o Mapping to the MIB Module should be clear. o The data model should allow for static configurations of LSP. (Editors Note - Maybe taken for future) Zhang & Dhody Expires September 4, 2015 [Page 4] Internet-Draft LSPDB-YANG March 2015 o The data model should include read-only counters in order to gather statistics with errors. o It should be fairly straightforward to augment the base data model. 6. The Design of LSP-DB Data Model The module "ietf-lspdb", defines the generic components of a LSP-DB. This module will be augmented with with additional data nodes and features based on signalling protocol and advanced features. module: ietf-lspdb +--ro lspdb +--ro lsp-num? uint32 +--ro lsp-entry* [system-generated-id] +--ro system-generated-id uint64 +--ro lsp-signaling lsp-signalingtypes +--ro is-primary? boolean +--ro lsr-type? lsr-types +--ro source inet:ip-address +--ro destination inet:ip-address +--ro creation-time? yang:date-and-time +--ro last-change? yang:date-and-time +--ro operation-status? status-types +--ro incoming | +--ro incoming-interface? if:interface-state-ref | +--ro incoming-label +--ro outgoing | +--ro outgoing-interface? if:interface-state-ref | +--ro outgoing-label +--ro primary-lsp* lsp-ref +--ro backup-lsp* lsp-ref +--ro statistics 6.1. The Lsp-entry Lists The LSP-DB yang module contains the full LSP-DB and thus the status information for all LSPs. The data model presented in this document uses a flat list of LSPs. Each entity in the list is identified by a system generated id (system-generated-id). Furthermore, each entity has a mandatory "lsp-signaling" leaf (the signalling protocol/ mechanism). Zhang & Dhody Expires September 4, 2015 [Page 5] Internet-Draft LSPDB-YANG March 2015 6.2. Incoming/Outgoing Containers These containers contain the interface and label information in incoming and outgoing directions. A reference to the interface name to "ietf-interfaces" module [RFC7223] and an empty label container is maintained. The label should be augmented by the data plane specific YANG modules. 6.3. Primary/Backup Lists All LSPs (primary and backup) are maintained together in a single flat lsp-entry list. The relationship to other LSPs is maintained via the "primary-lsp" and "backup-lsp" leaf-lists. A LSP is identified by its system-generated-id, which is unique within the node. This property is captured in "lsp-ref" typedef, which other should use when they need to reference a LSP. Thus a list of references to primary and backup LSPs are maintained per LSP. 7. The LSP-DB YANG Module RFC Ed.: In this section, replace all occurrences of 'XXXX' with the actual RFC number and all occurrences of the revision date below with the date of RFC publication (and remove this note). file "ietf-lspdb@2015-03-xx.yang" module ietf-lspdb { namespace "urn:ietf:params:xml:ns:yang:ietf-lspdb"; prefix lspdb; import ietf-inet-types { prefix "inet"; } import ietf-yang-types { prefix "yang"; } Zhang & Dhody Expires September 4, 2015 [Page 6] Internet-Draft LSPDB-YANG March 2015 import ietf-interfaces { prefix "if"; } organization "IETF XXX Working Group"; contact " Editor: Dhruv dhody Editor: Xian ZHANG "; description "This module contains a collection of YANG definitions for configuring LSP database. The intent of this module is to serve as a base model and it is kept protocol-independent. It is expected that it will be augmented depending on the targeted protocol. Copyright (c) 2015 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info)."; revision 2015-03-05 { description "Initial revision."; reference "RFC XXX: A YANG Data Model for Label Switched Path (LSP) Database Management"; } /* * Features:none. */ /* * Typedefs */ typedef lsp-signalingtypes { Zhang & Dhody Expires September 4, 2015 [Page 7] Internet-Draft LSPDB-YANG March 2015 type enumeration { enum "rsvp" { value 1; description "Resource reSerVation Protocol."; } enum "ldp" { value 2; description "Label Distribution Protocol"; } enum "bgp" { value 3; description "Border Gateway Protocol."; } enum "sr" { value 4; description "Segment Routing."; } enum "static" { value 5; description "Manually Configured."; } } description "The signalling type of a LSP."; } typedef status-types { type enumeration { enum "up" { value 1; description "UP"; } enum "down" { value 2; description "Not working/failed"; } enum "standby" { value 3; description "Idle state, created by not used"; } Zhang & Dhody Expires September 4, 2015 [Page 8] Internet-Draft LSPDB-YANG March 2015 } description "The status types of a LSP."; } typedef lsr-types { type enumeration { enum "ingress" { value 1; description "Ingress node"; } enum "transit" { value 2; description "Transit node"; } enum "egress" { value 3; description "Egress node"; } } description "the role of the Label Switched Router (LSR) for a LSP entry."; } typedef lsp-ref { type leafref { path "/lspdb/lsp-entry/system-generated-id"; } description "This type is used by data models that need to reference other LSP."; } /* * Operational data nodes */ container lspdb { config false; description "This container defines the information of all the LSP a node has/stores"; Zhang & Dhody Expires September 4, 2015 [Page 9] Internet-Draft LSPDB-YANG March 2015 leaf lsp-num { type uint32; description "This stores the total number of LSPs, including working and backup."; } list lsp-entry { key "system-generated-id"; description "This define each LSP entry."; leaf system-generated-id { type uint64; description "This is generated by the local node and it is unique within this node"; } leaf lsp-signaling { type lsp-signalingtypes; mandatory true; description "The signalling protocol/mechanism for the LSP."; } leaf is-primary { type boolean; description "Whether a LSP is a primary or second LSP. 1-primary, 0-secondary"; } leaf lsr-type { type lsr-types; description "The role of this LSR with regard to the current LSP"; } leaf source { type inet:ip-address; mandatory true; description Zhang & Dhody Expires September 4, 2015 [Page 10] Internet-Draft LSPDB-YANG March 2015 "The Source node of this LSP"; } leaf destination { type inet:ip-address; mandatory true; description "The Destination node of this LSP"; } leaf creation-time { type yang:date-and-time; description "The time the LSP was created."; } leaf last-change { type yang:date-and-time; description "The time the LSP entered its current state."; } leaf operation-status { type status-types; description "The operational status of this LSP"; } container incoming { description "The incoming interface, label information."; leaf incoming-interface { type if:interface-state-ref; description "The reference to the name of the incoming interface."; } container incoming-label { description "Empty container, Label format to be augmented depending on the data plane technology"; } } Zhang & Dhody Expires September 4, 2015 [Page 11] Internet-Draft LSPDB-YANG March 2015 container outgoing { description "The outgoing interface, label information."; leaf outgoing-interface { type if:interface-state-ref; description "The reference to the name of the outgoing interface."; } container outgoing-label { description "Empty container, Label format to be augmented depending on the data plane technology"; } } leaf-list primary-lsp { type lsp-ref; description "A list of references to primary LSPs (if exist) for this LSP."; reference "xxx"; } leaf-list backup-lsp { type lsp-ref; description "A list of references to backup LSPs (if exist) for this LSP."; reference "xxx"; } container statistics { description "TBD"; } } } }//module Zhang & Dhody Expires September 4, 2015 [Page 12] Internet-Draft LSPDB-YANG March 2015 8. 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 the 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. TBD: List specific Subtrees and data nodes and their sensitivity/ vulnerability. 9. Manageability Considerations 9.1. Control of Function and Policy 9.2. Information and Data Models 9.3. Liveness Detection and Monitoring 9.4. Verify Correct Operations 9.5. Requirements On Other Protocols 9.6. Impact On Network Operations 10. IANA Considerations This document registers a URI in the "IETF XML Registry" [RFC3688]. Following the format in RFC 3688, the following registration has been made. URI: urn:ietf:params:xml:ns:yang:ietf-lspdb Registrant Contact: The MPLS WG of the IETF. XML: N/A; the requested URI is an XML namespace. This document registers a YANG module in the "YANG Module Names" registry [RFC6020]. Zhang & Dhody Expires September 4, 2015 [Page 13] Internet-Draft LSPDB-YANG March 2015 Name: ietf-lspdb Namespace: urn:ietf:params:xml:ns:yang:ietf-lspdb Prefix: lspdb Reference: This I-D 11. Acknowledgements 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013. [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, May 2014. 12.2. Informative References [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. [I-D.ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", draft-ietf-netmod-rfc6087bis-01 (work in progress), October 2014. Zhang & Dhody Expires September 4, 2015 [Page 14] Internet-Draft LSPDB-YANG March 2015 Appendix A. Contributor Addresses Authors' Addresses Xian Zhang Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R.China EMail: zhang.xian@huawei.com Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560037 India EMail: dhruv.ietf@gmail.com Zhang & Dhody Expires September 4, 2015 [Page 15]