Subject: [CCAMP] Meeting note for 3 June 2021 IETF CCAMP - Microwave / ETSI GR mWT 025

From: Scott Mansfield <[email-masked]>
Date: Tue, 8 Jun 2021 11:27:18 +0000

Meeting note for 3 June 2021 IETF CCAMP - Microwave / ETSI GR mWT 025

Attendees:

Scott Mansfield

Daniela Spreafico

Gabriele Ferrari

Jean Rebiffé

Leo Macciotta

Zakaria Tayq

Min Ye (Amy)

Note:  Writing in blue is discussion that has occurred in previous CCAMP
Microwave meetings.  The text in red was discussed during the meeting.
Actions are marked with “Action:”

Regards,

-scott.

  _____  

*	BCA

*	Any mix of bands is included

*	Includes carrier aggregation in the same band

*	Intent:

*	Understand underlying topology
*	Address more advanced applications

*	Handling each carrier independently for specific purposes

*	Have the information about the total capacity

*	MW topo extension?

*	Performance information is important, like capacity latency

*	Combined performance of the bundle is required

*	--> potentially describes a set of attributes related to the
multicarrier

*	We are addressing L1 bonding
*	RFC8561 has a basis with the protection group

*	Extend or add a new group?

*	Fade Margin

*	With adaptive modulation enabled, which modulation does this refer
to?
*	It’s a planning target
*	--> at least for the lowest modulation allowed on the link (the
other margins can be calculated by the controller)
*	--> what about the threshold degradation due to interference?

*	To be managed between planning tool / optimization tool / SDN
Controller, not in the equipment

*	BER, Errored block – EB, Mean Time between outages, Outage Intensity

*	--> 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

*	Current Alarm Specific Problem, Historical Alarm Specific Problem

*	Refer to the existing alarm management module?
*	What’s the “Specific Problem”?

*	--> exists in the IETF alarm modeling [to be double checked by both
sides (see bullets below)]

*	--> Comment: information abundance is going to be important to feed
future AI algorithms
*	Specific problems.
*	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  <https://www.itu.int/rec/T-REC-X.733-199202-I/en> X.733 :
Information technology - Open Systems Interconnection - Systems Management:
Alarm reporting function (itu.int))
*	RFC8632 is the alarms IETF RFC
<https://datatracker.ietf.org/doc/html/rfc8632>
https://datatracker.ietf.org/doc/html/rfc8632
*	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.

*	Maximum Link/Carrier Utilization %

*	--> original intent was to support the power consumption
optimization, based on actual link traffic load

*	Per carrier and per link (bundled)

*	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

*	Integration time could be much shorter than 15 minutes, reporting
max and min could be on a 15 minutes interval

*	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

*	Latency

*	Latency of what?  Link? Service? Defined on Ethernet traffic, any
requirements on interval for measurement of latency?
*	Requirements related to supporting configuration of L2 or L3 service
based on latency, availability, and capacity.
*	Differentiate between what needs to be stored/retrieved/measured
from the equipment, or supported by an end-to-end protocol like TWAMP.
*	Ethernet OAM IEEE CFM (current CFM YANG found here:
<https://github.com/YangModels/yang/tree/master/standard/ieee/published/802.
1> yang/standard/ieee/published/802.1 at master · YangModels/yang · GitHub),
ITU-T work on G.8052.1 (
<https://www.itu.int/rec/T-REC-G.8052.1-202101-I/en> G.8052.1 : Operation,
administration, maintenance (OAM) management information and data models for
the Ethernet-transport network element (itu.int))
*	Applicability of current tools to the given requirements based on
new features like slicing.
*	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).
*	Action: identify the YANG models that identify the latency
measurement

*	Electrical Power Consumption

*	Calculated how?  Consumption per link?  Per carrier? Or Aggregate
for the node?
*	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.
*	Action: proposal for electrical power consumption model (and
granularity of measurement)
*	Action: Can carriers agree that chassis-level measurement is
sufficient.

Action:  Carriers to determine if there is a need for another ETSI
WI25/CCAMP discussion meeting.

Next Meeting of the CCAMP Microwave modeling work is: 9 June at 1200pm
(noon) CEST
<https://mailarchive.ietf.org/arch/msg/ccamp/dTo-UebzMQpqV4m-SHDTdnE39cg/>
https://mailarchive.ietf.org/arch/msg/ccamp/dTo-UebzMQpqV4m-SHDTdnE39cg/

---

From: "Spreafico, Daniela (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 8 Jun 2021 12:54:51 +0000

Hi all,
as Action Point for vendors about 'Current Alarm Specific Problem, Historical Alarm Specific Problem' , my side I checked on RFC8632 the concept of alarm 'specific problem' as defined on ITU X.733 .
I found it using the following leaf attribute of 'alarm-list' to identify an alarm instance (added to 'resource' and 'alarm-type-id')

leaf alarm-type-qualifier {
        type alarm-type-qualifier;

        description
          "This leaf is used when the 'alarm-type-id' leaf cannot
           uniquely identify the alarm type.  Normally, this is not the
           case, and this leaf is the empty string."

typedef alarm-type-qualifier {
      type string;
      description
        "If an alarm type cannot be fully specified at design time by
         'alarm-type-id', this string qualifier is used in addition to
         fully define a unique alarm type.

Taking into account that 'alarm-type-id' corresponds to the Probable cause (ITU X.733 ) of the alarm

BR, Daniela

From: CCAMP <[email-masked]> On Behalf Of Scott Mansfield
Sent: Tuesday, June 8, 2021 1:27 PM
To: [email-masked]
Subject: [CCAMP] Meeting note for 3 June 2021 IETF CCAMP - Microwave / ETSI GR mWT 025

Attendees:
Scott Mansfield
Daniela Spreafico
Gabriele Ferrari
Jean Rebiffé
Leo Macciotta
Zakaria Tayq
Min Ye (Amy)

Note:  Writing in blue is discussion that has occurred in previous CCAMP Microwave meetings.  The text in red was discussed during the meeting.  Actions are marked with "Action:"

Regards,
-scott.

________________________________

  *   BCA
     *   Any mix of bands is included
        *   Includes carrier aggregation in the same band
     *   Intent:
        *   Understand underlying topology
        *   Address more advanced applications
           *   Handling each carrier independently for specific purposes
        *   Have the information about the total capacity
           *   MW topo extension?
        *   Performance information is important, like capacity latency
           *   Combined performance of the bundle is required
     *   --> potentially describes a set of attributes related to the multicarrier
        *   We are addressing L1 bonding
        *   RFC8561 has a basis with the protection group
           *   Extend or add a new group?
  *   Fade Margin
     *   With adaptive modulation enabled, which modulation does this refer to?
     *   It's a planning target
     *   --> at least for the lowest modulation allowed on the link (the other margins can be calculated by the controller)
     *   --> what about the threshold degradation due to interference?
        *   To be managed between planning tool / optimization tool / SDN Controller, not in the equipment
  *   BER, Errored block - EB, Mean Time between outages, Outage Intensity
     *   --> 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
  *   Current Alarm Specific Problem, Historical Alarm Specific Problem
     *   Refer to the existing alarm management module?
     *   What's the "Specific Problem"?
        *   --> exists in the IETF alarm modeling [to be double checked by both sides (see bullets below)]
     *   --> Comment: information abundance is going to be important to feed future AI algorithms
     *   Specific problems.
     *   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)<https://www.itu.int/rec/T-REC-X.733-199202-I/en>)
     *   RFC8632 is the alarms IETF RFC https://datatracker.ietf.org/doc/html/rfc8632
     *   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.
  *   Maximum Link/Carrier Utilization %
     *   --> original intent was to support the power consumption optimization, based on actual link traffic load
        *   Per carrier and per link (bundled)
     *   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
              *   Integration time could be much shorter than 15 minutes, reporting max and min could be on a 15 minutes interval
     *   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
  *   Latency
     *   Latency of what?  Link? Service? Defined on Ethernet traffic, any requirements on interval for measurement of latency?
     *   Requirements related to supporting configuration of L2 or L3 service based on latency, availability, and capacity.
     *   Differentiate between what needs to be stored/retrieved/measured from the equipment, or supported by an end-to-end protocol like TWAMP.
     *   Ethernet OAM IEEE CFM (current CFM YANG found here: yang/standard/ieee/published/802.1 at master · YangModels/yang · GitHub<https://github.com/YangModels/yang/tree/master/standard/ieee/published/802.1>), 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)<https://www.itu.int/rec/T-REC-G.8052.1-202101-I/en>)
     *   Applicability of current tools to the given requirements based on new features like slicing.
     *   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).
     *   Action: identify the YANG models that identify the latency measurement
  *   Electrical Power Consumption
     *   Calculated how?  Consumption per link?  Per carrier? Or Aggregate for the node?
     *   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.
     *   Action: proposal for electrical power consumption model (and granularity of measurement)
     *   Action: Can carriers agree that chassis-level measurement is sufficient.

Action:  Carriers to determine if there is a need for another ETSI WI25/CCAMP discussion meeting.

Next Meeting of the CCAMP Microwave modeling work is: 9 June at 1200pm (noon) CEST https://mailarchive.ietf.org/arch/msg/ccamp/dTo-UebzMQpqV4m-SHDTdnE39cg/