draft-ietf-ccamp-layer1-types-02.txt   draft-ietf-ccamp-layer1-types-03.txt 
CCAMP Working Group H. Zheng CCAMP Working Group H. Zheng
Internet-Draft I. Busi Internet-Draft I. Busi
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: March 12, 2020 September 9, 2019 Expires: May 4, 2020 November 1, 2019
A YANG Data Model for Layer 1 Types A YANG Data Model for Layer 1 Types
draft-ietf-ccamp-layer1-types-02 draft-ietf-ccamp-layer1-types-03
Abstract Abstract
This document defines a collection of common data types and groupings This document defines a collection of common data types and groupings
in YANG data modeling language for layer 1 networks. These derived in YANG data modeling language for layer 1 networks. These derived
common types and groupings are intended to be imported by modules common types and groupings are intended to be imported by modules
that specifies the OTN networks, including the topology, tunnel, that specifies the OTN networks, including the topology, tunnel,
client signal adaptation and service. client signal adaptation and service.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 https://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 March 12, 2020. This Internet-Draft will expire on May 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 2
3. Prefix in Data Node Names . . . . . . . . . . . . . . . . . . 3 3. Prefix in Data Node Names . . . . . . . . . . . . . . . . . . 3
4. Layer 1 Types Overview . . . . . . . . . . . . . . . . . . . 3 4. Layer 1 Types Overview . . . . . . . . . . . . . . . . . . . 3
4.1. Relationship with other Modules . . . . . . . . . . . . . 3 4.1. Relationship with other Modules . . . . . . . . . . . . . 3
4.2. Content in Layer 1 Type Module . . . . . . . . . . . . . 3 4.2. Content in Layer 1 Type Module . . . . . . . . . . . . . 3
5. YANG Code for Layer1 Types . . . . . . . . . . . . . . . . . 5 4.3. Usage of groupings in Layer1-types . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. YANG Code for Layer1 Types . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document introduces a collection of common data types which This document introduces a collection of common data types which
would be used in Layer 1 networks. The derived types and groupings would be used in Layer 1 networks. The derived types and groupings
are designed to be the common types applicable for modeling Traffic are designed to be the common types applicable for modeling Traffic
Engineering (TE) features for Layer 1 optical networks. Engineering (TE) features for Layer 1 optical networks.
Typical L1 network, the Optical Transport Networking, was specified Typical L1 network, the Optical Transport Networking, was specified
in [RFC7062]. Corresponding routing and signaling protocol have been in [RFC7062]. Corresponding routing and signaling protocol have been
skipping to change at page 3, line 21 skipping to change at page 3, line 21
+-------------+---------------------------+----------------------+ +-------------+---------------------------+----------------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+-------------+---------------------------+----------------------+ +-------------+---------------------------+----------------------+
| layer1-types| ietf-layer1-types | This Document | | layer1-types| ietf-layer1-types | This Document |
+-------------+---------------------------+----------------------+ +-------------+---------------------------+----------------------+
4. Layer 1 Types Overview 4. Layer 1 Types Overview
4.1. Relationship with other Modules 4.1. Relationship with other Modules
This document defines one YANG module for common Layer 1 types: ietf- This document defines one YANG module for common Layer 1 types. The
layer1-types for OTN specific types. The objective is to specifies objective is to specifies common Layer 1 TE types that can be
common Layer 1 TE types that can be imported by layer 1 specific imported by layer 1 specific technology, for example OTN, in its
technology, for example OTN, in its technology-specific modules such technology-specific modules such as topology and tunnels. It is
as topology and tunnels. It is worth noting that the generic worth noting that the generic traffic-engineering (TE) types module
traffic-engineering (TE) types module is specified in is specified in [I-D.ietf-teas-yang-te-types] as ietf-te-types, and
[I-D.ietf-teas-yang-te-types] as ietf-te-types, and both the module both the module ietf-te-types and ietf-layer1-types are needed to be
ietf-te-types and ietf-layer1-types are needed to be imported when imported when the OTN is configured.
the OTN is configured.
4.2. Content in Layer 1 Type Module 4.2. Content in Layer 1 Type Module
The module ietf-layer1-types contains the following YANG reusable The module ietf-layer1-types contains the following YANG reusable
types and groupings: types and groupings:
tributary-slot-granularity: tributary-slot-granularity:
This is to define the granularity for ODUk or ODUCn. Three This is to define the granularity of the server layer ODU Link (HO
granularities, 1.25G/2.5G/5G, have been specified. ODUk or ODUCn) supporting a client layer ODU LSP (LO ODUj or ODUk,
respectively). Three granularities, 1.25G/2.5G/5G, have been
specified.
odu-type: odu-type:
This is to specify the type of ODUk. This is to specify the type of ODUk LSP.
client-signal: client-signal:
This is to specify the client signal types of OTN networks. The This is to specify the client signal types of OTN networks. The
initial input was the G-PID specified in [RFC7139]. Identities about initial input was the G-PID specified in [RFC7139]. Identities about
a few categories of client signal types, including ETH, STM-n, OC and a few categories of client signal types, including ETH, STM-n, OC and
Fiber Channel have been specified. Fiber Channel have been specified.
otn-label-range-type: otn-label-range-type:
skipping to change at page 4, line 33 skipping to change at page 4, line 35
used in OTN topology model for bandwidth representation. All the used in OTN topology model for bandwidth representation. All the
bandwidth related sections in generic topology module, ietf-te- bandwidth related sections in generic topology module, ietf-te-
topology, need to be augmented with this grouping for the usage of topology, need to be augmented with this grouping for the usage of
Layer 1. This grouping is also applicable to set up the OTN tunnel. Layer 1. This grouping is also applicable to set up the OTN tunnel.
otn-label-restriction and otn-label-step: otn-label-restriction and otn-label-step:
These groupings are used for the augmentation of OTN label in a These groupings are used for the augmentation of OTN label in a
specific way. specific way.
otn-link-label and otn-path-label: otn-label-start-end and otn-label-hop:
These groupings are used for the augmentation of label for OTN link These groupings are used for the augmentation of label for OTN link
and path respectively. and path respectively.
optical-interface-func: optical-interface-func:
The optical interface function is specified in [MEF63]. This The optical interface function is specified in [MEF63]. This
grouping describes the functionality which encodes bits for grouping describes the functionality which encodes bits for
transmission and the corresponding decode upon reception. transmission and the corresponding decode upon reception.
service-performance-metric: service-performance-metric:
The service performance metric is a quantitative characterization of The service performance metric is a quantitative characterization of
Layer 1 characteristic information delivery quality experienced by Layer 1 characteristic information delivery quality experienced by
the Layer 1 subscriber. the Layer 1 subscriber.
4.3. Usage of groupings in Layer1-types
As described in [RFC7139], the OTN label usually represents the
Tributary Port Number (TPN) and the related set of Tributary Slots
(TS) assigned to a client layer ODU LSP (LO ODUj or ODUk) on a given
server layer ODU (HO-ODU or ODUCn, respectively) Link (e.g., ODU2 LSP
over ODU3 Link). Some special OTN label values are also defined for
an ODUk LSP being setup over an OTUk Link.
The same OTN label shall be assigned to the same ODUk LSP at the two
ends of an OTN Link.
As described in [RFC7139], TPN can be a number from 1 to 4095 and TS
are numbered from 1 to 4095, although the actual maximum values
depend on the type of server layer ODU. For example, a server layer
ODU4 provides 80 time slots (numbered from 1 to 80) and the TPN
values can be any number from 1 to 80.
The OTN Label Range represents the values for the TPN and TS that are
available for ODUk LSPs to be setup over a given OTN Link.
The OTN Label Range is defined by the label-restriction list, defined
in [I-D.ietf-teas-yang-te-types], which, for OTN, should be augmented
using the otn-label-restriction grouping.
Each entry in the label-restriction list represents either the range
of the available TPN values or the range of the available TS values:
the range-type attribute defines the type of range for each entry of
the list.
Each entry of the label-restriction list, as defined in
[I-D.ietf-teas-yang-te-types], defines a label-start, a label-end, a
label-step and a range-bitmap. The label-start and label-end
definitions for OTN should be augmented using the otn-link-label
grouping. The label-step definition for OTN should be augmented
using the otn-label-step grouping. It is expected that the otn-
label-step will always be equal to its default value (i.e., 1).
As described in [RFC7139], in some cases, the TPN assignment rules is
flexible (e.g., ODU4 Link) while in other cases the TPN assignment
rules are fixed (e.g., ODU1 Link). In the latter case, only the TS
range is reported: not reporting the TPN range means that the TPN
shall be set equal to the TS number assigned to the ODUk LSP.
As described in [RFC7139], in some cases, the TPN assignment rules
depends on the TS Granularity (e.g., ODU2 or ODU3 Links). Different
entries in the label-restriction list will report different TPN
ranges for each TS granularity supported by the link, as indicated by
the tsg attribute.
As described in [RFC7139], in some cases, the TPN ranges are
different for different types of ODUk LSPs. For example, on an ODU2
Link with 1,25G TS granularity, there is TPN range 1-4 for ODU1 and
another TPN range 1-8 in common for ODU0 and ODUflex. Different
entries in the label-restriction list will report different TPN
ranges for different set of ODUk types, as indicated by the odu-type-
list .
5. YANG Code for Layer1 Types 5. YANG Code for Layer1 Types
<CODE BEGINS>file "ietf-layer1-types@2019-09-09.yang" <CODE BEGINS>file "ietf-layer1-types@2019-11-01.yang"
module ietf-layer1-types { module ietf-layer1-types {
namespace "urn:ietf:params:xml:ns:yang:ietf-layer1-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-layer1-types";
prefix "layer1-types"; prefix "layer1-types";
organization organization
"IETF CCAMP Working Group"; "IETF CCAMP Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/ccamp/> "WG Web: <http://tools.ietf.org/wg/ccamp/>
WG List: <mailto:ccamp@ietf.org> WG List: <mailto:ccamp@ietf.org>
Editor: Haomian Zheng Editor: Haomian Zheng
<mailto:zhenghaomian@huawei.com> <mailto:zhenghaomian@huawei.com>
Editor: Italo Busi Editor: Italo Busi
<mailto:Italo.Busi@huawei.com>"; <mailto:Italo.Busi@huawei.com>";
description description
"This module defines Layer 1 types."; "This module defines Layer 1 types. The model fully conforms
to the Network Management Datastore Architecture (NMDA).
revision "2019-09-09" { Copyright (c) 2018 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
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision "2019-11-01" {
description description
"Initial Version"; "Initial Version";
reference reference
"RFC XXXX: A YANG Data Model for Layer 1 Types"; "RFC XXXX: A YANG Data Model for Layer 1 Types";
// RFC Ed.: replace XXXX with actual RFC number, update date // RFC Ed.: replace XXXX with actual RFC number, update date
// information and remove this note // information and remove this note
} }
identity tributary-slot-granularity { identity tributary-slot-granularity {
description description
skipping to change at page 7, line 39 skipping to change at page 9, line 15
signal"; signal";
} }
identity ODUFlex-gfp { identity ODUFlex-gfp {
base odu-type; base odu-type;
description description
"ODU Flex GFP protocol for transporting stream of packets "ODU Flex GFP protocol for transporting stream of packets
using Generic Framing Procedure"; using Generic Framing Procedure";
} }
identity ODUCn {
base odu-type;
description
"ODUCn protocol (beyond 100G)";
}
identity client-signal { identity client-signal {
description description
"Base identity from which specific client signals for the "Base identity from which specific client signals for the
tunnel are derived"; tunnel are derived";
} }
// Editor Notes: may consider add the OTUk as client signal;
identity ETH-1Gb { identity ETH-1Gb {
base client-signal; base client-signal;
description description
"Client signal type of 1GbE"; "Client signal type of 1GbE";
} }
identity ETH-10Gb-LAN { identity ETH-10Gb-LAN {
base client-signal; base client-signal;
description description
"Client signal type of 10GbE LAN"; "Client signal type of 10GbE LAN";
skipping to change at page 11, line 21 skipping to change at page 12, line 38
description description
"Defines a range of OTN tributary slots"; "Defines a range of OTN tributary slots";
} }
identity label-range-trib-port { identity label-range-trib-port {
base otn-label-range-type; base otn-label-range-type;
description description
"Defines a range of OTN tributary ports"; "Defines a range of OTN tributary ports";
} }
// Editor Notes: following grouping only used in otn topology model,
// so suggest to move to ietf-otn-topology and remove from types.
grouping otn-link-bandwidth { grouping otn-link-bandwidth {
description "link bandwidth attributes for OTN"; description "link bandwidth attributes for OTN";
list odulist { list odulist {
key "odu-type"; key "odu-type";
description description
"OTN bandwidth definition"; "OTN bandwidth definition";
leaf odu-type { leaf odu-type {
type identityref { type identityref {
base layer1-types:odu-type; base layer1-types:odu-type;
} }
description "ODU type"; description "ODU type";
} }
leaf number { leaf number {
type uint16; type uint16;
description "Number of ODUs"; description "Number of ODUs";
} }
} }
} }
// Editor Notes: following groupings are used in both otn topology
// and tunnel model, so suggest to be kept in the types.
grouping otn-path-bandwidth { grouping otn-path-bandwidth {
description "path bandwidth attributes for OTN"; description
"path bandwidth attributes for OTN";
leaf odu-type { leaf odu-type {
type identityref { type identityref {
base layer1-types:odu-type; base layer1-types:odu-type;
} }
description "ODU type"; description "ODU type";
} }
} }
// Editor Notes: following groupings are used in both otn topology
// and tunnel model, so suggest to be kept in the types. grouping otn-label-range-info {
grouping otn-label-restriction { description "label range information for OTN";
description "label restriction information for OTN";
leaf range-type { leaf range-type {
type identityref { type identityref {
base layer1-types:otn-label-range-type; base layer1-types:otn-label-range-type;
} }
description "type for range"; description "type for range";
} }
leaf tsg { leaf tsg {
type identityref { type identityref {
base layer1-types:tributary-slot-granularity; base layer1-types:tributary-slot-granularity;
} }
description "Tributary slot granularity."; description
"Tributary slot granularity.";
reference reference
"G.709/Y.1331, February 2016: Interfaces for the "G.709/Y.1331, February 2016: Interfaces for the
Optical Transport Network (OTN)"; Optical Transport Network (OTN)";
} }
leaf-list odu-type-list {
type identityref {
base odu-type;
}
description
"List of ODU types to which the label range applies.
Empty odu-type-list means all the ODU types are applicable
per label range. ";
}
leaf priority { leaf priority {
type uint8; type uint8;
description "priority."; description "priority.";
} }
} }
grouping otn-label-start-end {
// Editor Notes: following groupings are used in both otn topology description
// and tunnel model, so suggest to be kept in the types. "The OTN label-start or label-end used to specify an OTN label range.";
grouping otn-link-label {
description "link label information for OTN, for label-start/end";
choice otn-label-type { choice otn-label-type {
description description
"OTN label range type, either TPN range or TS range"; "OTN label range type, either TPN range or TS range";
case tributary-port { case tributary-port {
leaf tpn { leaf tpn {
type uint16 { type uint16 {
range "1..4095"; range "1..4095";
} }
description description
"Tributary Port Number. Applicable in case of mux services."; "Tributary Port Number. Applicable in case of mux services.";
skipping to change at page 13, line 16 skipping to change at page 14, line 37
description description
"Tributary Slot Number. Applicable in case of mux services."; "Tributary Slot Number. Applicable in case of mux services.";
reference reference
"RFC7139: GMPLS Signaling Extensions for Control of Evolving "RFC7139: GMPLS Signaling Extensions for Control of Evolving
G.709 Optical Transport Networks."; G.709 Optical Transport Networks.";
} }
} }
} }
} }
// Editor Notes: following groupings are used in both otn topology grouping otn-label-hop {
// and tunnel model, so suggest to be kept in the types.
grouping otn-path-label {
description "label information for OTN, for label-hop"; description "label information for OTN, for label-hop";
leaf tpn { leaf tpn {
type uint16 { type uint16 {
range "1..4095"; range "1..4095";
} }
description description
"Tributary Port Number. Applicable in case of mux services."; "Tributary Port Number. Applicable in case of mux services.";
reference reference
"RFC7139: GMPLS Signaling Extensions for Control of Evolving "RFC7139: GMPLS Signaling Extensions for Control of Evolving
G.709 Optical Transport Networks."; G.709 Optical Transport Networks.";
skipping to change at page 13, line 46 skipping to change at page 15, line 18
"G.709/Y.1331, February 2016: Interfaces for the "G.709/Y.1331, February 2016: Interfaces for the
Optical Transport Network (OTN)"; Optical Transport Network (OTN)";
} }
leaf ts-list { leaf ts-list {
type string { type string {
pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" 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})?)*)"; + "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)";
} }
description description
"A list of available tributary slots ranging "A list of available tributary slots ranging
between 1 and 9999. between 1 and 4095.
For example 1-20,25,50-1000"; For example 1-20,25,50-1000";
reference "RFC 7139: GMPLS Signaling Extensions for Control reference "RFC 7139: GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks"; of Evolving G.709 Optical Transport Networks";
} }
} }
// Editor Notes: following grouping only used in otn topology model,
// so suggest to move to ietf-otn-topology and remove from types.
grouping otn-label-step { grouping otn-label-step {
description "Label step for OTN"; description "Label step for OTN";
choice otn-label-type { choice otn-label-type {
description description
"OTN label range type, either TPN range or TS range"; "OTN label range type, either TPN range or TS range";
case tributary-port { case tributary-port {
leaf tpn-step { leaf tpn {
type uint16 { type uint16 {
range "1..80"; range "1..4095";
} }
default 1; default 1;
description description
"Label step which represents possible increments for "Label step which represents possible increments for
Tributary Port Number."; Tributary Port Number.";
reference reference
"RFC7139: GMPLS Signaling Extensions for Control of Evolving "RFC7139: GMPLS Signaling Extensions for Control of Evolving
G.709 Optical Transport Networks."; G.709 Optical Transport Networks.";
} }
} }
case tributary-slot { case tributary-slot {
leaf ts { leaf ts {
type uint16 { type uint16 {
range "1..80"; range "1..4095";
} }
default 1; default 1;
description description
"Label step which represents possible increments for "Label step which represents possible increments for
Tributary Slot Number."; Tributary Slot Number.";
reference reference
"RFC7139: GMPLS Signaling Extensions for Control of Evolving "RFC7139: GMPLS Signaling Extensions for Control of Evolving
G.709 Optical Transport Networks."; G.709 Optical Transport Networks.";
} }
} }
} }
} }
// Editor Notes: to be reviewed for the following coding functions.
identity coding-func { identity coding-func {
description description
"base identity from which coding func is derived."; "base identity from which coding func is derived.";
} }
identity ETH-1000X-PCS-36 { identity ETH-1000X-PCS-36 {
base "coding-func"; base "coding-func";
description description
"PCS clause 36 coding function that corresponds to "PCS clause 36 coding function that corresponds to
1000BASE-X"; 1000BASE-X";
skipping to change at page 15, line 41 skipping to change at page 17, line 9
} }
identity ETH-100GR-PCS-82 { identity ETH-100GR-PCS-82 {
base "coding-func"; base "coding-func";
description description
"PCS clause 82 coding function that corresponds to "PCS clause 82 coding function that corresponds to
100GBASE-R"; 100GBASE-R";
reference "MEF63 & IEEE802.3"; reference "MEF63 & IEEE802.3";
} }
/* coding func needs to expand for Fiber Channel, SONET, SDH */
identity optical-interface-func { identity optical-interface-func {
description description
"base identity from which optical-interface-function is "base identity from which optical-interface-function is
derived."; derived.";
} }
identity SX-PMD-clause-38 { identity SX-PMD-clause-38 {
base "optical-interface-func"; base "optical-interface-func";
description description
"SX-PMD-clause-38 Optical Interface function for "SX-PMD-clause-38 Optical Interface function for
skipping to change at page 18, line 10 skipping to change at page 19, line 24
} }
identity ER4-PMD-clause-88 { identity ER4-PMD-clause-88 {
base "optical-interface-func"; base "optical-interface-func";
description description
"ER4-PMD-clause-88 Optical Interface function for "ER4-PMD-clause-88 Optical Interface function for
100GBASE-R PCS-82"; 100GBASE-R PCS-82";
reference "MEF63 & IEEE802.3"; reference "MEF63 & IEEE802.3";
} }
// Editor Notes: To add the performance monitor parameters per L1CSM;
identity service-performance-metric { identity service-performance-metric {
description "list of service-specific performance metric"; description
"list of service-specific performance metric";
} }
identity One-way-Delay { identity One-way-Delay {
base "service-performance-metric"; base "service-performance-metric";
description "one-way-delay"; description "one-way-delay";
} }
identity One-way-Errored-Second { identity One-way-Errored-Second {
base "service-performance-metric"; base "service-performance-metric";
description "one-way-errored-second"; description "one-way-errored-second";
skipping to change at page 18, line 39 skipping to change at page 20, line 4
identity One-way-Unavailable-Second { identity One-way-Unavailable-Second {
base "service-performance-metric"; base "service-performance-metric";
description "one-way-unavailable-second"; description "one-way-unavailable-second";
} }
identity One-way-Availability { identity One-way-Availability {
base "service-performance-metric"; base "service-performance-metric";
description "one-way-availability"; description "one-way-availability";
} }
identity network-performance-metric {
//Editor Notes: it's useful to separate network specific performance description "list of network-specific performance metric";
//monitoring with service-specific
identity network-performance-metric {
description "list of network-specific performance metric";
}
identity pm-placeholder {
base "network-performance-metric";
description "A placeholder for potential performance monitoring
on L1 networks";
} }
} }
<CODE ENDS> <CODE ENDS>
6. Security Considerations 6. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
skipping to change at page 21, line 27 skipping to change at page 22, line 31
China Mobile China Mobile
Email: liyunbo@chinamobile.com Email: liyunbo@chinamobile.com
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-teas-yang-te-types] [I-D.ietf-teas-yang-te-types]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Traffic Engineering Common YANG Types", draft-ietf-teas- "Traffic Engineering Common YANG Types", draft-ietf-teas-
yang-te-types-10 (work in progress), July 2019. yang-te-types-11 (work in progress), October 2019.
[MEF63] Metro Ethernet Forum, "Subscriber Layer1 Service [MEF63] Metro Ethernet Forum, "Subscriber Layer1 Service
Attributes Technical Specification", MEF 63, August 2018. Attributes Technical Specification", MEF 63, August 2018.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[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
skipping to change at page 22, line 30 skipping to change at page 23, line 36
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ccamp-l1csm-yang] [I-D.ietf-ccamp-l1csm-yang]
Fioccola, G., Lee, K., Lee, Y., Dhody, D., and D. Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D.
Ceccarelli, "A YANG Data Model for L1 Connectivity Service Ceccarelli, "A YANG Data Model for L1 Connectivity Service
Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-09 (work in Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in
progress), March 2019. progress), September 2019.
[I-D.ietf-ccamp-otn-topo-yang] [I-D.ietf-ccamp-otn-topo-yang]
Zheng, H., Guo, A., Busi, I., Sharma, A., Liu, X., Zheng, H., Guo, A., Busi, I., Sharma, A., Liu, X.,
Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data
Model for Optical Transport Network Topology", draft-ietf- Model for Optical Transport Network Topology", draft-ietf-
ccamp-otn-topo-yang-07 (work in progress), July 2019. ccamp-otn-topo-yang-08 (work in progress), September 2019.
[I-D.ietf-ccamp-otn-tunnel-model] [I-D.ietf-ccamp-otn-tunnel-model]
Zheng, H., Guo, A., Busi, I., Sharma, A., Rao, R., Zheng, H., Busi, I., Belotti, S., Lopezalvarez, V., and Y.
Belotti, S., Lopezalvarez, V., Li, Y., and Y. Xu, "OTN Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel-
Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel-model-07 model-08 (work in progress), October 2019.
(work in progress), July 2019.
[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,
<https://www.rfc-editor.org/info/rfc7062>. <https://www.rfc-editor.org/info/rfc7062>.
[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
 End of changes. 41 change blocks. 
87 lines changed or deleted 141 lines changed or added

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