Internet DRAFT - draft-zhang-mpls-lspdb-yang
draft-zhang-mpls-lspdb-yang
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).
<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";
}
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
<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 {
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
<CODE ENDS>
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., <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.
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]
