Re: [CCAMP] Quirks part two Re: Question about identities with multiple bases

[tom petch <[e-mail]>]

From: Daniele Ceccarelli <[e-mail]>
Sent: 09 June 2020 12:44

Hi Tom,

Yes please. We (chairs and most of the authors) are not native English speakers, if you find ways to improve readability and put the text in a better English that would help a lot and be highly appreciated.

<tp>

Since you ask-)
I have taken -06 and removed the non-text and the text that looks ok to me leaving either a modified sentence or paragraph.  Use it as you wish; I claim no IPR in it!

[ contain explanations or notes or suggestions]
** something has changed on this line, may be just removing one or two letters or a comma

[unaltered text has been excised. document order has been retained]
=====================================================
Abstract

   This document defines a collection of common data types and groupings
   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.

[section 1 already submitted]


2.  Terminology and Notations

**   Refer to [RFC7062] for the key terms used in this document.  The
   terminology for describing YANG data models can be found in
   [RFC7950].

4.  Layer 1 Types Overview

4.1.  Relationship with other Modules

   This document defines one YANG module for common Layer 1 types.  The
   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 [I-D.ietf-teas-yang-te-types] as ietf-te-types, and
   both YANG modules, ietf-te-types and ietf-layer1-types, will need importing  
   when OTN is configured.  Generic attributes such as te-
   bandwidth and te-label, are specified in ietf-te-types in
   [I-D.ietf-teas-yang-te-types], 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 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 specifies the type of ODUk LSP, including the types
   specified in [RFC7139] and [RFC7963].

   client-signal:

   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 is represented in one of two ways, tributary slots (TS) and tributary port number (TPN), as specified in
   [RFC7139].  This is specified by an enumeration of this typedef
[this is a guess - I did not understand the original sentence here]

   otn-link-bandwidth:

   This grouping defines the link bandwidth information and could be
   used in OTN topology model for link 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 use with Layer 1.

   otn-path-bandwidth:

   This grouping defines the path bandwidth information and could be
   used in OTN topology model for path 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 use with 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 to augment an OTN label with type, granularity, priority and ODU types.

   otn-label-start-end and otn-label-hop:

   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 decodes bits upon reception.


   service-performance-metric:

   The service performance metric is a quantitative characterization of
   of 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 set up over an OTUk Link.

**   The same OTN label must be assigned to the same ODUk LSP at the two
   ends of an OTN Link.



 
   Each entry in the label-restriction list represents either a range
   of the available TPN values or a 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 in the list.

   Each entry in 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 both be augmented using the otn-label-start-end
   grouping.  The label-step definition for OTN should be augmented
   with 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 defined in [I-D.ietf-teas-yang-te-types].
[well it is default value one for case generic! here it is type otn-tpn which has no default]

**   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 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.

   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.
[should or must? not sure]
   [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 YANG choice has been defined to describe
   these cases:

[the use of (  ) is a bit odd; normally ( ) is something that can be omitted without loss of meaning so unless they appear as such in e.g. G.709 then I think that single quotes are more suitable]

   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 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 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.  '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 a few exceptions, as
   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' value is optional.

   The 'flexe-client' case is used for IMP mapped FlexE Client signals,
[expand IMP somewhere - s.2?]

   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


   [Page 7]


   25G' FlexE Clients, the value of 'n' is used to define the value of s=5
   x n.

   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].


**  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
   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.

**   Sections 5.1 and 5.2 of [RFC7139] define 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 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
   all the other cases, including the 'generic' case, the rules defined
   for the other ODUflex types 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, provide sufficient information to
   infer the OTN link bandwidth availability for ODUflex LSPs.  This
**   information is independent of the ODUflex type.

4.4.1.  Resizable ODUflex

   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 is used only with resizable
      ODUflex(GFP,n,k).

   These two identities are used to identify whether an ODUflex(GFP,n,k)
**   LSP does or does not 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 a resizable
   ODUflex(GFP,n,k) LSP but with different capabilities (e.g., a lower
   number of LSPs).

5.  YANG Code for Layer1 Types

     description
       "This module defines Layer 1 types (typedef, identity, grouping). The model fully conforms
        to the Network Management Datastore Architecture (NMDA).


**      "ODUflex protocol (flexible bit rate, not resizable).
**          It can be used for any type of ODUflex, including


     identity ODUflex-resizable {
       base odu-type;
       description
**         "ODUflex protocol (flexible bit rate, resizable).
**          It can only  be used for ODUflex(GFP,n,k).";

            
                 grouping otn-label-range-info {
       description
**         "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. ";
[or else 
 "Label range information for OTN which is dependent on the range-type,
]

       leaf tsg {type identityref { base tributary-slot-granularity;
         }
         description
           "Tributary slot granularity (TSG) to which the label range
            applies.
**            This leaf must be present when the range-type is TS;
[you use must just above, shall is not quite the same in English]

**         This leaf may omitted when mapping an ODUk over an OTUk
            Link. 
          
       leaf ts-list {
           description
             "A list of available tributary slots ranging
              from 1 to 4095. 
['between' sort of suggests that valid values are 2 to 4194 not 1 to 4095]

     grouping otn-label-step {
       description
        "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. ";
       
[or else 
    "Label step for OTN which is dependent on the range-type,
]

================================================

HTH

Tom Petch

Thanks,
Daniele

-----Original Message-----
From: CCAMP <[e-mail]> On Behalf Of tom petch
Sent: den 9 juni 2020 12:25
To: Rob Wilton (rwilton) <[e-mail]>; Italo Busi <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: [CCAMP] Quirks part one Re: Question about identities with multiple bases

An example of what I see as quirks in the English

OLD
   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.

   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],
   [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.


NEW
   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.

 The Optical Transport Networking, a typical Layer 1 network, is
   specified in [RFC7062].  The corresponding routing and signaling protocols
   are specified in [RFC7138] and [RFC7139].  The types and
   groupings defined in this document are consistent with 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 only defines groupings, typedefs 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, namely  [MEF63] for Layer 1
   service attributes, [ITU-Tg709] and [ITU-Tgsup43] for OTN data plane
   definitions.


Is this useful?  Shall I do some more?

Tom Petch
________________________________________
From: Rob Wilton (rwilton) <[e-mail]>
Sent: 08 June 2020 18:06
To: tom petch; Italo Busi
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Question about identities with multiple bases

Hi,

Apologies for the delayed reply.

Tom, I would be interested if you can provide your feedback on the quirks in the English.  It would be useful to get them fixed/tweaked now rather than later in the process.

Some thoughts of the main question regarding multiple base identities:

I think that you might be using base identities in two different ways here.  One of those seems reasonable, the other, I'm not so sure about.

The first way, that I think is reasonable, is if you want to tag a subset of identities that all derive from a common base as having the same property.
E.g. if you have lots of identities that derive from "client-signal", then it might be reasonable to group a subset of them as also deriving from the "Ethernet" base identity.  In this scenario, the set of identities that derive from "Ethernet" would be a subset of identities that derive from "client-signal".  I have no issues with this approach and have considering using this formulation myself.

The second way, that I'm not convinced by, is where I think that you are trying to share the same identity in different sets (e.g. client-signal vs coding-func).  In this case, I think that it would be much better to define separate identities, either by prefixing the name of the set in the identity name (to make the names unique), or perhaps more cleanly by putting them in separate YANG source files, where the module name/prefix can be used to use the same textual identity name different scoped names.

Further discussion, perhaps involving the YANG doctors' alias might be helpful.

Thanks,
Rob



-----Original Message-----
From: tom petch <[e-mail]>
Sent: 05 June 2020 12:11
To: Italo Busi <[e-mail]>; Rob Wilton (rwilton) <rwilton@cisco..com>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Question about identities with multiple bases

From: CCAMP <[e-mail]> on behalf of Italo Busi <[e-mail]>
Sent: 19 May 2020 17:49

Hi Rob,

We have discussed an open issue with the ietf-l1csm which is impacting the ietf-layer1-types YANG model, for which we are addressing CCAMP WG LC comments

See slides 3 and 4 of the attached presentation made during the CCAMP WG virtual meeting last week

Since we have not much experience with identities having multiple bases, we would like to get a feedbacks from you about whether the proposed solution would work <tp> Italo

I have not seen a response to your question.  I had a look and it seems ok but like you I do not see much of this construct in IETF modules.

So while it may be ok, that does make me wonder; is this approach too complicated?  If you and I are uncertain about it, then what about future users - will they be comfortable with it?  I had to look up which Boolean operator applied with multiple bases!

Separately, having persuaded my obstructionist ESP to let me send an e-mail, I see a number of quirks in the English of layer1-types.  Are you interested in hearing about them? (assuming that my ESP lets me:-)

Tom Petch



You can check initial changes to ETH-1GbE, FICON-4G and STM-1 identities in github:

https://protect2.fireeye.com/v1/url?k=0414c5cd-5ab40788-04148556-86b568293eb5-ec07e8744681da2f&q=1&e=93d52b5e-6eee-4d6a-846a-0db90eafdb3b&u=https%3A%2F%2Fgithub.com%2Fhaomianzheng%2FIETF-ACTN-YANG-Model%2Fpull%2F65

Let me report here the key ones:

  identity ETH-1Gb {
    base client-signal;
    description
      "Client signal type of 1GbE";
    reference "RFC7139/ITU-T G.709";
  }

  identity FICON-4G {
    base client-signal;
    description
      "Client signal type of Fibre Connection 4G";
    reference "RFC4328/RFC7139";
  }

  identity ETH-1000X {
    base "coding-func";
    base Ethernet;
    description
      "1000BASE-X PCS clause 36 coding function.";
    reference "MEF63: Subscriber Layer 1 Service Attributes";
  }

  identity STM-1 {
    base client-signal;
    base "coding-func";
    base SDH;
    description
      "STM-1 client signal;
       STM-1 G.707 (N=1) coding function.";
    reference
      "RFC7139/ITU-T G.709
       MEF63: Subscriber Layer 1 Service Attributes";
  }

              leaf client-signal {
                type identityref {
                  base "l1-types:client-signal";
                }
                mandatory true;
                description
                  "The client signal being used at the UNI";
              }

Then ETH-1GbE, FICON-4G and STM-1 would be valid configuration for the client-signa leaf, while ETH-1000X will not be valid

    leaf coding {
      type identityref {
        base "l1-types:coding-func";
      }
      must 'derived-from(../coding, ../protocol)';
      mandatory true;
      description "The coding function being used at the UNI.";
    }

Then:
- ETH-1000X would be valid configuration of the coding leaf, if Ethernet is configured, otherwise it is invalid;
- STM-1 would be valid configuration of the coding leaf, if SDH is configure as protocol, otherwise it is invalid;
- ETH-1GbE and FICON-4G would never be valid configuration of the coding leaf

Before applying these changes to a lot of identities, it would be good to check that our understanding is correct

What do you think?

Thanks in advance

Italo

Italo Busi
Principal Optical Transport Network Research Engineer

[cid:image001.jpg@01D5AC11.9575BB40]
____________________________________________________________________

Huawei Technologies Italia S.r.l.
Address: Centro Direzionale Milano 2, Palazzo Verrocchio, 20090 Segrate (MI)
Tel: [phone] - Mobile: [e-mail]<mailto:[e-mail]>

__________________________________________________________________________________
Huawei Technologies Italia S.r.l. is a company registered in Italy at the Company Registration Office of Milan, with registered number 04501190963 and equity capital ?3,000,000 fully paid up, whose registered office is in Milan, Via Lorenteggio 240, Tower A, 20147 Milan, Italy. Huawei Technologies Italia S.r.l. is 100% owned by Huawei Technologies Cooperatief U.A.
CONAI Reg. No. cc 12639454 - A.E.E. Registry No. IT10010000006521 - Batteries and Accumulators Registry No. IT12050P00002839.
________________________________________________________________________________________________________________________
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! Thank you.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PRIVACY NOTICE: Pursuant to Art. 13 of the General Data Protection Regulation 2016/679 (GDPR), Huawei Technologies Italia S.r.l. informs you that the personal data contained in this email will be collected and treated for the acquisition of information preliminary to the conclusion of contracts, for the definition of the contractual relationship, as well as for the fulfillment of legal requirements related to civil, tax and accounting law or any other legal obligation to which Huawei may be subject. Personal data will not be subject to disclosure and spread unless otherwise required by law. Huawei will take appropriate security measures to protect personal data against loss, misuse disclosure or destruction of the information. Personal Data held may be transferred to countries outside the European Union, however Huawei Italia has put in place appropriate safeguards for the transfer of personal data to third countries by adopting the standard data protection clauses of the EU Commission. Personal Data are kept for a period necessary for the fulfillment of contract obligations unless otherwise required by law. You can exercise your rights under Art. 15 and following of the GDPR (i.e. right of access, rectification, erasure, restriction, portability, object) by contacting Huawei at this email address: [e-mail]<mailto:[e-mail]> or through the following channel: www.huawei.com/en/personal-data-request<http://www.huawei.com/en/personal-data-request>. You have also the right to lodge a complaint with the competent supervisory authorities. If you need any further information or have any queries on how Huawei process your personal data, please send an email to our Data Protection Officer at [e-mail]<mailto:[e-mail]>.The Data Controller is Huawei Technologies Italia S.r.l. with registered office in Milan, Via Lorenteggio 240 Tower A, 20147.



_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp