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

[Scott Mansfield <[e-mail]>]

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/