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

[tom petch <[e-mail]>]

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) <[e-mail]>
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://github.com/haomianzheng/IETF-ACTN-YANG-Model/pull/65

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.