| 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
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.
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 (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.
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.
+---------------+
| Generic LSPDB |
| ietf-lspdb |
+-------^-------+
|
---------------------------------------------
| | | |
| | | |
+----+----+ +-------+-------+ +----+----+ +--+--+
| LDP-LSP | | BGP-LSP | | TE-LSP | | SR |
| | | | | | | |
+---------+ +---------------+ +----^----+ +--^--+
| |
-----------
| |
| |
+----+----+ +--+--+
| RSVP-TE | | SR- |
| | | TE |
+----^----+ +--^--+
| |
| |
-----------
|
+----+----+
| PCEP |
| |
+---------+
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.
This document contains a specification of the base LSPDB YANG module, "ietf-lspdb".
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].
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]:
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] |
This section describes some of the design objectives for the model:
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
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.
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).
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.
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.
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).
<CODE BEGINS> 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";
}
import ietf-interfaces {
prefix "if";
}
organization
"IETF XXX Working Group";
contact
"
Editor: Dhruv dhody
<dhruv.dhody@huawei.com>
Editor: Xian ZHANG
<zhang.xian@huawei.com>";
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 {
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";
}
}
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";
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
"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";
}
}
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
<CODE ENDS>
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., <edit-config>) 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.
This document registers a URI in the "IETF XML Registry" [RFC3688]. Following the format in RFC 3688, the following registration has been made.
Name: ietf-lspdb
Namespace: urn:ietf:params:xml:ns:yang:ietf-lspdb
Prefix: lspdb
Reference: This I-D
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].
| [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. |
| [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", Internet-Draft draft-ietf-netmod-rfc6087bis-01, October 2014. |