draft-ietf-ccamp-otn-topo-yang-00.txt   draft-ietf-ccamp-otn-topo-yang-01.txt 
CCAMP Working Group H. Zheng CCAMP Working Group H. Zheng
Internet-Draft Z. Fan Internet-Draft Z. Fan
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: November 12, 2017 A. Sharma Expires: March 18, 2018 A. Sharma
Google Google
X. Liu X. Liu
Jabil Jabil
May 11, 2017 S. Belotti
Nokia
Y. Xu
CAICT
L. Wang
China Mobile
O. Gonzalez de Dios
Telefonica
September 14, 2017
A YANG Data Model for Optical Transport Network Topology A YANG Data Model for Optical Transport Network Topology
draft-ietf-ccamp-otn-topo-yang-00 draft-ietf-ccamp-otn-topo-yang-01
Abstract Abstract
A transport network is a server-layer network designed to provide A transport network is a server-layer network designed to provide
connectivity services for a client-layer network to carry the client connectivity services for a client-layer network to carry the client
traffic transparently across the server-layer network resources. A traffic transparently across the server-layer network resources. A
transport network can be constructed from equipments utilizing any of transport network can be constructed from equipments utilizing any of
a number of different transport technologies such as the evolving a number of different transport technologies such as the evolving
Optical Transport Networks (OTN) or packet transport as provided by Optical Transport Networks (OTN) or packet transport as provided by
the MPLS-Transport Profile (MPLS-TP). the MPLS-Transport Profile (MPLS-TP).
This draft describes a YANG data model to describe the topologies of This document describes a YANG data model to describe the topologies
an Optical Transport Network (OTN). It is independent of control of an Optical Transport Network (OTN). It is independent of control
plane protocols and captures topological and resource related plane protocols and captures topological and resource related
information pertaining to OTN. This model enables clients, which information pertaining to OTN. This model enables clients, which
interact with a transport domain controller via a REST interface, for interact with a transport domain controller via a REST interface, for
OTN topology related operations such as obtaining the relevant OTN topology related operations such as obtaining the relevant
topology resource information. topology resource information.
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].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2017. This Internet-Draft will expire on March 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents 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 publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3
3. YANG Data Model for OTN Topology . . . . . . . . . . . . . . 4 3. YANG Data Model for OTN Topology . . . . . . . . . . . . . . 4
3.1. the YANG Tree . . . . . . . . . . . . . . . . . . . . . . 4 3.1. the YANG Tree . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Explanation of the OTN Topology Data Model . . . . . . . 5 3.2. Explanation of the OTN Topology Data Model . . . . . . . 5
3.3. The YANG Code . . . . . . . . . . . . . . . . . . . . . . 5 3.3. The YANG Code . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Manageability Considerations . . . . . . . . . . . . . . . . 13 5. Manageability Considerations . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
A transport network is a server-layer network designed to provide A transport network is a server-layer network designed to provide
connectivity services for a client-layer network to carry the client connectivity services for a client-layer network to carry the client
traffic transparently across the server-layer network resources. A traffic transparently across the server-layer network resources. A
transport network can be constructed of equipments utilizing any of a transport network can be constructed of equipments utilizing any of a
number of different transport technologies such as the Optical number of different transport technologies such as the Optical
Transport Networks (OTN) or packet transport as provided by the MPLS- Transport Networks (OTN) or packet transport as provided by the MPLS-
Transport Profile (MPLS-TP). Transport Profile (MPLS-TP).
This document defines a data model of an OTN network topology, using This document defines a data model of an OTN network topology, using
YANG [RFC6020]. The model can be used by an application exposing to YANG [RFC7950]. The model can be used by an application exposing to
a transport controller via a REST interface. Furthermore, it can be a transport controller via a REST interface. Furthermore, it can be
used by an application for the following purposes (but not limited used by an application for the following purposes (but not limited
to): to):
o To obtain a whole view of the network topology information of its o To obtain a whole view of the network topology information of its
interest; interest;
o To receive notifications with regard to the information change of o To receive notifications with regard to the information change of
the OTN topology; the OTN topology;
o To enforce the establishment and update of a network topology with o To enforce the establishment and update of a network topology with
the characteristic specified in the data model, e.g., by a client the characteristic specified in the data model, e.g., by a client
controller; controller;
The YANG model defined in this draft is independent of control plane The YANG model defined in this document is independent of control
protocols and captures topology related information pertaining to an plane protocols and captures topology related information pertaining
Optical Transport Networks (OTN)-electrical layer, as the scope to an Optical Transport Networks (OTN)-electrical layer, as the scope
specified by [RFC7062] and [RFC7138]. Furthermore, it is not a specified by [RFC7062] and [RFC7138]. Furthermore, it is not a
stand-alone model, but augmenting from the TE topology YANG model stand-alone model, but augmenting from the TE topology YANG model
defined in [I-D.ietf-teas-yang-te-topo]. defined in [I-D.ietf-teas-yang-te-topo].
Optical network technologies, including fixed Dense Wavelength Optical network technologies, including fixed Dense Wavelength
Switched Optical Network (WSON) and flexible optical networks Switched Optical Network (WSON) and flexible optical networks
(a.k.a., flexi-grid networks), are covered in (a.k.a., flexi-grid networks), are covered in
[I-D.ietf-ccamp-wson-yang] and [I-D.vergara-ccamp-flexigrid-yang], [I-D.ietf-ccamp-wson-yang] and [I-D.vergara-ccamp-flexigrid-yang],
respectively. respectively.
2. Terminology and Notations 2. Terminology and Notations
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in the YANG data tree this document. The meaning of the symbols in the YANG data tree
presented later in this draft is defined in presented later in this document is defined in
[I-D.ietf-netmod-rfc6087bis]. They are provided below for reference. [I-D.ietf-netmod-yang-tree-diagrams]. They are provided below for
reference.
o Brackets "[" and "]" enclose list keys. o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration o Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only). (read-write) and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node, "!" o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list. means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
skipping to change at page 4, line 14 skipping to change at page 5, line 4
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":"). marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not o Ellipsis ("...") stands for contents of subtrees that are not
shown. shown.
3. YANG Data Model for OTN Topology 3. YANG Data Model for OTN Topology
3.1. the YANG Tree 3.1. the YANG Tree
module: ietf-otn-topology module: ietf-otn-topology
augment /nd:networks/nd:network/nd:network-types/tet:te-topology: augment /nd:networks/nd:network/nd:network-types/tet:te-topology:
+--rw otn-topology! +--rw otn-topology!
augment /nd:networks/nd:network: augment /nd:networks/nd:network:
+--rw name? string +--rw name? string
augment /nd:networks/nd:network/nd:node: augment /nd:networks/nd:network/nd:node:
+--rw name? string +--rw name? string
augment /nd:networks/nd:network/lnk:link/tet:te/tet:config: augment /nd:networks/nd:network/lnk:link/tet:te/tet:config:
+--rw available-odu-info* [priority] +--rw available-odu-info* [priority]
| +--rw priority uint8 | +--rw priority uint8
| +--rw odulist* [odu-type] | +--rw odulist* [odu-type]
| +--rw odu-type identityref | | +--rw odu-type identityref
| +--rw number? uint16 | | +--rw number? uint16
+--rw distance? uint32 | | +--rw tpn-range? string
augment /nd:networks/nd:network/lnk:link/tet:te/tet:state: | +--rw ts-range? string
+--ro available-odu-info* [priority] +--rw tsg? identityref
| +--ro priority uint8 +--rw distance? uint32
| +--ro odulist* [odu-type] augment /nd:networks/nd:network/lnk:link/tet:te/tet:state:
| +--ro odu-type identityref +--ro available-odu-info* [priority]
| +--ro number? uint16 | +--ro priority uint8
+--ro distance? uint32 | +--ro odulist* [odu-type]
augment /nd:networks/nd:network/nd:node/lnk:termination-point | | +--ro odu-type identityref
/tet:te/tet:config: | | +--ro number? uint16
+--rw client-facing? empty | | +--ro tpn-range? string
+--rw tpn? uint16 | +--ro ts-range? string
+--rw tsg? identityref +--ro tsg? identityref
+--rw protocol-type? identityref +--ro distance? uint32
+--rw adaptation-type? adaptation-type augment /nd:networks/nd:network/nd:node/lnk:termination-point
+--rw sink-adapt-active? boolean /tet:te/tet:config:
+--rw source-adapt-active? boolean +--rw supported-payload-types* [index]
+--rw tributary-slots +--rw index uint16
| +--rw values* uint8 +--rw payload-type? string
+--rw supported-payload-types* [index] augment /nd:networks/nd:network/nd:node/lnk:termination-point
+--rw index uint16 /tet:te/tet:state:
+--rw payload-type? string +--ro supported-payload-types* [index]
augment /nd:networks/nd:network/nd:node/lnk:termination-point/ +--ro index uint16
tet:te/tet:state: +--ro payload-type? string
+--ro client-facing? empty
+--ro tpn? uint16
+--ro tsg? identityref
+--ro protocol-type? identityref
+--ro adaptation-type? adaptation-type
+--ro sink-adapt-active? boolean
+--ro source-adapt-active? boolean
+--ro tributary-slots
| +--ro values* uint8
+--ro supported-payload-types* [index]
+--ro index uint16
+--ro payload-type? string
3.2. Explanation of the OTN Topology Data Model 3.2. Explanation of the OTN Topology Data Model
As can be seen, from the data tree shown in Section 3.1, the YANG As can be seen, from the data tree shown in Section 3.1, the YANG
module presented in this draft augments from a more generic Traffic module presented in this document augments from a more generic
Engineered (TE) network topology data model, i.e., the ietf-te- Traffic Engineered (TE) network topology data model, i.e., the ietf-
topology.yang as specified in [I-D.ietf-teas-yang-te-topo]. The te-topology.yang as specified in [I-D.ietf-teas-yang-te-topo]. The
entities and their attributes, such as node, termination points and entities and their attributes, such as node, termination points and
links, are still applicable for describing an OTN topology and the links, are still applicable for describing an OTN topology and the
model presented in this draft only specifies with technology-specific model presented in this document only specifies with technology-
attributes/information. For example, if the data plane complies with specific attributes/information. For example, if the data plane
ITU-T G.709 (2012) standards, the switching-capability and encoding complies with ITU-T G.709 (2012) standards, the switching-capability
attributes MUST be filled as OTN-TDM and G.709 ODUk(Digital Path) and encoding attributes MUST be filled as OTN-TDM and G.709
respectively. ODUk(Digital Path) respectively.
Note the model in this draft re-uses some attributes defined in ietf- Note the model in this document re-uses some attributes defined in
transport-types.yang, which is specified in ietf-transport-types.yang, which is specified in
[I-D.sharma-ccamp-otn-tunnel-model]. [I-D.ietf-ccamp-otn-tunnel-model].
One of the main augmentations in this model is that it allows to One of the main augmentations in this model is that it allows to
specify the type of ODU container and the number a link can support specify the type of ODU container and the number a link can support
per priority level. For example, for a ODU3 link, it may advertise per priority level. For example, for a ODU3 link, it may advertise
32*ODU0, 16*ODU1, 4*ODU2 available, assuming only a single priority 32*ODU0, 16*ODU1, 4*ODU2 available, assuming only a single priority
level is supported. If one of ODU2 resource is taken to establish a level is supported. If one of ODU2 resource is taken to establish a
ODU path, then the availability of this ODU link is updated as ODU path, then the availability of this ODU link is updated as
24*ODU0, 12*ODU1, 3*ODU2 available. If there are equipment hardware 24*ODU0, 12*ODU1, 3*ODU2 available. If there are equipment hardware
limitations, then a subset of potential ODU type SHALL be advertised. limitations, then a subset of potential ODU type SHALL be advertised.
For instance, an ODU3 link may only support 4*ODU2. For instance, an ODU3 link may only support 4*ODU2.
3.3. The YANG Code 3.3. The YANG Code
<CODE BEGINS> file "ietf-otn-topology@2017-04-25.yang" <CODE BEGINS> file "ietf-otn-topology@2017-09-14.yang"
module ietf-otn-topology { module ietf-otn-topology {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-otn-topology";
prefix "otntopo";
import ietf-network {
prefix "nd";
}
import ietf-network-topology {
prefix "lnk";
}
import ietf-te-topology {
prefix "tet";
}
import ietf-transport-types {
prefix "tran-types";
}
organization
"Internet Engineering Task Force (IETF) CCAMP WG";
contact
"
WG List: <mailto:ccamp@ietf.org>
ID-draft editor:
Haomian Zheng (zhenghaomian@huawei.com);
Zheyu Fan (fanzheyu2@huawei.com);
Anurag Sharma (ansha@google.com);
Xufeng Liu (Xufeng_Liu@jabil.com)
";
description
"This module defines a protocol independent Layer 1/ODU
topology data model.";
revision 2017-04-25 { namespace "urn:ietf:params:xml:ns:yang:ietf-otn-topology";
description prefix "otntopo";
"Revision 0.3";
reference
"draft-zhang-ccamp-l1-topo-yang-07.txt";
}
/* import ietf-network {
typedef prefix "nd";
*/
typedef adaptation-type {
type enumeration {
enum CBR {
description "Constant Bit Rate.";
}
enum ATMvp {
description "ATM VP.";
}
enum GFP {
description "Generic Framing Procedure.";
}
enum NULL {
description "NULL";
}
enum PRBS {
description "Pseudo Random Binary Sequence";
}
enum RSn {
description "SDH/SONET section";
}
enum ODUj-21 {
description "ODU payload type 21";
}
enum ETHERNET_PP-OS {
description "ETHERNET_PP-OS, for ODU 2 only";
}
enum CBRx {
description "CBRx(0.. 1.25G), for ODU0 only";
}
enum ODU {
description "Optical Data Unit";
}
} }
description import ietf-network-topology {
"Defines a type representing the adaptation type prefix "lnk";
on the termination point.";
}
/*
Groupings
*/
grouping otn-topology-type {
container otn-topology {
presence "indicates a topology type of Optical
Transport Network (OTN)-electrical layer.";
description "otn topology type";
} }
description "otn-topology-type";
}
grouping otn-topology-attributes { import ietf-te-topology {
leaf name { prefix "tet";
type string; revision-date 2017-06-10;
description "the topology name";
} }
description "name attribute for otn topology";
}
grouping otn-node-attributes { import ietf-transport-types {
description "otn-node-attributes"; prefix "tran-types";
leaf name {
type string;
description "a name for this node.";
} }
} organization
"IETF CCAMP Working Group";
grouping otn-link-attributes { contact
description "otn link attributes"; "WG Web: <http://tools.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org>
list available-odu-info{
key "priority";
max-elements "8";
description Editor: Haomian Zheng
"List of ODU type and number on this link"; <mailto:zhenghaomian@huawei.com>
leaf priority {
type uint8 {
range "0..7";
}
description "priority";
}
list odulist { Editor: Zheyu Fan
key "odu-type"; <mailto:fanzheyu2@huawei.com>
description Editor: Anurag Sharma
"the list of available ODUs per priority level"; <mailto:ansha@google.com>
leaf odu-type { Editor: Xufeng Liu
type identityref{ <mailto:Xufeng_Liu@jabil.com>
base tran-types:tributary-protocol-type;
}
description "the type of ODU";
} Editor: Sergio Belotti
<mailto:sergio.belotti@nokia.com>
leaf number { Editor: Yunbin Xu
type uint16; <mailto:xuyunbin@ritt.cn>
description "the number of odu type supported";
}
}
}
leaf distance { Editor: Lei Wang
type uint32; <mailto:wangleiyj@chinamobile.com>
description "distance in the unit of kilometers";
}
}
grouping otn-tp-attributes { Editor: Oscar Gonzalez de Dios
description "otn-tp-attributes"; <mailto:oscar.gonzalezdedios@telefonica.com>";
leaf client-facing { description
type empty; "This module defines a protocol independent Layer 1/ODU
description topology data model.";
"if present, it means this tp is a client-facing tp.
adding/dropping client signal flow.";
}
leaf tpn { revision 2017-09-14 {
type uint16 { description
range "0..4095"; "Revision 0.4";
}
description
"Tributary Port Number. Applicable in case of mux services.";
reference reference
"RFC7139: GMPLS Signaling Extensions for Control of Evolving "draft-ietf-ccamp-otn-topo-yang-01.txt";
G.709 Optical Transport Networks.";
} }
leaf tsg { /*
type identityref { * Groupings
base tran-types:tributary-slot-granularity; */
} grouping otn-topology-type {
description "Tributary slot granularity."; container otn-topology {
reference presence "indicates a topology type of Optical Transport
"G.709/Y.1331, February 2012: Interfaces for the Optical Network (OTN)-electrical layer.";
Transport Network (OTN)";
}
leaf protocol-type { description "otn topology type";
type identityref { }
base tran-types:tributary-protocol-type; description "otn-topology-type";
}
description "Protocol type for the Termination Point.";
} }
leaf adaptation-type { grouping otn-topology-attributes {
type adaptation-type; leaf name {
description type string;
"This attribute indicates the type of the supported description "the topology name";
adaptation function at the termination point."; }
reference description "name attribute for otn topology";
"G.874.1, January 2002: Optical transport network (OTN):
Protocol-neutral management information model for the
network element view.";
} }
leaf sink-adapt-active { grouping otn-node-attributes {
type boolean; description "otn-node-attributes";
description leaf name {
"This attribute allows for activation or deactivation of type string;
the sink adaptation function. The value of TRUE means active."; description "a name for this node.";
}
reference
"G.874.1, January 2002: Optical transport network (OTN):
Protocol-neutral management information model for the
network element view ";
} }
leaf source-adapt-active { grouping otn-link-attributes {
type boolean; description "link attributes for OTN";
description
"This attribute allows for activation or deactivation of
the sink adaptation function. The value of TRUE
means active.";
reference
"G.874.1, January 2002: Optical transport network (OTN):
Protocol-neutral management information model for
the network element view ";
}
container tributary-slots { list available-odu-info {
description key "priority";
"A list of tributary slots used by the ODU max-elements "8";
Termination Point."; description "List of ODU type and number on this link";
leaf-list values { leaf priority {
type uint8; type uint8 {
description range "0..7";
"Tributary slot value."; }
reference description "priority";
"G.709/Y.1331, February 2012: Interfaces for the }
Optical Transport Network (OTN)"; list odulist {
key "odu-type";
description
"the list of available ODUs per priority level";
leaf odu-type {
type identityref {
base tran-types:tributary-protocol-type;
}
description "the type of ODU";
}
leaf number {
type uint16;
description "the number of odu type supported";
}
leaf tpn-range {
type string {
pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?"
+ "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)";
}
description
"A list of available tributary port number range
between 1 and 9999.
For example 1-20,25,50-1000";
reference
"RFC 7139: GMPLS Signaling Extensions for Control of
Evolving G.709 Optical Transport Networks";
}
}
leaf ts-range {
type string {
pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?"
+ "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)";
}
description
"A list of available tributary slot range
between 1 and 9999.
For example 1-20,25,50-1000";
reference
"RFC 7139: GMPLS Signaling Extensions for Control of
Evolving G.709 Optical Transport Networks";
}
}
leaf tsg {
type identityref {
base tran-types:tributary-slot-granularity;
}
description "Tributary slot granularity";
reference
"RFC 7138: Traffic Engineering Extensions to OSPF for GMPLS
Control of Evolving G.709 Optical Transport Networks";
}
leaf distance {
type uint32;
description "distance in the unit of kilometers";
} }
} }
list supported-payload-types{ grouping otn-tp-attributes {
key "index"; description "tp attributes for OTN";
list supported-payload-types {
description "supported payload types of a TP"; key "index";
description
leaf index { "Supported payload types of a TP. The payload type is defined
type uint16; as the generalized PIDs in GMPLS.";
description "payload type index"; leaf index {
} type uint16;
description "payload type index";
leaf payload-type { }
type string; leaf payload-type {
description "the payload type supported by this client type string;
tp"; description "the payload type supported by this client tp";
reference reference
"http://www.iana.org/assignments/gmpls-sig-parameters "http://www.iana.org/assignments/gmpls-sig-parameters
/gmpls-sig-parameters.xhtml /gmpls-sig-parameters.xhtml";
not: the payload type is defined as the generalized PIDs }
in GMPLS."; }
}
} }
}
/* /*
* Data nodes * Data nodes
*/ */
augment "/nd:networks/nd:network/nd:network-types/tet:te-topology" { augment "/nd:networks/nd:network/nd:network-types/"
uses otn-topology-type; + "tet:te-topology" {
description "augment network types to include otn newtork"; uses otn-topology-type;
} description "augment network types to include otn newtork";
augment "/nd:networks/nd:network" {
when "nd:network-types/tet:te-topology/otn-topology" {
description "Augment only for otn network";
} }
uses otn-topology-attributes;
description "Augment network configuration";
}
augment "/nd:networks/nd:network/nd:node" { augment "/nd:networks/nd:network" {
when "../nd:network-types/tet:te-topology/otn-topology" { when "nd:network-types/tet:te-topology/otntopo:otn-topology" {
description "Augment only for otn network"; description "Augment only for otn network";
}
uses otn-topology-attributes;
description "Augment network configuration";
} }
description "Augment node configuration";
uses otn-node-attributes;
}
augment "/nd:networks/nd:network/lnk:link/tet:te/tet:config" { augment "/nd:networks/nd:network/nd:node" {
when "../../../nd:network-types/tet:te-topology/otn-topology" { when "../nd:network-types/tet:te-topology/otntopo:otn-topology" {
description "Augment only for otn network."; description "Augment only for otn network";
}
description "Augment node configuration";
uses otn-node-attributes;
} }
description "Augment link configuration";
uses otn-link-attributes; augment "/nd:networks/nd:network/lnk:link/tet:te/tet:config" {
} when "../../../nd:network-types/tet:te-topology/"
+ "otntopo:otn-topology" {
description "Augment only for otn network.";
}
description "Augment link configuration";
uses otn-link-attributes;
augment "/nd:networks/nd:network/lnk:link/tet:te/tet:state" {
when "../../../nd:network-types/tet:te-topology/otn-topology" {
description "Augment only for otn network.";
} }
description "Augment link state";
uses otn-link-attributes; augment "/nd:networks/nd:network/lnk:link/tet:te/tet:state" {
} when "../../../nd:network-types/tet:te-topology/"
+ "otntopo:otn-topology" {
description "Augment only for otn network.";
}
description "Augment link state";
uses otn-link-attributes;
}
augment "/nd:networks/nd:network/nd:node/" augment "/nd:networks/nd:network/nd:node/"
+"lnk:termination-point/tet:te/tet:config" { + "lnk:termination-point/tet:te/tet:config" {
when "../../../../nd:network-types/tet:te-topology/otn-topology" { when "../../../../nd:network-types/tet:te-topology/"
description "Augment only for otn network"; + "otntopo:otn-topology" {
description "Augment only for otn network";
}
description "OTN TP attributes config in ODU topology.";
uses otn-tp-attributes;
} }
description "OTN TP attributes config in a ODU topology.";
uses otn-tp-attributes;
}
augment "/nd:networks/nd:network/nd:node/" augment "/nd:networks/nd:network/nd:node/"
+"lnk:termination-point/tet:te/tet:state" { + "lnk:termination-point/tet:te/tet:state" {
when "../../../../nd:network-types/tet:te-topology/otn-topology" { when "../../../../nd:network-types/tet:te-topology/"
description "Augment only for otn network"; + "otntopo:otn-topology" {
description "Augment only for otn network";
}
description "OTN TP attributes state in ODU topology.";
uses otn-tp-attributes;
} }
description "OTN TP attributes state in a ODU topology.";
uses otn-tp-attributes;
}
} }
<CODE ENDS> <CODE ENDS>
4. IANA Considerations 4. IANA Considerations
TBD. TBD.
5. Manageability Considerations 5. Manageability Considerations
TBD. TBD.
6. Security Considerations 6. Security Considerations
The data following the model defined in this draft is exchanged via, The data following the model defined in this document is exchanged
for example, the interface between an orchestrator and a transport via, for example, the interface between an orchestrator and a
network controller. The security concerns mentioned in transport network controller. The security concerns mentioned in
[I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model [I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model
also applies to this draft. also applies to this document.
The YANG module defined in this document can be accessed via the The YANG module defined in this document can be accessed via the
RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF
protocol [RFC6241]. protocol [RFC6241].
There are a number of data nodes defined in the YANG module which are There are a number of data nodes defined in the YANG module which are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., POST) to these in some network environments. Write operations (e.g., POST) to these
data nodes without proper protection can have a negative effect on data nodes without proper protection can have a negative effect on
network operations. network operations.
Editors note: to list specific subtrees and data nodes and their Editors note: to list specific subtrees and data nodes and their
sensitivity/vulnerability. sensitivity/vulnerability.
7. Acknowledgements 7. Acknowledgements
We would like to thank Igor Bryskin, Zhe Liu, Dieter Beller and We would like to thank Igor Bryskin, Zhe Liu, and Daniele Ceccarelli
Daniele Ceccarelli for their comments and discussions. for their comments and discussions.
8. Contributors 8. Contributors
Baoquan Rao Baoquan Rao
Huawei Technologies Huawei Technologies
Email: raobaoquan@huawei.com Email: raobaoquan@huawei.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Huub van Helvoort Huub van Helvoort
Hai Gaoming BV Hai Gaoming BV
the Netherlands the Netherlands
Email: huubatwork@gmail.com Email: huubatwork@gmail.com
Victor Lopez
Telefonica
Email: victor.lopezalvarez@telefonica.com
Yunbo Li
China Mobile
Email: liyunbo@chinamobile.com
Dieter Beller
Nokia
Email: dieter.beller@nokia.com
Yanlei Zheng
China Unicom
Email: zhengyl@dimpt.com
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-ccamp-otn-tunnel-model]
zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Rao, R.,
Belotti, S., Lopezalvarez, V., and Y. Li, "OTN Tunnel YANG
Model", draft-ietf-ccamp-otn-tunnel-model-00 (work in
progress), July 2017.
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for TE Topologies", draft-ietf- O. Dios, "YANG Data Model for TE Topologies", draft-ietf-
teas-yang-te-topo-08 (work in progress), March 2017. teas-yang-te-topo-12 (work in progress), July 2017.
[I-D.sharma-ccamp-otn-tunnel-model]
Zhang, X., xiangkun, x., ansharma@infinera.com, a., and R.
Rao, "OTN Tunnel YANG Model", draft-sharma-ccamp-otn-
tunnel-model-01 (work in progress), March 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
<http://www.rfc-editor.org/info/rfc7138>. <https://www.rfc-editor.org/info/rfc7138>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-ccamp-wson-yang] [I-D.ietf-ccamp-wson-yang]
Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V., Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V.,
King, D., and B. Yoon, "A Yang Data Model for WSON Optical King, D., Yoon, B., and R. Vilata, "A Yang Data Model for
Networks", draft-ietf-ccamp-wson-yang-05 (work in WSON Optical Networks", draft-ietf-ccamp-wson-yang-07
progress), February 2017. (work in progress), July 2017.
[I-D.ietf-netmod-rfc6087bis] [I-D.ietf-netmod-yang-tree-diagrams]
Bierman, A., "Guidelines for Authors and Reviewers of YANG Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
Data Model Documents", draft-ietf-netmod-rfc6087bis-12 ietf-netmod-yang-tree-diagrams-01 (work in progress), June
(work in progress), March 2017. 2017.
[I-D.vergara-ccamp-flexigrid-yang] [I-D.vergara-ccamp-flexigrid-yang]
Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O.,
King, D., Lee, Y., and G. Galimberti, "YANG data model for King, D., Lee, Y., and G. Galimberti, "YANG data model for
Flexi-Grid Optical Networks", draft-vergara-ccamp- Flexi-Grid Optical Networks", draft-vergara-ccamp-
flexigrid-yang-04 (work in progress), March 2017. flexigrid-yang-05 (work in progress), July 2017.
[RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D.
Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Ceccarelli, "Framework for GMPLS and PCE Control of G.709
Optical Transport Networks", RFC 7062, Optical Transport Networks", RFC 7062,
DOI 10.17487/RFC7062, November 2013, DOI 10.17487/RFC7062, November 2013,
<http://www.rfc-editor.org/info/rfc7062>. <https://www.rfc-editor.org/info/rfc7062>.
Authors' Addresses Authors' Addresses
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129 Shenzhen, Guangdong 518129
P.R.China P.R.China
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
skipping to change at page 16, line 4 skipping to change at page 14, line 39
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Zheyu Fan Zheyu Fan
Huawei Technologies Huawei Technologies
F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129 Shenzhen, Guangdong 518129
P.R.China P.R.China
Email: fanzheyu2@huawei.com Email: fanzheyu2@huawei.com
Anurag Sharma Anurag Sharma
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
Email: ansha@google.com Email: ansha@google.com
Xufeng Liu Xufeng Liu
Jabil Jabil
Email: Xufeng_Liu@jabil.com Email: Xufeng_Liu@jabil.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Yunbin Xu
CAICT
Email: xuyunbin@ritt.cn
Lei Wang
China Mobile
Email: wangleiyj@chinamobile.com
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
 End of changes. 77 change blocks. 
410 lines changed or deleted 324 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/