[CCAMP] Notes: CCAMP - Microwave - 2021-03-03

[Jonas Ahlberg <[e-mail]>]

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]>; 'Dragos-Iulian Dosan' <[e-mail]>; 'Yemin (Amy)' <[e-mail]>; Scott Mansfield <[e-mail]>; 'Italo Busi' <[e-mail]>; 'Belotti, Sergio (Nokia - IT)' <[e-mail]>; 'Xi Li' <[e-mail]>; 'Leonida Macciotta' <[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
     *   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
     *   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.