Subject: Re: [CCAMP] Microwave Radio Link YANG Data Models

From: Marko Vaupotic <[email-masked]>
Date: Mon, 18 Apr 2016 20:23:29 +0000

Hi Jonas

Great to see a push towards standardizing data model for managing microwave link.

I had a look at your yang file and have some proposals (please also find it in attached document):

* Changed enums to identities (so that they can easily be augmented by vendor specific yang files). (The example shows couple of them but more can be done - like modes of operation)

* Group G.826 parameters so that they are available for "carrier-ethernet" as well as "radio-link-terminal" type of interfaces - as they are needed on both type of interfaces. Although for the final model I strongly suggest that we remove this from the standard yang (and keep it as vendor specific) as most of the required G.826 stuff is missing in this model
* I also propose that the "choice" statement shall be avoided if possible (and rather use the "when"  - in the attached example this was done for coding-modulation). The rationale behind this is that nodes under choice do not appear in the actual data instances(or schema path) - they are just used for validation so that only one set of data appears.

Regards

Marko Vaupotic

----------------------------------------------------------------------------------------------------------------------------------

Hi all,

At IETF 95 on Monday April 4th, 14:50, there will be a presentation about a Microwave Radio Link Yang Model.

The draft was unfortunately not properly uploaded in due time and there is therefore no link to the document in the CCAMP Agenda For IETF 95.

I've instead used the CCAMP mailing list to reach out with the draft to all of you.

The purpose of the draft is to provide a (starting point for a) standardized YANG model for configuration, status and statistics for the radio link interface in a microwave node.

There is a similar activity to standardize a model for microwave in ONF, but the major differences are:

  *   We believe that there are clear benefits to augment the YANG Model for Interface Management [RFC 7223]<http://www.rfc-editor.org/rfc/rfc7223.txt> and thereby use the same structure for radio  link as for most other interfaces in microwave node
  *   Our intention is to cover a selected set of key parameters which we believe are enough for managing the core parts of a radio link and leave out the product/implementation specific parameters. If required, they can always be added as a vendor specific model augmenting the standardized radio link model.

I will share more info in my presentation at IETF 95.

Regards

Jonas Ahlberg

---

From: "Yemin (Amy)" <[email-masked]>
Date: Tue, 19 Apr 2016 16:17:33 +0000

I'm also interested in this draft. Will review and provide comments later.

BR,

Amy

________________________________
发件人: CCAMP [[email-masked]] 代表 Marko Vaupotic [[email-masked]]
发送时间: 2016年4月19日 4:23
收件人: [email-masked]
主题: Re: [CCAMP] Microwave Radio Link YANG Data Models

Hi Jonas

* Group G.826 parameters so that they are available for “carrier-ethernet” as well as “radio-link-terminal” type of interfaces - as they are needed on both type of interfaces. Although for the final model I strongly suggest that we remove this from the standard yang (and keep it as vendor specific) as most of the required G.826 stuff is missing in this model
* I also propose that the “choice” statement shall be avoided if possible (and rather use the “when”  – in the attached example this was done for coding-modulation). The rationale behind this is that nodes under choice do not appear in the actual data instances(or schema path) – they are just used for validation so that only one set of data appears.

Regards

Marko Vaupotic

Hi all,

I’ve instead used the CCAMP mailing list to reach out with the draft to all of you.

Regards

Jonas Ahlberg

---

From: Jonas Ahlberg <[email-masked]>
Date: Thu, 21 Apr 2016 14:50:33 +0000

Hi Marko,

Thank you for your feedback. It's very much appreciated.

* Changed enums to identities (so that they can easily be augmented by vendor specific yang files). (The example shows couple of them but more can be done - like modes of operation)
It's a good proposal and I will include it in the next version of the model, for coding-modulation, spectrum-efficency-class and also for radio-link-terminal:mode.
I've checked the other enums but I think that they can remain as enums, at least for now.

* Group G.826 parameters so that they are available for "carrier-ethernet" as well as "radio-link-terminal" type of interfaces - as they are needed on both type of interfaces. Although for the final model I strongly suggest that we remove this from the standard yang (and keep it as vendor specific) as most of the required G.826 stuff is missing in this model
Making a group of the G.826 parameters make sense. I will include it in the model.

So far we've included actual values only. Historical PM data, including G.826 parameters, are currently not in the model but I've received feedback that we should consider to introduce support for that via Netconf/YANG in addition to XML-files over FTP which we currently use.
Is there anything else than the historical parameters that's missing?

The packet domain is outside the scope of this model, but I think there still is an open question about the use cases for supporting G.826 on the aggregated level of a radio-link-terminal or not. It's obvious that we need to understand the performance on a carrier-termination, but could it be enough to rely on the packet measurements on the aggregated level? Let's continue the discussion.

* I also propose that the "choice" statement shall be avoided if possible (and rather use the "when"  - in the attached example this was done for coding-modulation). The rationale behind this is that nodes under choice do not appear in the actual data instances(or schema path) - they are just used for validation so that only one set of data appears.
We have generated both CLI & WebUI using your proposal. I agree with you that there could be a benefit of storing the selection in the CDB (data instance). It turns out in a good way in CLI and I believe the same could be true for the WebUI, buf it would require some adjustments.
I support your proposal and plan to introduce it in the model.

Once again, thanks for your contribution and let's continue the discussion.

Regards
Jonas Ahlberg

From: CCAMP [mailto:[email-masked]] On Behalf Of Marko Vaupotic
Sent: den 18 april 2016 22:23
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] Microwave Radio Link YANG Data Models

Hi Jonas

Regards

Marko Vaupotic

Hi all,

Regards

Jonas Ahlberg

---

From: Jonas Ahlberg <[email-masked]>
Date: Thu, 21 Apr 2016 14:50:33 +0000

Hi Amy,

Thank you for the support. Your input is important.

Regards
Jonas Ahlberg

From: CCAMP [mailto:[email-masked]] On Behalf Of Yemin (Amy)
Sent: den 19 april 2016 18:18
To: Marko Vaupotic; [email-masked]
Subject: Re: [CCAMP] Microwave Radio Link YANG Data Models

BR,

Amy

________________________________
发件人: CCAMP [[email-masked]] 代表 Marko Vaupotic [[email-masked]]
发送时间: 2016年4月19日 4:23
收件人: [email-masked]<mailto:[email-masked]>
主题: Re: [CCAMP] Microwave Radio Link YANG Data Models

Hi Jonas

Regards

Marko Vaupotic

Hi all,

Regards

Jonas Ahlberg

---

From: Marko Vaupotic <[email-masked]>
Date: Mon, 25 Apr 2016 13:39:43 +0000

Hi Jonas

A couple of more comments:
* Under "power" container, we suggest to also add "FCC-compliant" node (Boolean type) that defines if Federal  Communications Commission (FCC) compliant Automatic Transmit Power Control function shall be used
* We also suggest to change all power related object to type decimal64 (with fraction-digits 1) so that they are all the same (even better would be to define a new typedef for this and use it globally).

Regards

Marko

From: Jonas Ahlberg [mailto:[email-masked]]
Sent: Thursday, April 21, 2016 4:51 PM
To: Marko Vaupotic; [email-masked]
Subject: RE: [CCAMP] Microwave Radio Link YANG Data Models

Hi Marko,

Regards
Jonas Ahlberg

Hi Jonas

Regards

Marko Vaupotic

Hi all,

Regards

Jonas Ahlberg