--- 1/draft-ietf-ccamp-layer1-types-06.txt 2020-09-21 19:13:30.843929920 -0700 +++ 2/draft-ietf-ccamp-layer1-types-07.txt 2020-09-21 19:13:30.887930541 -0700 @@ -1,43 +1,43 @@ CCAMP Working Group H. Zheng Internet-Draft I. Busi Intended status: Standards Track Huawei Technologies -Expires: November 14, 2020 May 13, 2020 +Expires: March 25, 2021 September 21, 2020 A YANG Data Model for Layer 1 Types - draft-ietf-ccamp-layer1-types-06 + draft-ietf-ccamp-layer1-types-07 Abstract This document defines a collection of common data types and groupings - in YANG data modeling language for layer 1 networks. These derived - common types and groupings are intended to be imported by modules - that specifies the OTN networks, including the topology, tunnel, + in the YANG data modeling language for use with layer 1 networks. + These derived common types and groupings are intended to be imported + by modules that specify OTN networks, such as topology, tunnel, client signal adaptation and service. 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 https://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 November 14, 2020. + This Internet-Draft will expire on March 25, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,333 +64,327 @@ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. Examples of OTN Label Ranges . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction - This document introduces a collection of common data types which - would be used in Layer 1 networks. The derived types and groupings - are designed to be the common types applicable for modeling Traffic - Engineering (TE) features for Layer 1 networks. + This document specifies common data types for use in YANG [RFC7950] + data models of Layer 1 networks. The derived types and groupings are + types applicable to modeling Traffic Engineering (TE) for Layer 1 + networks. - Typical Layer 1 network, the Optical Transport Networking, was - specified in [RFC7062]. Corresponding routing and signaling protocol - have been specified in [RFC7138] and [RFC7139]. The types and - groupings defined in this document is consistent to these document, - and will be imported in other Layer 1 data models, including but not - restrictive to, [I-D.ietf-ccamp-otn-topo-yang], + The Optical Transport Networking, a typical Layer 1 network, is + specified in [RFC7062]. The corresponding routing and signaling + protocol are specified in [RFC7138] and [RFC7139]. The types and + groupings defined in this document are consistent to those documents, + and can be imported into other Layer 1 data models, including but not + limited to, [I-D.ietf-ccamp-otn-topo-yang], [I-D.ietf-ccamp-otn-tunnel-model], [I-D.ietf-ccamp-client-signal-yang] and [I-D.ietf-ccamp-l1csm-yang]. - The data model in this draft has only types defined including - groupings, typedef and identities. There is no need to include - configuration and state data according to the new Network Management - Datastore Architecture [RFC8342]. The content in this draft is in - consistent with other specifications, including [MEF63] for Layer 1 - service attributes, [ITU-Tg709] and [ITU-Tgsup43] for OTN data plane - definitions. + The data model in this draft only defines groupings, typedef and + identities. There is no configuration or state data as specified in + the Network Management Datastore Architecture [RFC8342]. The + document is consistent with other specifications, including [MEF63] + for Layer 1 service attributes, [ITU-Tg709] and [ITU-Tgsup43] for OTN + data plane definitions. 2. Terminology and Notations - Refer to [RFC7062] for the key terms used in this document, and the + Refer to [RFC7062] for the key terms used in this document. The terminology for describing YANG data models can be found in [RFC7950]. 3. Prefix in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules. +-------------+---------------------------+----------------------+ | Prefix | YANG module | Reference | +-------------+---------------------------+----------------------+ | l1-types | ietf-layer1-types | This Document | +-------------+---------------------------+----------------------+ 4. Layer 1 Types Overview 4.1. Relationship with other Modules This document defines one YANG module for common Layer 1 types. The - objective is to specifies common Layer 1 TE types that can be - imported by layer 1 specific technology, for example OTN, in its - technology-specific modules such as topology and tunnels. It is - worth noting that the generic traffic-engineering (TE) types module - is specified in [I-D.ietf-teas-yang-te-types] as ietf-te-types, and - both the module ietf-te-types and ietf-layer1-types are needed to be - imported when the OTN is configured. Generic attributes such as te- - bandwidth and te-label, are indicated in ietf-te-types in - [I-D.ietf-teas-yang-te-types], while the OTN-specific attributes, - such as odu-type, are indicated in ietf-layer1-types in this - document. + aim is to specify common Layer 1 TE types (i.e. typedef, identity, + grouping) that can be imported by layer 1 specific technology, for + example OTN, in its technology-specific modules, such as topology and + tunnels. It is worth noting that the generic traffic-engineering + (TE) types module is specified in [RFC8776] as ietf-te-types, and + both YANG modules, ietf-te-types and ietf-layer1-types, will need + importing when the OTN is configured. Generic attributes such as te- + bandwidth and te-label, are specified in ietf-te-types in [RFC8776], + while the OTN-specific attributes, such as odu-type, are specified in + ietf-layer1-types in this document. 4.2. Content in Layer 1 Type Module The module ietf-layer1-types contains the following YANG reusable types and groupings: tributary-slot-granularity: - This is to define the granularity of the server layer ODU Link (HO - ODUk or ODUCn) supporting a client layer ODU LSP (LO ODUj or ODUk, + This specifies the granularity of the server layer ODU Link (HO 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: - This is to specify the type of ODUk LSP, including the types - specified in [RFC7139] and [RFC7963]. + This specifies the type of ODUk LSP, including the types specified in + [RFC7139] and [RFC7963]. client-signal: - This is to specify the client signal types of OTN networks. The - initial input was the G-PID specified in [RFC7139]. Identities about - a few categories of client signal types, including ETH, STM-n, OC - [Telcordia] and Fiber Channel have been specified. + This specifies the client signal types of OTN networks. The initial + input was the G-PID specified in [RFC7139]. Identities for some of + the categories of client signal types, including ETH, STM-n, OC + [Telcordia] and Fiber Channel, have been specified. otn-label-range-type: - The label range type of OTN has two different representations, - tributary slots (TS) and tributary port number (TPN), according to - [RFC7139]. Respective representation is specified under this same - base type. + The label range type of OTN is represented in one of two ways, + tributary slots (TS) and tributary port number (TPN), as specified in + [RFC7139]. Two representations are enumerated in the otn-label- + range-type. otn-link-bandwidth: This grouping defines the link bandwidth information and could be - used in OTN topology model for bandwidth representation. All the - bandwidth related sections in generic module, - [I-D.ietf-teas-yang-te-types], need to be augmented with this - grouping for the usage of Layer 1. + used in OTN topology model for link bandwidth representation. All + the bandwidth related sections in generic module, [RFC8776], need to + be augmented with this grouping for the usage of Layer 1. otn-path-bandwidth: This grouping defines the path bandwidth information and could be - used in OTN topology model for bandwidth representation. All the - bandwidth related sections in generic module, - [I-D.ietf-teas-yang-te-types], need to be augmented with this - grouping for the usage of Layer 1. This grouping is also applicable - to set up the OTN tunnel. + used in OTN topology model for path bandwidth representation. All + the bandwidth related sections in generic module, [RFC8776], need to + be augmented with this grouping for the usage of Layer 1. This + grouping is also applicable when setting up the OTN tunnel. otn-label-range-info and otn-label-step: - These groupings are used for the augmentation of OTN label in a - specific way. + These groupings are used to augment an OTN label with type, + granularity, priority and ODU types. otn-label-start-end and otn-label-hop: - These groupings are used for the augmentation of label for OTN link - and path respectively. + These groupings are used to augment a label for an OTN link and path + respectively. optical-interface-func: The optical interface function is specified in [MEF63]. This grouping describes the functionality which encodes bits for - transmission and the corresponding decode upon reception. + transmission and decodes bits upon reception. service-performance-metric: The service performance metric is a quantitative characterization of - Layer 1 characteristic information delivery quality experienced by - the Layer 1 subscriber. + the quality of the delivery of Layer 1 characteristic information as + experienced by the Layer 1 subscriber. 4.3. OTN Label and Label Range 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 + The same OTN label must 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-range-info grouping. + in [RFC8776], which, for OTN, should be augmented using the otn- + label-range-info 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 in the otn-label-range-info grouping 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-label-start-end - 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), which - is defined in [I-D.ietf-teas-yang-te-types]. + Each entry of the label-restriction list, as defined in [RFC8776], + 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-label-start-end 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), which is defined in [RFC8776]. - 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 former case, both TPN and - TS ranges are reported, while in the latter case, the TPN range is - not reported to indicate 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 + are flexible (e.g., ODU4 Link) while in other cases the TPN + assignment rules are fixed (e.g., ODU1 Link). In the former case, + both TPN and TS ranges are reported, while in the latter case, the + TPN range is not reported which indicates 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 in the otn-label-range-info grouping. - 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 in the otn-label-range-info grouping. + 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, the TPN range is 1-4 for ODU1 but 1-8 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 in the otn-label-range-info grouping. Appendix A provides some examples of how the TPN and TS label ranges described in Table 3 and Table 4 of [RFC7139] can be represented in YANG using the groupings defined in this document. 4.4. ODUflex - ODUflex is a type of ODU which has a flexible bit rate which should - be configured when setting up an ODUflex LSP. + ODUflex is a type of ODU which has a flexible bit rate which is + configured when setting up an ODUflex LSP. [ITU-Tg709], defines six types of ODUflex: ODUflex(CBR), ODUflex(GFP), ODUflex(GFP,n,k), ODUflex(IMP), ODUflex(IMP,s) and ODUflex(FlexE-aware). The main difference between these types of ODUflex is the formula used to calculate the nominal bit rate of the ODUflex, as described - in Table 7-2 of [ITU-Tg709]. A choice has been defined to describe - these cases: + in Table 7-2 of [ITU-Tg709]. A YANG choice has been defined to + describe these cases: +--rw (oduflex-type)? +--:(generic) | +--rw nominal-bit-rate uint64 +--:(cbr) | +--rw client-type identityref +--:(gfp-n-k) | +--rw gfp-n uint8 | +--rw gfp-k? l1-types:gfp-k +--:(flexe-client) | +--rw flexe-client | l1-types:flexe-client-rate +--:(flexe-aware) | +--rw flexe-aware-n uint16 +--:(packet) +--rw opuflex-payload-rate uint64 - The (generic) case has been added to allow defining the ODUflex - nominal bit rate independently from the type of ODUflex. This could - be useful for forward compatibility in the transit domain/nodes where - the setup of ODUflex LSPs does not depend from the ODUflex type. + The 'generic' case has been added to allow the ODUflex nominal bit + rate to be defined independently from the type of ODUflex. This + could be useful for forward compatibility in the transit domain/nodes + where the setup of ODUflex LSPs does not depend on the ODUflex type. - In order to simplify interoperability it is recommended to use - (generic) case only when needed and to use the ODUflex specific type - case whenever possible. + In order to simplify interoperability the 'generic' case should be + used only when it is needed; the ODUflex type-specific case should be + used whenever possible. - The (cbr) case is used for Constant Bit Rate (CBR) client signals. - The client-type indicates which is the CBR client signal carried by - the ODUflex and, implicitly, also the client signal bit rate which is + The 'cbr' case is used for Constant Bit Rate (CBR) client signals. + The client-type indicates which CBR client signal is carried by the + ODUflex and, implicitly, the client signal bit rate which is then used to calculate the ODUflex(CBR) nominal bit rate as described in Table 7-2 of [ITU-Tg709]. - The (gfp-n-k) case is used for GFP-F mapped client signals based on - ODUk.ts and n 1.25G tributary slots. The gfp-k defines the nominal - bit-rate of the ODUk.ts which, together with the value of gfp-n, is + The 'gfp-n-k' case is used for GFP-F mapped client signals based on + ODUk.ts and 'n' 1.25G tributary slots. 'gfp-k' defines the nominal + bit-rate of the ODUk.ts which, together with the value of 'gfp-n', is used to calculated the ODUflex(GFP,n,k) nominal bit rate as described - in Table 7-8 and Table L-7 of [ITU-Tg709] . With few exceptions, + in Table 7-8 and Table L-7 of [ITU-Tg709] . With a few exceptions, shown in Table L-7 of [ITU-Tg709], the nominal bit-rate of the - ODUk.ts could be inferred from the value of n, as shown in Table 7-8 - of [ITU-Tg709] and therefore the gfp-k is optional. + ODUk.ts could be inferred from the value of 'n', as shown in + Table 7-8 of [ITU-Tg709] and therefore the 'gfp-k' is optional. - The (flexe-client) case is used for IMP mapped FlexE Client signals, - The flexe-client represents the type of FlexE Client carried by the - ODUflex which implicitly defines the value of s used to calculate the - ODUflex(s) nominal bit rate as described in Table 7-2 of [ITU-Tg709]. - The '10G' and '40G' enumeration values are used for 10G and 40G FlexE - Clients to implicitly define the values of s=2 and s=8. For the n x - 25G FlexE Clients the value of n is used to defines the value of s=5 - x n. + The 'flexe-client' case is used for Idle Mapping Procedure(IMP) + mapped FlexE client signals, The 'flexe-client' represents the type + of FlexE client carried by the ODUflex which implicitly defines the + value of 's' used to calculate the ODUflex(s) nominal bit rate as + described in Table 7-2 of [ITU-Tg709]. The '10G' and '40G' + enumeration values are used for 10G and 40G FlexE clients to + implicitly define the values of s=2 and s=8. For the 'n x 25G' FlexE + Clients the value of 'n' is used to defines the value of s=5 x n. - The (flexe-aware) case is used for FlexE-aware client signals. The + The 'flexe-aware' case is used for FlexE-aware client signals. The flexe-aware-n represents the value n (n = n1 + n2 + ... + np) which is used to calculate the ODUflex(FlexE-aware) nominal bit rate as described in Table 7-2 of [ITU-Tg709]. - When (packet) case is used for both the GFP-F mapped client signals + The 'packet' case is used for both the GFP-F mapped client signals and the IMP mapped client signals. The opuflex-payload-rate is - either the GFP-F encapsulated packet client nominal bit rate or the - 64b/66b encoded packet client nominal bit rate. The calculation of + either the GFP-F encapsulated-packet client nominal bit rate or the + 64b/66b encoded-packet client nominal bit rate. The calculation of ODUflex(GFP) nominal bit rate is defined in section 12.2.5 of [ITU-Tg709], and the calculation of ODUflex(IMP) nominal bit rate is defined in section 12.2.6 of [ITU-Tg709]. The same formula is used in both cases. Section 5.1 and 5.2 of [RFC7139] defines two rules to compute the number of tributary slots to be allocated to ODUflex(CBR) and - ODUflex(GFP) LSPs when carried over an HO-ODUk link. According to - section 19.6 of [ITU-Tg709], the rules in section 5.2 applies only to - ODUflex(GFP,n,k) while the rules defined in section 5.1 applies to - any other ODUflex type, including but not being limited to - ODUflex(CBR). Section 20.5 of [ITU-Tg709] defines the rules to - compute the number of tributary slots to be allocated to ODUflex LSPs - when carried over an ODUCn link. + ODUflex(GFP) LSPs when carried over a HO-ODUk link. According to + section 19.6 of [ITU-Tg709], the rules in section 5.2 apply only to + ODUflex(GFP,n,k) while the rules defined in section 5.1 apply to any + other ODUflex type, including, but not limited, to ODUflex(CBR). + Section 20.5 of [ITU-Tg709] defines the rules for computing the + number of tributary slots to be allocated to ODUflex LSPs when + carried over an ODUCn link. Following the [ITU-Tg709] definitions, the rules defined for - ODUflex(GFP,n,k) are used only when the (gfp-n-k) case is used. In + ODUflex(GFP,n,k) are used only when the 'gfp-n-k' case is used. In all the other cases, including the (generic) case, the rules defined any other ODUflex type are used. The number of available ODUs, defined for each ODUk type, including ODUflex, together with the number of available time-slots, reported - as part of the OTN label range, provides sufficient information to + as part of the OTN label range, provide sufficient information to infer the OTN link bandwidth availability for ODUflex LSPs. This - information is independent from the ODUflex type. + information is independent of the ODUflex type. 4.4.1. Resizable ODUflex Resizable ODUflex is a special type of ODUflex that supports the procedures defined in [ITU-Tg7044] for hitless resizing of the ODUflex nominal bit rate. Two odu-type identities have been defined for ODUflex: o The ODUflex identity, which is used with any type of non-resizable ODUflex, as defined in Table 7-2 of [ITU-Tg709]. - o The ODUflex-resizable identity, which used only with resizable + o The ODUflex-resizable identity, which is used only with resizable ODUflex(GFP,n,k). These two identities are used to identify whether an ODUflex(GFP,n,k) - LSP shall or not support the [ITU-Tg7044] hitless resizing procedures - as well as whether an OTN link supports only the setup of non- - resizable ODUflex LSPs or also the setup of resizable - ODUflex(GFP,n,k) LSP but with different capabilities (e.g., a lower - number of LSPs). + LSP does or does support the [ITU-Tg7044] hitless resizing + procedures. They also identify whether an OTN link only supports the + setup of non-resizable ODUflex LSPs or also supports the setup of + resizable ODUflex(GFP,n,k) LSP but with different capabilities (e.g., + a lower number of LSPs). 5. YANG Code for Layer1 Types - file "ietf-layer1-types@2020-05-13.yang" + file "ietf-layer1-types@2020-09-21.yang" module ietf-layer1-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-layer1-types"; prefix "l1-types"; organization "IETF CCAMP Working Group"; contact "WG Web: WG List: @@ -387,44 +381,41 @@ module ietf-layer1-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-layer1-types"; prefix "l1-types"; organization "IETF CCAMP Working Group"; contact "WG Web: WG List: - Editor: Haomian Zheng - Editor: Italo Busi "; description - "This module defines Layer 1 types. The model fully conforms - to the Network Management Datastore Architecture (NMDA). - + "This module defines Layer 1 types (typedef, identity, + grouping). The model fully conforms to the Network Management + Datastore Architecture (NMDA). Copyright (c) 2020 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 "2020-05-13" { + revision "2020-09-21" { description "Initial Version"; reference "RFC XXXX: A YANG Data Model for Layer 1 Types"; // RFC Editor: replace XXXX with actual RFC number, update date // information and remove this note } typedef otn-tpn { type uint16 { @@ -604,32 +594,32 @@ identity ODU4 { base odu-type; description "ODU4 protocol (104.79Gb/s)."; reference "RFC7139/ITU-T G.709"; } identity ODUflex { base odu-type; description - "ODUflex protocol (flexibile bit rate, not resizable). - It could be used for any type of ODUflex, including + "ODUflex protocol (flexible bit rate, not resizable). + It can be used for any type of ODUflex, including ODUflex(CBR), ODUflex(GFP), ODUflex(GFP,n,k), ODUflex(IMP,s), ODUflex(IMP) and ODUflex(FlexE-aware)."; reference "RFC7139/ITU-T G.709"; } identity ODUflex-resizable { base odu-type; description - "ODUflex protocol (flexibile bit rate, resizable). - It could be used only for ODUflex(GFP,n,k)."; + "ODUflex protocol (flexible bit rate, resizable). + It can only be used for ODUflex(GFP,n,k)."; reference "RFC7139/ITU-T G.709 and ITU-T G.7044"; } identity client-signal { description "Base identity from which specific client signals for the tunnel are derived"; } identity ETH-1Gb { @@ -1086,44 +1078,45 @@ } case packet { leaf opuflex-payload-rate { type uint64; units "Kbps"; mandatory true; description "Either the GFP-F encapsulated packet client nominal bit rate for an ODUflex(GFP) or the 64b/66b encoded packet client nominal bit rate for an ODUflex(IMP)."; + } } } } grouping otn-label-range-info { description - "label range information for OTN, is dependent on the + "label range information for OTN, dependent on the range-type, must be used together with the following groupings: otn-label-start-end and otn-label-step. "; leaf range-type { type otn-label-range-type; description "The type of range (e.g., TPN or TS) to which the label range applies"; } leaf tsg { type identityref { base tributary-slot-granularity; } description "Tributary slot granularity (TSG) to which the label range applies. - This leaf shall be present when the range-type is TS; - This leaf can be omitted when mapping an ODUk over an OTUk + This leaf must be present when the range-type is TS; + This leaf may be omitted when mapping an ODUk over an OTUk Link. In this case the range-type is tpn, with only one entry (ODUk), and the tpn range has only one value (1)."; reference "G.709/Y.1331, February 2016: Interfaces for the Optical Transport Network (OTN)"; } leaf-list odu-type-list { type identityref { base odu-type; } @@ -1202,33 +1193,33 @@ "G.709/Y.1331, February 2016: Interfaces for the Optical Transport Network (OTN)"; } leaf ts-list { 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 slots ranging - between 1 and 4095. If multiple values or + from 1 to 4095. If multiple values or ranges are given, they all must be disjoint and must be in ascending order. For example 1-20,25,50-1000."; reference "RFC 7139: GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks"; } } grouping otn-label-step { description - "Label step for OTN, is dependent on the range-type, + "Label step for OTN, dependent on the range-type, must be used together with the following groupings: otn-label-range-info and otn-label-start-end. "; choice range-type { description "OTN label range type, either TPN range or TS range"; case trib-port { leaf otn-tpn { when "../../../range-type = 'trib-port'" { description "valid only when range-type represented by trib-port"; @@ -1363,25 +1355,20 @@ Email: victor.lopezalvarez@telefonica.com Yunbo Li China Mobile Email: liyunbo@chinamobile.com 10. References 10.1. Normative References - [I-D.ietf-teas-yang-te-types] - Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, - "Traffic Engineering Common YANG Types", draft-ietf-teas- - yang-te-types-13 (work in progress), November 2019. - [ITU-Tg7044] International Telecommunication Union, "Hitless adjustment of ODUflex(GFP)", ITU-T G.7044, October 2011. [ITU-Tg709] International Telecommunication Union, "Interfaces for the optical transport network", ITU-T G.709, March 2020. [ITU-Tgsup43] International Telecommunication Union, "Transport of IEEE @@ -1431,86 +1418,90 @@ [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . + [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, + "Common YANG Data Types for Traffic Engineering", + RFC 8776, DOI 10.17487/RFC8776, June 2020, + . + [Telcordia] Telcordia, "Synchronous Optical Network Transport Systems: Common Generic Criteria, Issue 5", Telcordia GR-253-CORE, October 2009. 10.2. Informative References [I-D.ietf-ccamp-client-signal-yang] Zheng, H., Guo, A., Busi, I., Snitser, A., Lazzeri, F., Xu, Y., Zhao, Y., Liu, X., and G. Fioccola, "A YANG Data Model for Transport Network Client Signals", draft-ietf- - ccamp-client-signal-yang-02 (work in progress), May 2020. + ccamp-client-signal-yang-03 (work in progress), July 2020. [I-D.ietf-ccamp-l1csm-yang] - Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. - Ceccarelli, "A YANG Data Model for L1 Connectivity Service - Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-11 (work in - progress), March 2020. + Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli, + "A YANG Data Model for L1 Connectivity Service Model + (L1CSM)", draft-ietf-ccamp-l1csm-yang-12 (work in + progress), September 2020. [I-D.ietf-ccamp-otn-topo-yang] Zheng, H., Busi, I., Liu, X., Belotti, S., and O. Dios, "A YANG Data Model for Optical Transport Network Topology", draft-ietf-ccamp-otn-topo-yang-10 (work in progress), March 2020. [I-D.ietf-ccamp-otn-tunnel-model] - Zheng, H., Busi, I., Belotti, S., Lopezalvarez, V., and Y. - Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- - model-10 (work in progress), March 2020. + Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, + "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- + model-11 (work in progress), September 2020. [I-D.ietf-ccamp-transport-nbi-app-statement] Busi, I., King, D., Zheng, H., and Y. Xu, "Transport Northbound Interface Applicability Statement", draft-ietf- - ccamp-transport-nbi-app-statement-10 (work in progress), - November 2019. - - [I-D.ietf-netmod-artwork-folding] - Watsen, K., Auerswald, E., Farrel, A., and Q. WU, - "Handling Long Lines in Inclusions in Internet-Drafts and - RFCs", draft-ietf-netmod-artwork-folding-12 (work in - progress), January 2020. + ccamp-transport-nbi-app-statement-11 (work in progress), + July 2020. [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", RFC 7062, DOI 10.17487/RFC7062, November 2013, . [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and J. Drake, "Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, . + [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, + "Handling Long Lines in Content of Internet-Drafts and + RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, + . + Appendix A. Examples of OTN Label Ranges This appendix provides some examples of how the TPN and TS label ranges described in Table 3 and Table 4 of [RFC7139] can be represented in YANG using the groupings defined in this document. It also considers the OTUk links in addition to HO-ODUk links. The JSON code examples provided in this appendix provides some - embedded comments following the conventions in section 3.2 of [I- - D.ietf-ccamp-transport-nbi-app-statement] and have been folded using - the tool in [I-D.ietf-netmod-artwork-folding]. + embedded comments following the conventions in section 3.2 of + [I-D.ietf-ccamp-transport-nbi-app-statement] and have been folded + using the tool in [RFC8792]. ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== { "examples of label-restrictions for different OTN Links": [ { "// ": "HO-ODU1 or OTU1 Link", "label-restrictions": { "label-restriction": [ {