Re: [CCAMP] Question about identities with multiple bases

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Tom,

> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: 09 June 2020 10:56
> To: Rob Wilton (rwilton) <[e-mail]>; Italo Busi
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-
> [e-mail]
> Subject: Re: Question about identities with multiple bases
> 
> From: Rob Wilton (rwilton) <[e-mail]>
> Sent: 08 June 2020 18:06
> 
> 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.
> 
> <tp>
> Rob
> I posted separately to Italo that I do not know the requirements and want
> to:-)
> 
> Looking at MEF 63, publicly available, it defines Client Protocol
> (Ethernet, FC, STM, SONET); Coding Function and Optical Interface
> Function.  For each Client Protocol it lists valid combinations of the
> three values, 13 for Ethernet, 10 for FC, 42 for SDH, 49 for SONET so you
> have a large, three dimensional sparse matrix so it might be good to model
> which  values are valid, be that as Boolean, identity or whatever. For
> SONET, the number of Optical Interface Function is limited, for SDH it is
> not.  How do you model a 3-D sparse matrix in YANG?  But I would wait for
> more clarity on the requirements before putting too much thought into that
> question, I might be off the mark..
[RW] 

Ah, that is interesting, and different from what I was imagining.

Without knowing the details, then using different bases to represent the different axis of a sparse 3D array seems like it could be a reasonable way of modelling this.  Once we get more information on the requirements then I can copy the YANG doctors alias in, to see if there are other opinions.

Thanks,
Rob


> 
> Tom Petch
> 
> 
> 
> 
> 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]; draft-ietf-
> [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.
>