Re: [CCAMP] Question about identities with multiple bases

[Italo Busi <[e-mail]>]

Rob, Tom,

Thanks for your feedbacks

I was actually trying to fix two issues at the same time so it is better to split the two issues.

Let me try to clarify the issues and how it is proposed to address them.

Issue #1

One issue is the need to define two partially overlapping set of identities. I think Rob got it right this issue.

For example:
- STM-1 can be both valid as client-signal as well as a coding-function;
- ETH-1Gb is only valid a client-signal
- ETH-1000X is only valid as coding-function

This would be the proposed solution:

  identity STM-1 {
    base client-signal;
    base "coding-func";
  }

  identity ETH-1Gb {
    base client-signal;
  }

  identity ETH-1000X {
    base "coding-func";
  }

  leaf client-signal {
    type identityref {
      base "l1-types:client-signal";
    }
  }

  leaf coding {
    type identityref {
      base "l1-types:coding-func";
    }
  }

My understanding is that:
-       For client-signal, STM-1 and ETH-1Gb values will be accepted while ETH-1000X will not be accepted
-       For coding, STM-1 and ETH-1000X values will be accepted while ETH-1Gb will not be accepted

Issue #2

Another issue is the need to define valid value combinations in a multidimensional sparse matrix. I think Tom got it right this issue.

For example in MEF 63, only a subset of all the possible combinations of protocol, coding and optical-interface are allowed:
- STM-1 is a valid coding-function only if the protocol is SDH;
- ETH-1000X is a valid coding-function only if the protocol is Ethernet.

This would be the proposed solution:

  identity Ethernet {
    base "protocol";
  }

  identity ETH-1000X {
    base "coding-func";
    base "Ethernet";
  }

  leaf protocol {
    type identityref {
      base "l1-types:protocol";
    }
  }

  leaf coding {
    type identityref {
      base "l1-types:coding-func";
    }
    must 'derived-from(../coding, ../protocol)';
  }

A feedback I have got offline is that this solution might not work since the second argument of the “derived-from” function should be a string and not a reference to another leaf ☹

Nevertheless, this code has passed pyang compilation checks …

It would be great if we can find better solutions to these issues.

Thanks, Italo

> -----Original Message-----
> From: Rob Wilton (rwilton) [mailto:[e-mail]]
> Sent: martedì 9 giugno 2020 12:31
> To: tom petch <[e-mail]>; Italo Busi <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-ccamp-
> [e-mail]
> Subject: RE: Question about identities with multiple bases
>
> Hi Tom,
>
> > -----Original Message-----
> > From: tom petch <[e-mail]<mailto:[e-mail]>>
> > Sent: 09 June 2020 10:56
> > To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; Italo Busi
> > <[e-mail]<mailto:[e-mail]>>
> > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; draft-ietf-
> > [e-mail]<mailto:[e-mail]>
> > Subject: Re: Question about identities with multiple bases
> >
> > From: Rob Wilton (rwilton) <[e-mail]<mailto:[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]<mailto:[e-mail]>>
> > Sent: 05 June 2020 12:11
> > To: Italo Busi <[e-mail]<mailto:[e-mail]>>; Rob Wilton (rwilton)
> > <[e-mail]<mailto:[e-mail]>>
> > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; draft-ietf-
> > [e-mail]<mailto:[e-mail]>
> > Subject: Re: Question about identities with multiple bases
> >
> > From: CCAMP <[e-mail]<mailto:[e-mail]>> on behalf of Italo Busi
> > <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]<mailto:[e-mail]>> or
> through
> > the following channel: www.huawei.com/en/personal-data-<http://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<mailto:[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.
> >