[CCAMP] Notes: CCAMP - Microwave - 2021-04-14

[Jonas Ahlberg <[e-mail]>]

Hi all,

Notes from today's meeting.

Microwave topology model

  *   Overall model structure
     *   Walk through and discussion about the different alternatives describes in the notes from last week's meeting. See below.
     *   Next step is to go back and look at these from a use-case point of view.
  *   Choice of names
     *   Unless there is a specific reason for it, the same names as in RFC 8561 should be used, i.e. radio-link and carrier.
     *   Is there a reason?
  *   Attributes
     *   Focus on what is required to be added directly into the topology model.
     *   Next step is to go back and look at these from a use-case point of view.
  *   Next week:
     *   Use case driven discussion
     *   Jonas to summarize previous discussions and use cases to be considered and send out info in advance of next week's meeting.

ETSI Gap analysis

  *   Meeting with operator representatives expected in a few weeks' time
  *   The reference mode is assumed to be based on the definition in ETSI EN 302 217-2 V3.2.2
     *   All to confirm in next meeting.

/JonasA


From: CCAMP <[e-mail]> On Behalf Of Jonas Ahlberg
Sent: den 7 april 2021 14:30
To: ccamp <[e-mail]>
Subject: [CCAMP] Notes: CCAMP - Microwave - 2021-04-07

Hi all,

Notes from today's meeting.

Microwave topology model

  *   Italo walked through the latest JSON examples.
  *   Three alternatives for modelling the radio-link to carrier relationship
     *   According to current draft
        *   Carriers (channels) modeled as entries in a list under radio-link and not as separate links in the topology model
        *   Cannot leverage the attributes such as oper-status in the existing topology models
     *   Carriers (channels) modelled as separate links in the topology model

        *   Radio-link to carrier relationship described by supporting-link from network-topology
           *   Basic/simple construction
           *   Cannot describe the details of the configured mode without additional attributes
        *   Radio-link to carrier relationship described by bundled or underlay links from te-topology
           *   More advanced/complicated construction
           *   Can describe more, but still not all aspects of the configured mode
  *   Two alternatives for the microwave information
     *   Include attributes directly into the topology model

        *   Possibility to use groups to maintain alignment with e.g. the interface management models

  1.  Assume a parallel set of node data, to which the topology model can refer

        *   E.g. a separate list of all nodes in the network, to which miscellaneous data can be added such a interface management info, inventory info, node info (energy consumption), ...
        *   Topology model using reference to that data when applicable and only includes data in the topology model itself when the data cannot be found elsewhere

Not discussed:
Need to resolve the choice of names - carrier or channel

-          Radio-link and carrier are the terms used in RFC 8561

Microwave attributes to be added to the topology model

-          Use the concept of grouping for the attributes that can be inherited from RFC 8561

-          Any other attributes required?

ETSI gap

  *   Plan going forward:
     *   Mail sent by Leo to operator representatives in ETSI information them about this work and with a request for a meeting to clarify the definitions of the attributes
     *   Decided to only use the excel sheet internally.
  *   Another attribute, not in the list of gaps, to be discussed
     *   Reference mode - To be further clarified internally
        *   How does this relate to the definition in ETSI EN 302 217-2 V3.2.2?
           *   Reference mode (reference equipment class and channel separation): in mixed-mode systems, it identifies the operative mode which characteristics (i.e. system capacity, spectral efficiency class over a given channel separation) are used (i.e. declared in the licensing process) in the link per link coordination analysis
           *   Classes: 2, 3, 4L, 4H, 5L, 5H, 6L, 6H, 7, 8

Regards
/JonasA


From: CCAMP <[e-mail]<mailto:[e-mail]>> On Behalf Of Jonas Ahlberg
Sent: den 1 april 2021 10:44
To: ccamp <[e-mail]<mailto:[e-mail]>>
Subject: [CCAMP] Notes: CCAMP - Microwave - 2021-03-31

Hi all,
Short notes from the weekly meeting.

Microwave topology model
Discussion about the different options for modelling the relationship between aggregated radio links and supporting carriers is on-going, supported by JSON examples prepared by Italo.

  *   Options are:
     *   Carriers modelled as list-items in the radio-link container
     *   Carriers modelled as separate links
        *   Using supporting-termination-point and supporting-link from network-topology for the relationship to radio-link (tp & link)
        *   Using overlay/underlay from te-topology, possibly including primary-path & backup-path for protection
        *   Using bundled links from te-topology?
  *   Examples of configurations to be supported:
     *   Bonded: 2+0. 4+0, ...
     *   Protected: 1+1, 2+2, ...
     *   Radio-link protection: n+1
     *   ...
  *   We need to identify all relevant microwave configurations required and make sure that they can be supported by the existing underlay construction in te-topology

Need to resolve the choice of names - carrier or channel

  *   Radio-link and carrier are the terms used in RFC 8561

Microwave attributes to be added to the topology model

  *   Use the concept of grouping for the attributes that can be inherited from RFC 8561
  *   Any other attributes required?

ETSI update

  *   Attached excel sheet, lists the gap according to ETSI WI 25 and summarizes the reflections from our team.
  *   Many of the attributes need to be more clearly defined before we can conclude on if they can be supported in RFC 8561 or not.
  *   Other attributes are not directly related to microwave and need to be covered by other models. Some of them are related to other IETF models, such as ietf-alarm-management. Other are related to models defined by IEEE and ITU-T.
  *   Plan going forward:
     *   Mail sent by Leo to operator representatives in ETSI information them about this work and with a request for a meeting to clarify the definitions of the attributes
     *   Review of excel sheet. After that we can share that with the ETSI representatives
  *   Another attribute, not in the list of gaps, to be discussed
     *   Reference mode - To be further clarified internally

/JonasA


From: CCAMP <[e-mail]<mailto:[e-mail]>> On Behalf Of Jonas Ahlberg
Sent: den 17 mars 2021 15:18
To: ccamp <[e-mail]<mailto:[e-mail]>>
Subject: [CCAMP] Notes: CCAMP - Microwave - 2021-03-07

Short notes from the weekly microwave team meeting.

Microwave topology model
Italo presented new alternatives for how to make use of the te-topology model.

  *   Walk through of new JSON examples:
     *   Two variants of n+1 protection:
(Need to check if both are applicable or not - AP on all)
        *   Multiple (n) radio-links (1+0) sharing protection from one carrier (basis for JSON examples 8-10)
        *   One radio-link with n active & 1 protecting carriers
  *   We need to identify all relevant microwave configurations required and make sure that they can be supported by the existing underlay construction in te-topology

Need to resolve the choice of names - carrier or channel

Microwave attributes to be added to the topology model

  *   Use the concept of grouping for the attributes that can be inherited from RFC 8561
  *   Any other attributes required?

ETSI update

  *   Walk through of attached excel sheet, listing the gap according to ETSI WI 25 and summarizing the reflections from our team.
  *   Many of the attributes need to be more clearly defined before we can conclude on if they can be supported in RFC 8561 or not.
  *   Other attributes are not directly related to microwave and need to be covered by other models. Some of them are related to other IETF models, such as ietf-alarm-management. Other are related to models defined by IEEE and ITU-T. How this should be handled remains to be understood.
  *   Plan going forward:
     *   Internal review and discussion about the ETSi gaps
     *   Inviting the operator representatives from the ETSI working group to these team meetings with the purpose to clarify the definition of the attributes and agree on how to manage the gaps.

/JonasA



From: CCAMP <[e-mail]<mailto:[e-mail]>> On Behalf Of Jonas Ahlberg
Sent: den 3 mars 2021 13:02
To: ccamp <[e-mail]<mailto:[e-mail]>>
Subject: [CCAMP] Notes: CCAMP - Microwave - 2021-03-03

Hi all,

Notes from the weekly microwave team meeting.

Microwave topology model
Italo presented new alternatives for how to make use of the te-topology model.

  *   Example 6 & 7 (protected & bundled) have a potential to support the various microwave configurations (1+0, 2+0, 1+1, etc).
  *   We need to identify all relevant microwave configurations required and make sure that they can be supported by the existing underlay construction in te-topology
  *   Italo to check n+1 (one backup path for several primary/active paths)

Need to resolve the choice of names - carrier or channel

Microwave attributes to be added to the topology model

  *   Use the concept of grouping for the attributes that can be inherited from RFC 8561
  *   Any other attributes required?

ETSI update

  *   Action on all of us to go through the ETSI document and add comments/reflections on the red-attributes for the IETF-columns by next week's meeting

/JonasA


From: Jonas Ahlberg
Sent: den 24 februari 2021 13:03
To: 'Spreafico, Daniela (Nokia - IT/Vimercate)' <[e-mail]<mailto:[e-mail]>>; 'Dragos-Iulian Dosan' <[e-mail]<mailto:[e-mail]>>; 'Yemin (Amy)' <[e-mail]<mailto:[e-mail]>>; Scott Mansfield <[e-mail]<mailto:[e-mail]>>; 'Italo Busi' <[e-mail]<mailto:[e-mail]>>; 'Belotti, Sergio (Nokia - IT)' <[e-mail]<mailto:[e-mail]>>; 'Xi Li' <[e-mail]<mailto:[e-mail]>>; 'Leonida Macciotta' <[e-mail]<mailto:[e-mail]>>
Subject: Notes: CCAMP - Microwave Topology - 2021-02-24

Hi,

Some short notes.

Microwave specific attributes I the topology module:

  *   Including the new groups for microwave specific attributes into the microwave-types module can be done in three different ways:
     *   Make a new revision of RFC 8561 (preferred approach, since then gaps identified in ETSI work can be filled at the same time)
     *   Create a new separate draft/RFC for the revised microwave-types only
     *   Include the revised microwave-types in the new microwave topology draft/RFC
  *   The required groups and attributes to be included is for further study.

Modeling carriers as separate links in the topology model:

  *   Interesting approach that should be further explored
  *   Illustrate how radio link level tps and links can be associated with the supporting carrier level tps and links
  *   The content inside the presence containers need to be further studied - Related to the groups in microwave-types
  *   Bandwidth per link or not? Te-bandwidth?

Revision of RFC 8561 based on ETSI feedback

  *   Summarized in the ETSI document: mWT(21)018_004r1 - ETSI_mWT_ISG-WI25-Group_Report_v0.0.2<https://protect2.fireeye.com/v1/url?k=e917edea-b68cd4a9-e917ad71-861fcb972bfc-b8afdc9109ba53e2&q=1&e=bd101923-19fb-4b2a-97e2-6b12557f8a78&u=http%3A%2F%2Fportal.etsi.org%2Fngppapp%2FContributionCreation.aspx%3Fprimarykeys%3D217687>
  *   To be further discussed at the next meeting.

/JonasA

From: Jonas Ahlberg
Sent: den 18 februari 2021 15:50
To: 'Spreafico, Daniela (Nokia - IT/Vimercate)' <[e-mail]<mailto:[e-mail]>>; 'Dragos-Iulian Dosan' <[e-mail]<mailto:[e-mail]>>; 'Yemin (Amy)' <[e-mail]<mailto:[e-mail]>>; Scott Mansfield <[e-mail]<mailto:[e-mail]>>; 'Italo Busi' <[e-mail]<mailto:[e-mail]>>; 'Belotti, Sergio (Nokia - IT)' <[e-mail]<mailto:[e-mail]>>; 'Xi Li' <[e-mail]<mailto:[e-mail]>>; 'Leonida Macciotta' <[e-mail]<mailto:[e-mail]>>
Subject: Notes: CCAMP - Microwave Topology - 2021-02-18

Hi all,

Some of the topics discussed today, which we need to follow up in the coming meetings.


  *   An alternative to referencing the interface management information using xpath/mount-point  is to create groups of the attributes in RFC 8561 and use them directly in the topology model
     *   Start with a minimum scope - See current draft (frequency, ...) - Focus on the principle rather than the attributes to include (DanielaS)
  *   Considering that most operations will be related to carriers/channels, should carriers be modelled as a separate/related topology layer instead of having the carriers as a list in the link attributes?
     *   Can we use the presence container approach (or similar) to distinguish between radio links and carriers in one single topology?
     *   Create an example of how this could look like (ItaloB)
  *
  *   The relevant data nodes in network-topology and te-topology models. (see word document from mail Feb 4)
     *   Network-topology
        *   Supporting node/link/termination-point not relevant unless carriers and radio links are modelled as separate layers
     *   Te-topology
        *   Need to go through the turquoise candidate data nodes and clarify if they are applicable and what they really mean


Next meeting is on Wednesday Feb 24, 12-13 (CET).

Regards
JonasA

From: Jonas Ahlberg
Sent: den 4 februari 2021 17:04
To: Spreafico, Daniela (Nokia - IT/Vimercate) <[e-mail]<mailto:[e-mail]>>; Dragos-Iulian Dosan <[e-mail]<mailto:[e-mail]>>; Yemin (Amy) <[e-mail]<mailto:[e-mail]>>; Scott Mansfield <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>; Belotti, Sergio (Nokia - IT) <[e-mail]<mailto:[e-mail]>>; Xi Li <[e-mail]<mailto:[e-mail]>>; Leonida Macciotta <[e-mail]<mailto:[e-mail]>>
Subject: RE: Notes: CCAMP - Microwave Topology - 2021-02-03

Hi all,

I've started to look into what data nodes we need for the microwave topology.
I've looked at network-topology and te-topology models and indicated which data nodes I believe are relevant.
I've also listed a few data nodes that need to be added on top of what can be augmented, based on our previous discussions.
See attached word document. Please comment.

Italo & Scott, I hope that this can serve as input to the JSON example you are working on as well.

Regards
JonasA

From: Jonas Ahlberg
Sent: den 3 februari 2021 14:16
To: 'Spreafico, Daniela (Nokia - IT/Vimercate)' <[e-mail]<mailto:[e-mail]>>; 'Dragos-Iulian Dosan' <[e-mail]<mailto:[e-mail]>>; 'Yemin (Amy)' <[e-mail]<mailto:[e-mail]>>; Scott Mansfield <[e-mail]<mailto:[e-mail]>>; 'Italo Busi' <[e-mail]<mailto:[e-mail]>>; 'Belotti, Sergio (Nokia - IT)' <[e-mail]<mailto:[e-mail]>>; 'Xi Li' <[e-mail]<mailto:[e-mail]>>; 'Leonida Macciotta' <[e-mail]<mailto:[e-mail]>>
Subject: Notes: CCAMP - Microwave Topology - 2021-02-03

Hi all,

AP on all for next week: Go through the use cases and reflect upon the attributes required.
Next meeting: Start the discussion about attributes/data nodes required to support the use cases.
In two weeks, the meeting will be moved to Thursday 18, the same time. Jonas to ask Daniele to change the invite.

New proposal on how to use te-topology for non-te-topologies

  *   Would the client need to know about the profile, what data nodes are supported by the server? Read-only & Config nodes.
     *   Read-only not an issue - Will only respond if there it is instantiated
     *   Write - Italo will look into this further - A general issue
  *   JSON example from ETSI plug-test for Ethernet topology worked on by Italo & Scott in order to illustrate how te-topology can be used for non-te topologies. Walk through next week.

Review of the use cases:

  *   Service/connectivity use cases - See attached slide pack (Use case for Microwave Radio Link Topology model)
     *   Two alternatives: slide 3 & 5 illustrating when different L1 technologies can be modelled in the same topology and 4 & 6 when they are modelled in different topologies
     *   The other slides serve as a basis for discussing how higher layer connections/topologies relate to underlying topologies
  *   ETSI use cases
     *   Use cases described in the ETSI use case document, "Applications and use cases of Software Defined Networking (SDN) as related to microwave and millimeter wave transmission"
     *   https://www.etsi.org/deliver/etsi_gr/mWT/001_099/016/01.01.01_60/gr_mWT016v010101p.pdf<https://protect2.fireeye.com/v1/url?k=335f9651-6cc4af7c-335fd6ca-8692dc8284cb-688bce6b7fc80faf&q=1&e=6f8f782b-4979-4840-b4a7-c2957a48474d&u=https%3A%2F%2Fwww.etsi.org%2Fdeliver%2Fetsi_gr%2FmWT%2F001_099%2F016%2F01.01.01_60%2Fgr_mWT016v010101p.pdf>
     *   Main focus on the use cases in chapter 5.1 "Radio link network segment in itself"
     *   Attached are also some comments from Jonas and Stephen (Re: [CCAMP] Notes: Microwave Topology - 2020-05-18)
     *   Walk through the two other main chapters to understand if they put additional requirements on a topology model or not.
  *   Geo-location is another use case candidate
     *   Amy to explain in writing/drawing

Attributes:

  *   Bandwidth availability: On radio link level and/or the carrier level. To be further discussed.

Other Issues/Considerations/Conclusions:

  *   Should the model be defined to support a specific set of use cases or should it be generic with the ambition to support any future use case?
  *   Should bandwidth availability be reported for the aggregated radio link and/or for each individual carrier?
  *   If bandwidth availability is a generic characteristic, should it then be modelled in TEAS WG instead of CCAMP?
  *   The choice of mount point v.s. xpath need to be explained/understood
  *   Should a reference from a termination point to an interface (mount/xpath) be generic instead of microwave specific?
  *   Is the use of groups a better way to include interface related leafs than the use of mount/xpath? What would the impact on RFC 8561 & RFC 8343 be?
  *   How can multiple L1 technologies (e.g. microwave radio links & copper cables) co-exist in a single network instance? (use of presence containers)
  *   Is there a need to model more than current bandwidth and the bandwidth that can be supported with various availability (maximum to minimum)?
  *   Is there any other bandwidth information in te-topology than "nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth" that is relevant?
  *   Reserved & un-reserved bandwidth is not relevant for microwave radio links & carriers
  *   Can generic te-topology bandwidth leafs be used as is (see L3 topology) or do we always need mw specific versions
  *   If admin & oper status in te-topology should be used, then there is a need to describe how such attributes on a topology level relate to the admin/oper status of the radio link and carriers in the interface management model
  *   How to make it bandwidth/availability available to higher layers?
     *   It was decided to make it generic and create a separate module that can be reused by any technology with the assumption that bandwidth/availability information need to be aggregated/calculated/discovered or configured
     *   Should this approach be used for other characteristics as well? (frequency, latency, ...)
  *   Attaching a mail with a summary of other discussions in the area. (Notes: Microwave Topology - 2020-03-23)
  *   Understand a suggested new role of te-topology for network topologies in general (not only te-topologies)
  *   What is the benefit of augmenting te-topology rather than network-topology? Based on use-cases & required leafs.


/JonasA



From: Jonas Ahlberg
Sent: den 28 januari 2021 15:16
To: Spreafico, Daniela (Nokia - IT/Vimercate) <[e-mail]<mailto:[e-mail]>>; Dragos-Iulian Dosan <[e-mail]<mailto:[e-mail]>>; Yemin (Amy) <[e-mail]<mailto:[e-mail]>>; Scott Mansfield <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>; Belotti, Sergio (Nokia - IT) <[e-mail]<mailto:[e-mail]>>; Xi Li <[e-mail]<mailto:[e-mail]>>; Leonida Macciotta <[e-mail]<mailto:[e-mail]>>
Subject: Notes: CCAMP - Microwave Topology - 2021-01-28

Hi all,

Some short notes from today.
Please remember that next week the meeting is on Wednesday again.


  *   New proposal on how to use te-topology for non-te-topologies (Italo)
     *   Would the client need to know about the profile, what data nodes are supported by the server? Read-only & Config nodes.
     *   Follow up next week.
     *   Italo will share the slides with the team.



  *   Review of the use cases: (Move to next meeting)
     *   Which ones are applicable to be supported by the microwave topology model?
     *   Any use cases missing?
     *   Any other attributes than what is provided the basic topology structure (tp, link etc), bandwidth, availability and what's in RFC 8561 that would be required to support the use cases?
(If that should be supported by references to 8561 or if the attributes should be copied directly into the topology model is a separate/later question)

/JonasA

From: Jonas Ahlberg
Sent: den 20 januari 2021 14:42
To: Spreafico, Daniela (Nokia - IT/Vimercate) <[e-mail]<mailto:[e-mail]>>; Stephen Cheng <[e-mail]<mailto:[e-mail]>>; Dragos-Iulian Dosan <[e-mail]<mailto:[e-mail]>>; Yemin (Amy) <[e-mail]<mailto:[e-mail]>>; Scott Mansfield <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>; Belotti, Sergio (Nokia - IT) <[e-mail]<mailto:[e-mail]>>; Xi Li <[e-mail]<mailto:[e-mail]>>
Subject: Notes: CCAMP - Microwave Topology - 2021-01-20

Hi all,

Next meeting will be moved to Thursday Jan 28, 12:00 - 13:00 CET.

The proposed agenda:

  *   New proposal on how to use te-topology for non-te-topologies (Italo - 30 min)
  *   Review of the use cases: (30 min)
     *   Which ones are applicable to be supported by the microwave topology model?
     *   Any use cases missing?
     *   Any other attributes than what is provided the basic topology structure (tp, link etc), bandwidth, availability and what's in RFC 8561 that would be required to support the use cases?
(If that should be supported by references to 8561 or if the attributes should be copied directly into the topology model is a separate/later question)

/JonasA

From: Jonas Ahlberg
Sent: den 19 januari 2021 16:27
To: Spreafico, Daniela (Nokia - IT/Vimercate) <[e-mail]<mailto:[e-mail]>>; Stephen Cheng <[e-mail]<mailto:[e-mail]>>; Dragos-Iulian Dosan <[e-mail]<mailto:[e-mail]>>; Yemin (Amy) <[e-mail]<mailto:[e-mail]>>; Scott Mansfield <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>; Belotti, Sergio (Nokia - IT) <[e-mail]<mailto:[e-mail]>>; Xi Li <[e-mail]<mailto:[e-mail]>>
Subject: CCAMP - Microwave Topology - 2021-01-20

Hi all,
As agreed I've made a summary of the use-cases and work/discussions we have had so far.
There might be additional items that I have missed. Please add them to the list or bring them up at the meeting tomorrow.

I can make a walk-trough of it tomorrow.

/JonasA

Use cases:
(break apart into two cases: One basic with mw-topology only, which can serve as a basis for both connectivity & ETSI use cases.)

  *   Service/connectivity use cases - See attached slide pack (Use case for Microwave Radio Link Topology model)
     *   Two alternatives: slide 3 & 5 illustrating when different L1 technologies can be modelled in the same topology and 4 & 6 when they are modelled in different topologies
     *   The other slides serve as a basis for discussing how higher layer connections/topologies relate to underlying topologies



  *   ETSI use cases
     *   Use cases described in the ETSI use case document, "Applications and use cases of Software Defined Networking (SDN) as related to microwave and millimeter wave transmission"
     *   https://www.etsi.org/deliver/etsi_gr/mWT/001_099/016/01.01.01_60/gr_mWT016v010101p.pdf<https://protect2.fireeye.com/v1/url?k=5de4a901-027f902c-5de4e99a-8692dc8284cb-20eb97bd4b96e909&q=1&e=6f8f782b-4979-4840-b4a7-c2957a48474d&u=https%3A%2F%2Fwww.etsi.org%2Fdeliver%2Fetsi_gr%2FmWT%2F001_099%2F016%2F01.01.01_60%2Fgr_mWT016v010101p.pdf>
     *   Main focus on the use cases in chapter 5.1 "Radio link network segment in itself"
     *   Attached are also some comments from Jonas and Stephen (Re: [CCAMP] Notes: Microwave Topology - 2020-05-18)


Issues/Considerations/Conclusions

  *   Should the model be defined to support a specific set of use cases or should it be generic with the ambition to support any future use case?
  *   Should bandwidth availability be reported for the aggregated radio link and/or for each individual carrier?
  *   If bandwidth availability is a generic characteristic, should it then be modelled in TEAS WG instead of CCAMP?
  *   The choice of mount point v.s. xpath need to be explained/understood
  *   Should a reference from a termination point to an interface (mount/xpath) be generic instead of microwave specific?
  *   Is the use of groups a better way to include interface related leafs than the use of mount/xpath? What would the impact on RFC 8561 & RFC 8343 be?
  *   How can multiple L1 technologies (e.g. microwave radio links & copper cables) co-exist in a single network instance? (use of presence containers)
  *   Is there a need to model more than current bandwidth and the bandwidth that can be supported with various availability (maximum to minimum)?
  *   Is there any other bandwidth information in te-topology than "nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth" that is relevant?
  *   Reserved & un-reserved bandwidth is not relevant for microwave radio links & carriers
  *   Can generic te-topology bandwidth leafs be used as is (see L3 topology) or do we always need mw specific versions
  *   If admin & oper status in te-topology should be used, then there is a need to describe how such attributes on a topology level relate to the admin/oper status of the radio link and carriers in the interface management model
  *   How to make it bandwidth/availability available to higher layers?
     *   It was decided to make it generic and create a separate module that can be reused by any technology with the assumption that bandwidth/availability information need to be aggregated/calculated/discovered or configured
     *   Should this approach be used for other characteristics as well? (frequency, latency, ...)
  *   Attaching a mail with a summary of other discussions in the area. (Notes: Microwave Topology - 2020-03-23)
  *   Understand a suggested new role of te-topology for network topologies in general (not only te-topologies)
  *   What is the benefit of augmenting te-topology rather than network-topology? Based on use-cases & required leafs.