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

From: "Yemin (Amy)" <[email-masked]>
Date: Thu, 5 May 2016 09:57:57 +0000

Hi Jonas,

I reviewed the draft and have the following comments on the draft:

1.       decimal64 is used for some attributes type, such as min-rltm and max-rltm. Considering the implementation difficulty, it’s suggested to use int instead of decimal.

2.       coding-modulation: as there are some vendor specific coding modulations, it’s suggest to only include the common coding modulation, or change the type from enumeration to string to allow vendor specific extension

3.       id, expected-far-end-id, and far-end-id-check: ID is usually included in the air frame, and used for far end check. Considering that there’s no standard on air interface, it is totally vendor specific, I have some concern to include such attributes.

4.       reference-sec: the values of reference-sec are not aligned with latest EN 302 217

5.       If I understand correctly, the draft is intended to describe a YANG model for common radio link, not for a vendor specific implementation. Therefore it’s suggested to remove some attributes are not supported in our implementation. They are target-input-power-far-end, input-power-alarm-threshold , selected-min-speed, selected-max-speed, mimo-status, actual-si, min-rx-frequency, max-rx-frequency, duplex-type.

6.       Similar to 6, it’s suggested to remove the “ericsson” at the beginning of section 4.

BR,
Amy

________________________________
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!

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

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]<mailto:[email-masked]>
Subject: Re: [CCAMP] Microwave Radio Link YANG Data Models

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]<mailto:[email-masked]>
主题: Re: [CCAMP] Microwave Radio Link YANG Data Models

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: Jonas Ahlberg <[email-masked]>
Date: Tue, 10 May 2016 11:48:17 +0000

Hi all,

A new version of the Microwave Radio Link YANG Data Model has now been submitted with changes based on your feedback.
Amy and Marko are now co-authors. That’s great!

The following changes are made in the -01 revision.

·         rlt: tx-admin-status - has been added to allow for disabling of the transmitter even if the complete radio-link-terminal interface is enabled.

·         ct: channel-separation - type has been changed from enum to decimal 64 to allow for vendor specific values

·         G.826 parameters (ES, SES, UAS, etc) are defined in a grouping and now also supported for both carrier-termination and radio-link-terminal. (See also topic 4 below)

·         Presence statement has been removed from xpic-pairs, mimo-pairs and radio-link-protection-pairs

·         if-feature has been introduced for XPIC and MIMO functionality

·         actual-wait-to-restore – has been added and shows the actual time to wait before switching back to the preferred Tx in Auto & Revertive mode.

·         Identityref included for coding-modulation, spectrum-efficiency-class and radio-link-terminal:mode instead of enums. Allows for vendor specific extensions.

·         Choice statement replaced by when statement for power mode and coding & modulation mode. The associated containers have also been removed.

·         A new type has been defined for all power parameters. Decimal 64, fraction-digits 1. (See also topic 2 below)

·         Removed references to Ericsson in the model.

The topics under discussion are:

1.       There are currently a number of parameters included in the model that perhaps should be considered as vendor specific.

a.       min-rx-frequency, max-rx-frequency, duplex-type

b.      selected-min-speed, selected-max-speed (derived from selected coding-modulation)

c.       mimo-status, actual-si – They are included but are only supported if if-feature mimo is true

d.      target-input-power-far-end, input-power-alarm-threshold

e.      id, expected-far-end-id, and far-end-id-check
This is an additional id used to ensure that the radio link terminal locks into the correct radio link terminal at far end. In some cases, with high frequency reuse and tower installations with many radio links there is otherwise a risk that a radio link terminal locks into the wrong far end having the same frequency & carrier id.
Is it required? Can it be solved in other ways? Vendor specific?

2.       Does power really need to specified with one decimal or could it be enough with integer values. It could perhaps simplify the implementation.

3.       What is a suitable default value for revertive-wait-to-restore, the time to wait before switching back to the preferred Tx in Auto & Revertive mode. Default is currently 0 seconds.

4.       Support for historical performance data (typically interval counters, 15 min and 24 hours)? Or is sftp of XML-files as the case is for many systems today enough?

5.       Support for fault management? Use-cases?

6.       Support for synchronization? Use-cases?

See also comments in green to Amy’s feedback below.

Regards
JonasA

From: Yemin (Amy) [mailto:[email-masked]]
Sent: den 5 maj 2016 11:58
To: Jonas Ahlberg; Marko Vaupotic; [email-masked]
Subject: RE: [CCAMP] Microwave Radio Link YANG Data Models

Hi Jonas,

See open topic 2 above.

2.       coding-modulation: as there are some vendor specific coding modulations, it’s suggest to only include the common coding modulation, or change the type from enumeration to string to allow vendor specific extension
Changed to identityref to allow for vendor specific extensions.

3.       id, expected-far-end-id, and far-end-id-check: ID is usually included in the air frame, and used for far end check. Considering that there’s no standard on air interface, it is totally vendor specific, I have some concern to include such attributes.
See open topic 1.e above.

4.       reference-sec: the values of reference-sec are not aligned with latest EN 302 217
It should be. Can you please clarify.

See open topic 1 above.

Done!

BR,
Amy

From: Jonas Ahlberg [mailto:[email-masked]]
Sent: Thursday, April 21, 2016 10:51 PM
To: Yemin (Amy); Marko Vaupotic; [email-masked]<mailto:[email-masked]>
Subject: RE: [CCAMP] Microwave Radio Link YANG Data Models

Hi Amy,

Regards
Jonas Ahlberg

BR,

Amy

Hi Jonas

Regards

Marko Vaupotic

Hi all,

Regards

Jonas Ahlberg