samans / draft-ybam-rfc8561bis Goto Github PK

Email from Daniela,

I have a question (raised by our Sw development team) as a my understand confirmation:

The question from our Sw development team)
• (If we use a shifter, I assume the configuration value is should be a signed value relative to the TX value (i.e. TX > RX implies negative shifter). Is this correct (the YANG shifter value is signed)? Interestingly, the actual-duplex-distance value is unsigned.

My reply:
the duplex-distance to configure (as an alternative of rx-frequency configuration) is int32 (so signed) to allow to have negative shifter for Rx < TX , but for actual-duplex-instance we report only the positive value.

Action: validate the understanding of interpretation of duplex-distance

The configuration of the minimum value of Tx Power (which is not to be undercut) on ATPC mode is missing on ietf-microwave-radio-link model.

On ONF model this parameter is foreseen (air-interface-configuration/atpc-tx-power-min).

In the excel spreadsheet line 99 is documented that the ONF air interface supports the configuration of a loopback.

  |  +--rw air-interface:loop-back-kind-on?                  loop-back-type

Proposed solution:

Add in the augmentation to the ietf-interface the following attribute

  |  +--rw mrl:loopback?                  loopback with if-feature loopback

Attribute description:
"Maintenance Feature. The loopback function according to the chosen value. The default value is 'NONE'.";

Feature definition:

feature loopback {
  description 
    "Supports a maintenance feature maintenance feature to loop back local or remote signals";
}

The 'loopback' type should be defined as:

typedef loopback {
  type enumeration {

    enum NONE {
      description
        "The loopback function is disabled.";
    }

    enum REMOTE {
      description
        "Returning the signal of the remote site back to the remote site.";
    }

    enum LOCAL {
      description
        "Returning the signal of the local site back to the local site.";
    }

  }
  description 
    "Values describing the loopback function.";
}

After discussion with Netmod WG experts it is confirmed that the changes proposed in PR #10 will not break any existing client implementation based on RFC8561 but they are not backward compatible, according to the rules defined in section 11 of RFC7950, and that there are no alternatives to meet the rules defined in section 11 of RFC7950

Need to clarify this in the I-D text

based on counters implemented within the equipment

• See document about error performance evolution from ETSI ISG mWT [https://www.etsi.org/committee/1426-mwt] (WI 19)
• To be discussed more in a later session

Link to excel sheet with a comparison between ONF & IETF related fragments for the microwave domain.
The focus for this issue is the content in air-interface.
Next step is to walk through the sheets in order to understand the gaps identified.

https://oranalliance.atlassian.net/wiki/pages/viewpageattachments.action?pageId=2796486759&preview=%2F2796486759%2F2830729250%2Fietf-vs-onf-microwave%26ethernetwired-v03.xlsx&search_id=750a7e3a-bf9a-45a2-8fd8-2aa07a574880

In the excel spreadsheet line 100 is documented that the ONF air interface supports an integer to configure a maintenance window in seconds.

  |  +--rw air-interface:maintenance-timer?                  int32

Proposed solution

Add in the augmentation to the ietf-interface the following yang leaf:

    leaf maintenance-timer-duration {
      type uint32;
      units "s";
      default "0";
      description
        "Maintenance Feature: The duration of existence for any maintenance configuration, such as the loopback feature. A value of '0' indicates that the maintenance timer is deactivated. ";
    }

Having implemented the model in the 4th ETSI Plugtest for mw devices, we realized that the identityref coding-modulation does not provide all possible values. Some mw devices support 8 PSK modulation which is not included.

The use of identityrefs, even if it currently covers all values, also has the disadvantage of having to update the YANG model if new and more complex modulation schemes are standardized in the future.

A different approach could be taken to overcome this limitation. Let the device declare the acm profiles it supports, making explicit the parameters of each transmission ACM profile, and point to one of these in selected-min-acm, selected-max-acm or selected-cm.

Whereas each ACM profile is basically described by

• bandwidth
• modulation
• code rate (ratio between net bandwidth and gross bandwidth
• a reduction factor of the symbol rate (usefull for half-bpsk)
  to which generic parameters can be added, such as (for example) a descriptive name of the profile and a value to organize the profiles in ascending/descending order

the following structure could be assumed as an ACM profile entry:

grouping acm-profile {
 leaf acm-profile-name {
      typestring;
      ...
     "Eg: 4qam-strong"
 }
 leaf acm-profile-order {
   type int32;
   ...
   "1 to N"
 }
 leaf channel separation {
   type int32;
   units "kHz";
   ...
 }
 leaf modulation-scheme {
   type int16;
   units "symbols";
   ...
   "2=BSPK ... 10=1024qam ... 12=4096qam"
 }
 leaf code rate {
   type int8;
   units "%";
   ...
 }
 leaf symbol-rate-reduction-factor {
   type int8;
   default "1";
    "Reduction factor for the symbol rate. Example: value would be 2 for 1/2BPSK.";
 }
 leaf supported-as-fixed-configuration {
   type boolean;
   defaults "false";
    "true = This acm profile is available for manual configuration when Adaptive Modulation is switched off.";
 }

}

From which it would also be possible to obtain the available radio capacity with the simple formula:
tx-capacity = channel-separation * log2(modulation-scheme) * code-rate / symbol-rate-reduction-factor / K ;
K takes into account the rolloff (approx. 1.15).

The device could only show the profiles of the selected channel-separation, if one accepted that the list containing the ACM profiles is not invariant over time. In this case, acm-profile grouping might not include the channel-separation attribute.

The selected-min-acm, selected-max-acm or selected-cm attributes should become leafrefs pointing to one of the ACM profiles.

With this approach, although complex, it is not necessary to maintain the identityref in the future.
Even the user who has to configure the ACM profiles would be facilitated in the setting, having the list of values supported by the device available.

The need is to enable and define the compression of the Ethernet Header data on top of a Radio Link.
A new attribute could be added to RLT interface:
-- rw header-compression-mode

Currently the yang module has the following description.

description
"This is a module for the entities in
a generic microwave system.

Based on the discussion from 2023-08-17 (https://github.com/samans/draft-ybam-rfc8561bis/blob/main/minutes/2023-08-17.md) we may want to add a kind of 'scope' to the description.

Proposal for discussion:

description
"This module pertains to the components within a microwave system ([sko] network function ??).
Its purpose is to establish the specific configurations associated with radio links.
Configurations that concern the management of faults, performance, security, synchronization,
as well as packet and Ethernet management within a microwave system ([sko] network function ??),
are encompassed by distinct yang modules."

ALIC: Adjacent Link Interference Cancelation

The ALIC feature is not a common microwave device feature.
// @ALL: is this statement true?

Therefore the model should not support ALIC related configuration.
The issue can be 'rejected'.

In the excel spreadsheet line 97 and98 is documented that the ONF air interface supports encryption related configurations.

     |  |     |  +--rw air-interface:encryption-is-on?                   boolean
     |  |     |  +--rw air-interface:cryptographic-key?                  string

Discussion:

I would prefer that such feature is handled by
https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/28/

But this module is still a draft - how can we deal with it?

The example of B.1. Instance data for 2+0 mode includes JSON data from the ietf-interfaces and ietf-microwave-radio-link. If I understand properly, the module ietf-tp-interface-reference-topology enables all information of ietf-interfaces to be reported in topology models.

Microwave information are reported twice: the example highlight this copy for channel-separation, tx-frequency and rx-frequency/duplex-distance.
Do you also perceive this as duplication? How can we avoid that duplication?

Side note: Interestingly, L2Interface1 and L2Interface2 have a type of ethernetCsmacd discussed in issue #19.

The selection of the Reference Mode as a value of coding-modulation value between the 'selected-min-acm' and the 'selected-max-acm' is requested to be added as new attribute.
The attribute's name could be 'reference-cm' under the choice 'coding-modulation-mode/adaptive' .
As in the following:

o Refer to the existing alarm management module?
o What’s the “Specific Problem”?
 exists in the IETF alarm modeling [to be double checked by both sides (see bullets below)]
o Comment: information abundance is going to be important to feed future AI algorithms
o Specific problems.
o This parameter, when present, identifies further refinements to the Probable cause of the alarm. This parameter qualifies the chosen Probable cause and may be used by the managed object class definer to specify a set of identifiers for use in managed object classes.” according to ITU (X.733-1992 X.733 : Information technology - Open Systems Interconnection - Systems Management: Alarm reporting function (itu.int))
o RFC8632 is the alarms IETF RFC https://datatracker.ietf.org/doc/html/rfc8632
o Action: To Everyone, review RFC 8632 against the definition in X.733 and provide input of information that needs to be considered for probable cause.

o Calculated how? Consumption per link? Per carrier? Or Aggregate for the node?
o Suggestion: A system is modular, the modules are chassis that take power, so power consumption is measured at the granularity of the chassis. Take this to the carriers to determine if this provides the power consumption information needed.
o Action: proposal for electrical power consumption model (and granularity of measurement)
o Action: Can carriers agree that chassis-level measurement is sufficient.

Create a proposal to deprecate leaf mode in the augment to the interface model and the augment to microwave-topology and create a container that provides flexible assignment of number of bonded carriers and number of protecting carriers.

example:

   augment "/if:interfaces/if:interface" {
      description "Augment to provide example of new mode option for microwave radio link";
      container mode-option {
         description "Container that provides flexible definition of number of bonded carriers and protecting carriers";
         leaf num-bonded-carriers {
            type uint32;
            description "Number of bonded carriers";
         }
         leaf num-protecting-carriers {
            type uint32;
            description "Number of protecting carriers";
         }
      }
   }

Determine where to put the above code, in a types file wrapped in a grouping for example, then create a choice that deprecates mode and adds a uses that includes the new mode-option.

In mw devices that support Adaptive Coding and Modulation (ACM) the transmit power range is specific to each ACM. Typically the output power is dependent to the geometry of the transmitted constellation, therefore the output power decreases as the complexity of the modulation increases. The minimum-power and maximum-available-power values currently available in capabilities do not model this characteristic well enough.

The valid power ranges should be shown by the device in a sorted list indexed by modulation (coding-modulation). For this purpose, the acm-profile list proposed in issue #13 could be used, including the minimum and maximum tx power values in the acm-profile grouping.

grouping acm-profile {
   ...
    leaf tx-power-min {
       int8;
       units "dbm";
       ...
      "Eg: 4qam-strong"
    }
    leaf tx-power-max {
       int8;
       units "dbm";
       ...
      "Eg: 4qam-strong"
    }
}

With these values available, a user is able to set a valid output power value after selecting the single Coding Modulation value (selected-cm) or the Adaptive Coding Modulation range (selected-min-acm and selected-max-acm).

To maintain backward compatibility, the currently modeled minimum-power and maximum-available-power attributes could show the minimum tx power value for available-max-acm and the maximum tx power value for available-min-acm, respectively

During the 4th mWT plugtest, we see there were a challenge between our ietf-microwave-radio-link module and the model involved in the Bridging logic, the ieee-dot1q-bridge module. That relates to framework described in RFC8432.

The ieee-dot1q-bridge model can perform bridging between ethernet interfaces only (those with "type": "ianaift:ethernetCsmacd"). Not Microwave (neither thoses "type" are "ianaift:microwaveCarrierTermination" nor "ianaift:microwaveRadioLinkTerminal "). That is caused by a when cause of the ieee-dot1q-bridge.

The resulting stack: "virtual Ethernet" over the RadioLinkTerminal over the CarrierTermination (see diagram below). I am calling "virtual Ethernet" as opposed as real 802.3 interfaces (which really cares about duplex, negotiation, etc...).

That introduce 2 challenges:

• The "virtual Ethernet" interface implements the ieee802-ethernet-interface module, with leaves of <negotiation-status>, <duplex>, <speed> and other physical parameters which are meaningless because that layer is virtual.
• That also adds a new "virtual Ethernet" interface in the configuration and data: We need to model the relation netween "virtual Ethernet" and RadioLinkTerminal. During the plugtest, it was decided to be "internal mapping" on 12th call and each vendors provided the interface and to the script.

Few questions I wonder:

• Are we still comfortable with that?
• How can we known which "virtual Ethernet" corresponds to a microwaveRadioLinkTerminal? And the other way around?
• Do we have the same challenge if a Microwave equipment is performing IP routing instead of Ethernet bridging?

Please, tell me is there is anything wrong or incomplete with my interpretation of the challenge.

References:

• ieee802-dot1q-bridge
• ieee802-ethernet-interface
• "Figure 1: Relationship between Interfaces in a Node" page 4 of RFC8432
• Minutes of meeting of the 12th call for 4th mWT Plugtests

This issue is related to #22 and should address the following ONF parameters:

 +--ro air-interface:supported-radio-signal-id-datatype?            radio-signal-id-datatype-type	x
 +--ro air-interface:supported-radio-signal-id-length?              int16	x
 +--ro air-interface:expected-equals-transmitted-radio-signal-id?   boolean	x
 +--rw air-interface:transmitted-radio-signal-id	x
 |  +--rw air-interface:numeric-radio-signal-id?        int32	x
 |  +--rw air-interface:alphanumeric-radio-signal-id?   string	x
 +--rw air-interface:expected-radio-signal-id	x
 |  +--rw air-interface:numeric-radio-signal-id?        int32	x
 |  +--rw air-interface:alphanumeric-radio-signal-id?   string	x
 +--ro air-interface:received-radio-signal-id	x
 |  +--ro air-interface:numeric-radio-signal-id?        int32	x
 |  +--ro air-interface:alphanumeric-radio-signal-id?   string	x
 |  +--rw signalling-format?    string	x

Feature description.

There should be a to transmit a configurable ID to the receiver. if the receiver detects a mismatch between the received and expected ID an alarm should be raised.

personal remarks:
The alarm is also known as "Trail trace identifier (TTI) mismatch" in OTN - ITU-T G.709/Section 15.2

I could not find in IETF a related model

A similar model can be found in openconfig: https://github.com/openconfig/public/blob/master/release/models/optical-transport/openconfig-terminal-device.yang#L481

o original intent was to support the power consumption optimization, based on actual link traffic load
 Per carrier and per link (bundled)
o Interval?
 Action: everyone to consider and bring proposals/thoughts on measurement interval granularity
 current 15 minute integration time is too long for advanced applications
• For non-continuous transmission (packet transmission) the integration time should not be too short
o Integration time could be much shorter than 15 minutes, reporting max and min could be on a 15 minutes interval
o Percentage relative to what?
 maximum and minimum modulation (static)
 Action: everyone to consider and bring contributions that provide clarity on the interaction between electrical power consumption and traffic

Here the comments to be addressed (and replayed to) :

--
A follow up to an earlier comment of mine relating to
leaf actual-transmitted-level {
type decimal64 {
fraction-digits 1;
range "0..99";
I was unsure if the maximum value was then 99.9 or 99.0 so I asked on the NETMOD list and the answer is 99.0. I note that the same construct is used in RFC8561 so I assume that 99.0 is a magic number in microwave.

--
One more thought. The Appendices would benefit from a reference to RFC8792.

--
8561 is an import so must be a Normative reference

"ETSI EN 302 217-1 -
"ETSI EN 301 129 -
need adding as references as a URL so I can see if they are accessible

1.1
should include
ctp
rlt
rltp
snir
IMHO

carries, in various configurations/modes. T perhaps 'carriers'

. The supporting carriers are identified by its termination points /its/their/

s.3.3
L2 ethernet
Is there an Ethernet that is a different layer?

s.3.4
augmented by the microwave topology model a reference would be useful

module
snir
fraction-digits 1;
range "0..99";
I imagine that that excludes 99.9 or 99.1 etc

actual transmitted level
ditto

when choices specify mw-tp mw-link is one of the choice mandatory?

apply only for networks with an microwave network topology type
/an/a/

A.1
10.10.10.1
is not an address for documentation use

A.2
dirro

B.1
ditto

The authors would like to thank ...

To help configure an acceptable value in <channel-separation> it may be useful to list in the <capabilities> container the channel separation supported by the device.

This issues is an add on on the discussion around #13 and #16.
In this issues it should be discussed if a list of coding-modulation-profiles (cm-profile) should be modelled and how it could be used.
Basically what is the value of such profiles.

Current understanding - to be challenged :)

• A CM-profile does not group a set of configuration parameters and its values. So it must not be used as a kind of bulk configuration.
• A CM-profile describes the constrains of depending parameters
  • Example: parameter-value-a must not exceed value x if parameter-value-b is equals to y.
  • Therefore a coding-modulation-profile can be used for validating the configuration.
• A CM-profile describes the "behaviour" of a device and includes information of a technical description in a machine readable way.

Base on the understanding above a use case could be that the SDN Controller validates the configuration to the device against a selected profile.

Source code - feel free to modify ietf-microwave-usage-of-coding-modulation-profile.puml.txt

o Latency of what? Link? Service? Defined on Ethernet traffic, any requirements on interval for measurement of latency?
o Requirements related to supporting configuration of L2 or L3 service based on latency, availability, and capacity.
o Differentiate between what needs to be stored/retrieved/measured from the equipment, or supported by an end-to-end protocol like TWAMP.
o Ethernet OAM IEEE CFM (current CFM YANG found here: yang/standard/ieee/published/802.1 at master · YangModels/yang · GitHub), ITU-T work on G.8052.1 (G.8052.1 : Operation, administration, maintenance (OAM) management information and data models for the Ethernet-transport network element (itu.int))
o Applicability of current tools to the given requirements based on new features like slicing.
o Action: to the equipment vendors to propose what support is available on the equipment (capabilities may be beyond the microwave modeling work, more related to system-level OAM measurement/management).
o Action: identify the YANG models that identify the latency measurement

I read the ietf-microwave-topology and I wonder why the actual-received-level power is absent : If the NMS have the SNIR it probably also known the received power. I believe that you discussed that and I am not sure if an "issue" is an appropriate section for such question.

        +--:(microwave-carrier)
           +--rw microwave-carrier!
              +--rw tx-frequency?               uint32
              +--rw rx-frequency?               uint32
              +--rw channel-separation?         uint32
              +--ro actual-tx-cm?               identityref
              +--ro actual-snir?                decimal64
              +--ro actual-transmitted-level?   decimal64
              +--ro actual-received-level?      decimal64  /* This line does not exist. */

In addition, I see that the module ietf-microwave-radio-link use a type power whereas ietf-microwave-topology directly uses type decimal64 for power levels.

Consider including support for BCA in the update.
Check previous discussion on this. See issue #1.

With adaptive modulation enabled, which modulation does this refer to?
It’s a planning target
o at least for the lowest modulation allowed on the link (the other margins can be calculated by the controller)
o what about the threshold degradation due to interference?
 To be managed between planning tool / optimization tool / SDN Controller, not in the equipment

In the excel spreadsheet line 84 is documented that the ONF air interface supports a boolean to disable/enable the receiver.

Proposed solution:

Add in the augmentation to the ietf-interface the following parameters

  |     +--rw mrl:rx-enabled?                     boolean
  |     +--ro mrl:rx-oper-status?                 enumeration