Subject: [CCAMP] Notes: Microwave Topology - 2020-07-08

From: Jonas Ahlberg <[email-masked]>
Date: Thu, 9 Jul 2020 09:01:08 +0000

Hi all,

Participants:
Daniela Spreafico
Scott Mansfield
Stephen Cheng
Xi Li
Jonas Ahlberg

The status of the attempt to make a dynamic instantiation was presented & discussed.

  *   PYANG compiles cleanly, but when using Yuma123 there are errors that still remain to be sorted out
     *   The errors occur in ietf-microwave-radio-link module
        *   The yang file for iana types has not been updated since 2017 and thereby the two microwave types microwaveRadioLinkTermination and microwaveCarrierTermination have not been included (Scott to talk to the YANG-doctors)
        *   Some range statements seem to be a problem for Yama
        *   …
     *   Work to be continued …
  *   The structure of the relationship between the different instances was discussed and resulted in a diagram/picture in the attached presentation.

We are now also approaching the vacation period in Europe and the participation might be low in the coming weeks.
We decided that meetings might be cancelled if the participation will be low. To be sorted out via mail in advance of the meetings.

A comment to Amy’s question below.

  *   The bandwidth should be possible to retrieve from the leaf “speed” in the referenced interface management module.

Regards
JonasA

From: Yemin (Amy) <[email-masked]<mailto:[email-masked]>>
Sent: den 2 juli 2020 11:01
To: Jonas Ahlberg <[email-masked]<mailto:[email-masked]>>; Jonas Ahlberg <jonas.ahlberg=[email-masked]<mailto:jonas.ahlberg=[email-masked]>>; CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: RE: Notes: Microwave Topology - 2020-07-01

Hi Jonas,

For microwave information such as frequency, it’s understandable to consider an alternative way to retrieved from interface model.
My question is about the bandwidth, which is an important feature of topology model, cannot be retrieved from the interface model.
If it is not within the consideration, the model somehow lose its significance .

BR,
Amy
发件人: Jonas Ahlberg [mailto:[email-masked]]
发送时间: 2020年7月2日 15:15
收件人: Yemin (Amy) <[email-masked]<mailto:[email-masked]>>; Jonas Ahlberg <jonas.ahlberg=[email-masked]<mailto:jonas.ahlberg=[email-masked]>>; CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
主题: RE: Notes: Microwave Topology - 2020-07-01

Hi Amy,

As mentioned in previous mails, this minimum example illustrates one extreme where bandwidth and other microwave specific information is supposed to be retrieved from the associated interface management information referenced using a xpath reference.
The other extreme, the maximum example, includes all that information directly in the topology model.
We will use these examples to better understand how they can support various microwave specific SDN use cases. If the best solution is one of the two extremes or somewhere in between remains to be understood.

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Yemin (Amy)
Sent: den 2 juli 2020 04:09
To: Jonas Ahlberg <jonas.ahlberg=[email-masked]<mailto:jonas.ahlberg=[email-masked]>>; CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] 答复: Notes: Microwave Topology - 2020-07-01

In this minimum approach, there’s no new definition for microwave specific topology. No maximum & current bandwidth is included.
As such, it shows how to use the exiting models for microwave, rather than new definition of mw-topology-model.

Amy
发件人: CCAMP [mailto:[email-masked]] 代表 Jonas Ahlberg
发送时间: 2020年7月1日 20:40
收件人: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
主题: [CCAMP] Notes: Microwave Topology - 2020-07-01

Hi all,

Participants:
Daniela Spreafico
Dragos Dosan
Scott Mansfield
Stephen Cheng
Xi Li
Jonas Ahlberg

The meeting walked through the example on a minimum approach from Stephen, as agreed in the previous meeting.
The example comprises two modules – microwave-topology & bandwidth-availability-topology. See attachments.

Next steps are:

  *   Description of an example of a context in which the microwave topology can be deployed (Stephen to provide information)
  *   Instantiation of the modules in the minimum approach, based on the use cases defined in an earlier step of this work (see pages 3 & 5 in the attached slide pack).
     *   Static text example (Jonas to propose)
     *   Dynamic based on a toolkit (Scott + Jonas)

Regards
JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 24 juni 2020 13:30
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-06-24

Hi all,

Participants:
Daniela Spreafico
Eduardo
Scott Mansfield
Stephen Cheng
Jonas Ahlberg

The discussion continued about the question
“Should the topology model include attributes to support the use cases on its own or should the topology model only include attributes not already covered by other existing models?

The conclusion from the meeting was to draft the two extremes.

  *   Minimum approach:
     *   A topology that only includes topology aspects of a microwave model
        *   Termination points and links on the radio link level
        *   Bandwidth, availability matrix, …
     *   A reference to corresponding RLT in the interface management model

  *   Maximum approach:
     *   A topology model including all attributes from the interface management model
        *   Update the interface management model and create groups that can be reused in other models
        *   Include the groups from the interface management model in the topology model
        *   Describe how the consistency should be maintained in case of a domain controller exposes both models for configuration

Stephen will try to create a draft for the minimum approach in time for next week’s meeting.

Regards
JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 8 juni 2020 16:52
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Notes: Microwave Topology - 2020-05-25

Hi all,

Participants:
Daniela Spreafico
Scott Mansfield
Stephen Cheng
Xi Li
Jonas Ahlberg

The discussion continued about the question
“Should the topology model include attributes to support the use cases on its own or should the topology model only include attributes not already covered by other existing models?”,
leading to a number of additional/sub-questions

  *   Which use-cases should be supported by the topology model itself?
  *   Can the support of a use-case rely on the assumption that other model are supported/implemented by the domain controller, e.g RFC 8561?
  *   If it is acceptable to duplicate attributes already supported in other models and include it in the topology model, could e.g. all attributes from RFCC 8561 be included in the topology model? If not, which attributes are not duplicated and why not?
  *   …

An idea mentioned was that the RFC 8561 could be updated so that all attributes were structured into groups, which then could be reused in full by the topology model. A mechanism for ensuring consistency between the two data sets if both models are implemented in a domain control would be needed. To be further discussed, as one of many suggestions.

The meeting decided to continue the discussion on a more detailed level, going back to look at the various ETSI use cases which was initiated a few weeks ago.

The meeting also agreed to change the meeting time to Wednesdays 12:00-13:00 CEST.

Regards
JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 25 maj 2020 13:50
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-05-25

Hi all,

Some short notes from the meeting today.

A general (key) question was raised based on the input & discussion about the 1st set of use cases in the ETSI use case document.

  *   Should the topology model include attributes to support the use cases on its own or should the topology model only include attributes not already covered by other existing models?
     *   E.g. should attributes already supported in the Interface Management Model for Microwave Radio Link, RFC 8561, also be supported by the topology model?
     *   Some use cases in the ETSI document are fairly generic and are related to alarm management, HW inventory, etc. which most likely should not be covered by a topology model.

The focus is now to resolve this question and come to a conclusion at the meeting next week.

Regards
JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 18 maj 2020 15:24
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-05-18

Hi all,

Participants:
Daniela Spreafico
Dragos Dosan
Scott Mansfield
Stephen Cheng
Xi Li
Jonas Ahlberg

The meeting agreed that we should try to progress more work outside the actual meetings and leave room at the meetings to draw conclusions and create consensus on way forward.

Next steps:

  *   Identify attributes required to be supported by the topology model.
     *   To be based on the use cases described in the ETSI use case document, “Applications and use cases of Software Defined Networking (SDN) as related to microwave and millimetre 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=7ab296ee-241254ab-7ab2d675-8692dc8284cb-66bec52e4f40c277&q=1&e=a7f64a2e-f213-4ec5-994a-c5fa2a108f98&u=https%3A%2F%2Fwww.etsi.org%2Fdeliver%2Fetsi_gr%2FmWT%2F001_099%2F016%2F01.01.01_60%2Fgr_mWT016v010101p.pdf>
     *   1 step is to review the use cases in chapter 5.1 “Radio link network segment in itself”
     *   To be reviewed at next meeting
     *   It would be appreciated if you could share your findings on the mailing list before the meeting.

  *   Stephen to resend a previously shared alternative illustrating some interesting concepts to be further discussed and agreed upon.

Next meeting:

  *   The current meeting time on Mondays might not be the best and we still expect feedback from the team about their preferences.
  *   Until then, we will keep the current time, which means that next meeting will be Monday, May 25, 11-12 CEST.

/JonasA

From: Jonas Ahlberg
Sent: den 11 maj 2020 12:23
To: Spreafico, Daniela (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; Xi Li <[email-masked]<mailto:[email-masked]>>; Stephen Cheng <[email-masked]<mailto:[email-masked]>>; Dragos-Iulian Dosan <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>; Yemin (Amy) <[email-masked]<mailto:[email-masked]>>; Scott Mansfield <[email-masked]<mailto:[email-masked]>>
Subject: Notes: Microwave Topology - 2020-05-11

Hi all,

We cancelled the meeting today since the participation was poor.
It’s fully understandable that there will be occasions where someone has a conflict, but lately the attendance in general has been a bit too low in order to progress the work in a good way. Especially since we want to anchor this broadly within the community.

Maybe, the time and day for the meeting is not the best.
Please suggest time slots that would work better (or equally good) for you, and then we can try to find a time that is better for all or at least most of us.

Regards
JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 6 maj 2020 08:02
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-05-04

Hi all,

Participants:
Dragos Dosan
Scott Mansfield
Stephen Cheng
Jonas Ahlberg

Meeting discussion:

  *   rlt-interface-path, using an yang:xpath1.0 expression, to provide a relation to the RLT interface in the interface management module for radio link
     *   What is the corresponding use cases explaining why this attribute/reference is required?
     *   The attribute is optional, but in order to use the xpath, the controller need to have implemented support for the interface management module, RFC 8561
     *   Xpath v.s. Mount point – Needs a clear justification why xpath is better
        *   Using a mount point means that you create a stand-alone & independent copy (a new separate instance) of the RLT interface, which means that you e.g. cannot make use of the interface to traverse up and down the higher & lower layer relationships.
        *   Using a xpath you just point to an already existing instantiation of the interface management model, and you have the possibility to use all the information & capabilities provided by that model.

  *   Which microwave related attributes to be included in the topology model
     *   Bandwidth: maximum & current
     *   Availability matrix
     *   Clarify the scope:
        *   Supporting path computation & setting up services across a microwave radio link
        *   Microwave specific tasks related to configuration/inventory/monitoring of radio links & carriers
     *   Other candidates – Need to be explained by clear use cases
        *   Frequency (Xi) – Carrier level
        *   Energy efficiency (Xi)
        *   Signal id (Dragos)
        *   Auto discovery (Dragos)
        *   Oper/Admin status - 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
     *   It was suggested that we could use the ETSI use case document, “Applications and use cases of Software Defined Networking (SDN) as related to microwave and millimetre wave transmission”, as a reference
        *   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=84c771d1-da67b394-84c7314a-8692dc8284cb-7f416687b9974074&q=1&e=a7f64a2e-f213-4ec5-994a-c5fa2a108f98&u=https%3A%2F%2Fwww.etsi.org%2Fdeliver%2Fetsi_gr%2FmWT%2F001_099%2F016%2F01.01.01_60%2Fgr_mWT016v010101p.pdf>
        *   It was agree that we should analyze what attributes the ETSI use cases would require on a topology level.

Next meeting the focus will be on use cases and associated attributes required in a topology model for microwave.

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 27 april 2020 14:40
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-04-27

Hi all,

Participants:
Daniela Spreafico
Dragos Dosan
Scott Mansfield
Xi Li
Jonas Ahlberg

Meeting discussion:

  *   Association with the RLT interfaces, rlt-interface-path, using an yang:xpath1.0 expression
     *   What is the corresponding use cases explaining why this attribute/reference is required?
     *   The attribute is optional, but in order to use the xpath, the controller need to have implemented support for the interface management module, RFC 8561
     *   Xpath v.s. Mount point – Needs a clear justification why xpath is better

  *   Which microwave related attributes to be included in the topology model
     *   Bandwidth: maximum & current
     *   Availability matrix
     *   Clarify the scope:
        *   Supporting path computation & setting up services across a microwave radio link
        *   Microwave specific tasks related to configuration/monitoring of radio links & carriers
     *   Other candidates – Need to be explained by clear use cases
        *   Frequency (Xi)
        *   Energy efficiency (Xi)
        *   Signal id (Dragos)
        *   Oper/Admin status - 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

Next meeting the focus will be on use cases and associated attributes required in a topology model for microwave.

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 20 april 2020 12:15
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-04-20

Hi all,

Participants:
Scott Mansfield
Stephen Cheng
Jonas Ahlberg

Due to poor attendance we decided to cancel the meeting this time.
Instead, we will hopefully meet again next week, Monday  April 27, 12.00-13:00 (CEST)

Regards
JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 6 april 2020 13:49
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-04-06

Hi all,

Participants:
Daniela Spreafico
Scott Mansfield
Stephen Cheng
Jonas Ahlberg

Please remember that next Monday is Easter Monday and our next meeting is April 20

Meeting discussion:

  *   Walk through of the YANG model sent out by Stephen. See attachment.
     *   The key concept discussed was the association with the RLT interfaces, rlt-interface-path, using an yang:xpath1.0 expression.
     *   The meeting agreed with the suggested approach.
        *   Both the rlt-interface-path and the microwave specific attributes in the topology model can exist at the same time.
        *   The duplicated information in the topology model should always be derived from the interface model, if rlt-interface-path exists
        *   To be decided upon at out next meeting to allow for the rest of the team to review
     *   Other comments:
        *   ct-interface-path is actually not required since they can be reached via the rlt-interface-path and the attribute lower-layer-if
        *   How should a situation be handled when 2 devices provide inconsistent link information, e.g. different bandwidth info?
  *   Next step:
     *   Focus on which microwave related attributes to be included in the topology model
        *   Is there any radio link or carrier attributes required in the topology that are not already included in the interface management model?
        *   See also open topics below

Summary of conclusion:

  *   Generic attributes
     *   A matrix of availability and associated bandwidth information to be added on the link level
  *   Microwave radio link attributes
     *   Maximum bandwidth is required - equal to capacity that can be provided when the highest modulation & coding is used
     *   Current bandwidth is required - equal to capacity that is provided by modulation & coding the system is currently operating in
  *   Not yet decided
     *   Xpath as a reference to RLT interfaces. Pending review & comments from the rest of the team
     *   Any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant?
        *   Any use cases or examples on when any of the other bandwidth attributes are relevant/required for microwave radio link?
        *   If none, then we can conclude that it is only a single bandwidth attribute that is relevant from te-topology.
        *   Amy to explain if/how it is used in the ETSI plug-test - To be confirmed after that
     *   Augmentation of network-topology or te-topology?

Other open topics:

  *   Frequency/carrier info
     *   Use case: TBD
     *   Treat this information as specific to microwave radio

  *   Provider-id/client-id/te-topology-id
     *   Use case TBD

  *   Carrier id/label
     *   Use case: TBD
     *   Relation to the interface id/label

  *   Admin & Oper Status in te-topology
     *   Refers to the status of a te-link
     *   Use case: TBD
     *   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.

  *   Bandwidth Utilization – PM data – How to capture this in a model? Already supported in other models?
     *   Bandwidth utilization is a dynamic performance counter and not the same as reserved/un-reserved bandwidth
     *   Use cases?
     *   Relevant for a topology model or the interface model?

  *   From previous meetings/mails
     *   Co-existence with the modelling of other L1 technologies

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 31 mars 2020 08:23
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-03-30

Hi all,

Participants:
Daniela Spreafico
Dragos Dosan
Italo Busi
Scott Mansfield
Stephen Cheng
Jonas Ahlberg

Meeting discussion:

  *   Alignment of RFC 8561 Microwave Interface YANG with the topology model - node-instance-identifier and duplication of information in multiple models (interface & topology)
     *   Information in multiple models (alignment issue)
     *   Use node-instance-identifier (or alternative approach) to reference another model where the info resides
        *   Stephen to write an example of what it could look like – Yang Model
        *   If reference is not available – Allow for population of the data in the topology model itself
        *   Can be made conditional depending if the interface model exists or not
        *   Would have been simplified if the interface management model had been structured with groups
        *   The complete interface management model could be referenced
     *   A description of the associated behavior in the different data stores – both read-only & write
        *   Running/operational datastores
        *   Alignment of duplicated information???
     *   Is there any radio link or carrier attributes required in the topology that are not already included in the interface management model?
     *   Discussion to be continued based on the proposal from Stephen.

  *   Admin & Oper Status in te-topology
     *   Refers to the status of a te-link
     *   Use case: TBD
     *   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.
     *   Discussion to be continued.

Summary of conclusion:

  *   Generic attributes
     *   A matrix of availability and associated bandwidth information to be added on the link level
  *   Microwave radio link attributes
     *   Maximum bandwidth is required - equal to capacity that can be provided when the highest modulation & coding is used
     *   Current bandwidth is required - equal to capacity that is provided by modulation & coding the system is currently operating in
  *   Not yet decided
     *   Any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant?
        *   Any use cases or examples on when any of the other bandwidth attributes are relevant/required for microwave radio link?
        *   If none, then we can conclude that it is only a single bandwidth attribute that is relevant from te-topology.
        *   Amy to explain if/how it is used in the ETSI plug-test - To be confirmed after that
     *   Augmentation of network-topology or te-topology?

Other open topics:

  *   Bandwidth Utilization – PM data – How to capture this in a model? Already supported in other models?
     *   Bandwidth utilization is a dynamic performance counter and not the same as reserved/un-reserved bandwidth
     *   Use cases?
     *   Relevant for a topology model or the interface model?

  *   Frequency/carrier info
     *   Use case: TBD
     *   Treat this information as specific to microwave radio

  *   Provider-id/client-id/te-topology-id
     *   Use case TBD

  *   Carrier id/label
     *   Use case: TBD
     *   Relation to the interface id/label

  *   From previous meetings/mails
     *   Co-existence with the modelling of other L1 technologies

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 23 mars 2020 15:38
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-03-23

Hi all,

Participants:
Daniela Spreafico
Dragos Dosan
Scott Mansfield
Xi Li
Jonas Ahlberg

Meeting discussion:

  *   What bandwidth information should be used for the bandwidth attributes for a link?
     *   It was decided that the maximum bandwidth in perfect conditions (max-link-bandwidth, Nominal bandwidth, …) and current bandwidth (state) should be modelled.
        *   Assume a link with dynamic modulation & coding:
           *   Max bandwidth is equal to capacity that can be provided when the highest modulation & coding is used (based on configuration, not equipment capability)
           *   Current bandwidth is equal to capacity that is provided by modulation & coding the system is currently operating in
     *   It was also decided that it is enough to model this for the link level
     *   Reserved & un-reserved bandwidth is not relevant modelled for a microwave radio links & carriers
        *   Is the concepts relevant for anything else than a traffic engineered layer?
        *   Is maximum bandwidth reduced by the bandwidth allocated to TDM a relevant case?
           *   Why treat TDM different from other type of higher layer services/topologies?
        *   Agreement that reserved and un-reserved bandwidth are not relevant for a microwave radio link layer

  *   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 to model for a radio link?
     *   Any use cases or examples on when any of the other bandwidth attributes are relevant/required for microwave radio link?
     *   If none, then we can conclude that it is only a single bandwidth attribute that is relevant from te-topology.
     *   Amy to explain if/how it is used in the ETSI plug-test - To be confirmed after that

Summary of conclusion:

  *   Generic attributes
     *   A matrix of availability and associated bandwidth information to be added on the link level
  *   Microwave radio link attributes
     *   Maximum bandwidth is required - equal to capacity that can be provided when the highest modulation & coding is used
     *   Current bandwidth is required - equal to capacity that is provided by modulation & coding the system is currently operating in
  *   Not yet decided
     *   Any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant?
     *   Augmentation of network-topology or te-topology?

Other open topics:

  *   Bandwidth Utilization – PM data – How to capture this in a model? Already supported in other models?
     *   Bandwidth utilization is a dynamic performance counter and not the same as reserved/un-reserved bandwidth
     *   Use cases?
     *   Relevant for a topology model or the interface model?

  *   Frequency/carrier info
     *   Use case: TBD
     *   Treat this information as specific to microwave radio

  *   Admin & Oper Status
     *   Use case: TBD

  *   Provider-id/client-id/te-topology-id
     *   Use case TBD

  *   Carrier id/label
     *   Use case: TBD
     *   Relation to the interface id/label

  *   From previous meetings/mails
     *   Co-existence with the modelling of other L1 technologies
     *   Alignment of RFC 8561 Microwave Interface YANG with the topology model - node-instance-identifier
     *   Duplication of information in multiple models (interface & topology)

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 16 mars 2020 12:00
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-03-16

Hi all,

Participants:
Amy Ye
Daniela Spreafico
Scott Mansfield
Stephen Cheng
Jonas Ahlberg

Availability / Bandwidth information
Use case: Information that should be possible to consider in the process of selecting a path/link when setting up connectivity or a service

  *   What information to model?
     *   It was decided to model a matrix of availability and associated bandwidth on the link level (radio link)
     *   It was decided not to model this on the channel/carrier level, unless a use case is identified/defined that that requires this information.
        *   Link level is enough for the service use case
        *   Carrier level is not enough for “calculating” the resulting availability on link level

  *   How to make it available to higher layers?
     *   It was decided to make it generic and create a separate module that can be reused by any technology in the MW-draft
     *   Is it OK that the model augments network-topology???
        *   Availability/bandwidth information is relevant for a microwave link in general, not only when setting of te-paths, e.g. when setting up L2 bridged services, documentation of planning/config, … - Confirmed
        *   Is the scope of te-topology module to support all types of topologies or is it limited to te-topologies only? – To be confirmed once we have a complete picture of what needs to be modelled for microwave.

  *   What bandwidth information should be used for the bandwidth attributes for a link?
     *   It was decided that the maximum bandwidth in perfect conditions (max-link-bandwidth, Nominal bandwidth, …) and current bandwidth (state) should be modelled.
        *   Assume a link with dynamic modulation & coding:
           *   Max bandwidth is equal to capacity that can be provided when the highest modulation & coding is used (based on configuration, not equipment capability)
           *   Current bandwidth is equal to capacity that is provided by modulation & coding the system is currently operating in
     *   It was also decided that it is enough to model this for the link level
     *   Reserved & un-reserved bandwidth is not relevant modelled for a microwave radio links & carriers????
        *   Is the concepts relevant for anything else than a traffic engineered layer?
        *   Is maximum bandwidth reduced by the bandwidth allocated to TDM a relevant case?
           *   Why treat TDM different from other type of higher layer services/topologies?
        *   Bandwidth utilization is a dynamic performance counter and not the same as reserved/un-reserved bandwidth
        *   To be confirmed at next meeting

  *   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 to model for a radio link?
     *   Any use cases or examples on when any of the other bandwidth attributes are relevant/required for microwave radio link?
     *   If none, then we can conclude that it is only a single bandwidth attribute that is relevant from te-topology.
     *   To be confirmed at next meeting

  *   Other open topics:
     *   Bandwidth Utilization – PM data – How to capture this in a model? Already supported in other models?
     *   How this information relates to existing leafs in the te-topology model remains to be understood.

Frequency/carrier info

  *   Use case: TBD
  *   Treat this information as specific to microwave radio

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 5 mars 2020 13:10
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-03-05

Hi all,

Some notes from the CCAMP Microwave Topology meeting this week.
From next week we will run the meetings on Mondays, the same time, starting March 9.

Participants:
Dragos Dosan
Daniela Spreafico
Scott Mansfield
Stephen Cheng
Xi Li
Jonas Ahlberg

Availability / Bandwidth information
Use case: Information that should be possible to consider in the process of selecting a path/link when setting up connectivity or a service

  *   What information to model?
     *   It was decided to model a matrix of availability and associated bandwidth on the link level (radio link)
     *   It was decided not to model this on the channel/carrier level, unless a use case is identified/defined that that requires this information.
        *   Link level is enough for the service use case
        *   Carrier level is not enough for “calculating” the resulting availability on link level

  *   How to make it available to higher layers?
     *   It was decided to make it generic and create a separate module that can be reused by any technology in the MW-draft
     *   Is it OK that the model augments network-topology??? – To be confirmed at next meeting
        *   Availability/bandwidth information is relevant for a microwave link in general, not only when setting of te-paths (i.e. te-topology), e.g. when setting up TDM, documentation of planning/config, …
        *   Is there any drawbacks with augmenting network topology

  *   What bandwidth information should be used for the bandwidth attributes for a link?
     *   It was decided that the maximum bandwidth in perfect conditions (max-link-bandwidth, Nominal bandwidth, …) and current bandwidth (state) should be modelled.
        *   Assume a link with dynamic modulation & coding:
           *   Max bandwidth is equal to capacity that can be provided when the highest modulation & coding is used (based on configuration, not equipment capability)
           *   Current bandwidth is equal to capacity that is provided by modulation & coding the system is currently operating in
     *   It was also decided that it is enough to model this for the link level
     *   Reserved & un-reserved bandwidth is not relevant modelled for a microwave radio link????
        *   To be confirmed at next meeting

     *   Other open topics:
        *   Utilization – PM data
        *   How this information relates to existing leafs in the te-topology model remains to be understood.
        *   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 to model for a radio link?

Frequency/carrier info

  *   Use case: TBD
  *   Treat this information as specific to microwave radio

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 3 mars 2020 08:50
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-02-27

Availability / Bandwidth information
Use case: Information that should be possible to consider in the process of selecting a path/link when setting up connectivity or a service

  *   What information to model?
     *   It was decided to model a matrix of availability and associated bandwidth on the link level (radio link)
     *   It was decided not to model this on the channel/carrier level, unless a use case is identified/defined that that requires this information.
        *   Link level is enough for the service use case
        *   Carrier level is not enough for “calculating” the resulting availability on link level

  *   How to make it available to higher layers?
     *   It was decided to make it generic and create a separate module that can be reused by any technology in the MW-draft
     *   If the model should augment te-topology or network-topology remains to be agreed upon
        *   Is this information only relevant for te-topologies or not? Might also be useful for L2 topologies (not IP/MPLS TE)
        *   Is availability/bandwidth relevant to model in network-topology or only on te-topology?
        *   Up & down sides of the two options need to be understood - …
        *   It is related to how we decide to model bandwidth in general for a microwave radio link

  *   What bandwidth information should be used for the bandwidth attributes for a link?
     *   It was decided that the maximum bandwidth in perfect conditions (max-link-bandwidth, Nominal bandwidth, …) and current bandwidth (state) should be modelled.
     *   It was also decided that it is enough to model this for the link level
     *   How this information relates to existing leafs in the te-topology model remains to be understood.
     *   Other open topics:
        *   Is reserved & un-reserved bandwidth something that should/can be modelled for a microwave radio link?
        *   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 to model for a radio link?

Frequency/carrier info

  *   Use case: TBD
  *   Treat this information as specific to microwave radio

It was also decided to change the meeting time to Mondays, the same time from next week (March 9) and onwards.

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 20 februari 2020 12:16
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-02-20

Hi all,

These are the notes for CCAMP Microwave Topology meeting:

Participants:
Daniela Spreafico
Scott Mansfield
Xi Li
Dragos Dosan
Amy (Min Ye)
Jonas Ahlberg

It was decided to keep the current day & time for the future meetings.

Availability / Bandwidth information

  *   Use case: Information that should be possible to consider in the process of selecting a path/link when setting up connectivity or a service
  *   What information to model?
     *   There is a need to model a matrix of availability and associated bandwidth on link level
     *   There still might be a value of model it also on a carrier level
  *   How to make it available to higher layers?
     *   A few options:
        *   Keep it specific to microwave and leave the question for future discussions/drafts
        *   Make it generic
           *   A separate draft
           *   A separate module in the MW-draft
  *   What bandwidth information should be used for the bandwidth attributes for a link?
     *   Current bandwidth (state) – On link and carrier levels
     *   Nominal bandwidth (config)
        *   Maximum in perfect conditions
  *   The above to be confirmed / agreed by next meeting (Feb 27)

  *   Other topics:
     *   Reserved & un-reserved bandwidth
        *   Is this something that should/can be modelled for a microwave radio link?
     *   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 to model for a radio link?
  *   The above to be discussed at our next meeting and/or in mails before that.

Frequency/carrier info

  *   Use case: TBD
  *   Treat this information as specific to microwave radio

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Dragos-Iulian Dosan
Sent: den 13 februari 2020 16:43
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-02-13

Hi all,

These are the notes for CCAMP Microwave Topology meeting:

Participants:
Daniela Spreafico
Italo Busi
Scott Mansfield
Xi Li
Dragos Dosan

Discussed topics:

  1.  Change meeting day
Please reply if someone cannot attend to this meeting on Thursdays. Changing the days is doable, but not the hour since currently this meeting time is set for 05:00 for Scott and 23:00 for Stephen.

  1.  “Link-availability” for mw-topology
Starting from Jonas’s example [see attached JSON example], I formulated another example where the ‘link-availability’ I a property only o the Radio Link, there is no need for “availability” for channels [see attached .pptx].
I discussed with my colleagues and also friends working for various telecom companies, and the main used tool for radio planning is called Pathloss (http://www.pathloss.com/<https://protect2.fireeye.com/v1/url?k=0f162ba0-539ff18c-0f166b3b-0cc47ad93da2-3cf9d97c48ba66ed&q=1&e=f2199b22-bae2-4307-93a2-368cf41f44b5&u=http%3A%2F%2Fwww.pathloss.com%2F>). This application is delivering the “availabilities” per ‘Link’, regardless of the ‘link’ type [1+0, 1+1HSB, 1+1SD, MIMO, XPIC etc…]. Actually things are a bit more complicated, but bottom of line is the fact that the “link-availability” and “channel-bandwidth” is give per overall Link.

Other personal observations:

  1.  Propose to change the “mw-channels” with “mw-carriers” [aren’t they the same thing?] -> alignment with rfc8561.
  2.  The way the XPIC link is modeled in rfc8561 [one link with 2 carriers] is making things complicated when modeling this kind of link in upper layer models: actually from traffic point-of-view, the XPIC represents 2 parallel links using same medium.

Looking forward for your comments and ideas.

Regards,
Dragos D.

From: Jonas Ahlberg <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 6, 2020 1:11 PM
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-02-06

Hi all,

The meeting continued the discussion about the different options for how to model a microwave topology, but did not reach a conclusion since the participation was too low.

There was also a discussion about how to make the availability information for a channel available to higher layers.
An example is attached, showing an instantiation of a model were a generic link attribute has been added to the network-topology model.

The example also shows a situation with two availability levels and associated bandwidth for each channel, which also have been aggregated to the link level.
That raises a new question. What availability level should be the basis for the bandwidth attribute for a link.
Let’s discuss over mail and at our next weekly meeting.

I will be on vacation next week and will not call in, but the webex meeting will be open for the rest of you.

Regards
JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 3 februari 2020 13:29
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-01-30

Hi all,

The meeting agreed with the suggested way forward as proposed in the summary below, “Notes: Microwave Topology - 2020-01-23”.

The 1st step is to create example instantiations in JSON for the three different options.
We agreed to use the configuration in Appendix A.2. in the current draft, draft-ye-ccamp-mw-topo-yang.

Attached are:

  *   A powerpoint slide with a picture of the configuration, “IETF Topology - JSON example”
  *   A draft of an instantiation based on te-topology, “JSON example - te-topology”
  *   A draft of an instantiation based on network-topology, “JSON example - network-topology”

We will continue to evolve these drafts and use them as a basis for the decision on model approach as described in step 2 in the summary below.

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 23 januari 2020 16:58
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-01-23

Hi all,

This is an attempt to create a high level summary of the discussions/conclusions about the microwave topology model that hopefully can help us taking a step forward.
What are the key conclusions, which are the main questions that remain to be resolved and what are the options for modelling a microwave radio link layer.

There is a difference between microwave and most other technologies.

  *   Microwave is a link-by-link technology, not a network technology
  *   It is not possible to switch/route/cross-connect traffic on the microwave radio link layer. It is always done on higher layers, e.g. on Ethernet or TDM layers.
  *   Therefore, concepts such as “Node Connectivity Matrix” and “Local Link Connectivity” are not applicable

Two use cases have been analyzed:

  *   Provisioning of bridged L2 services (E-LINE) across an Ethernet topology
  *   Provisioning of L3VPN services across an IP/MPLS (TE) infrastructure
The main conclusions from that analysis are:

  *   The microwave radio link information is not used directly in the process of selecting the path/resources to be used for the service. Instead, the process uses information in the Ethernet and LSP layers respectively.
  *   How the microwave radio link information can be made available to those higher layers remains to be understood and clarified
     *   If there is a corresponding attribute in the higher layer topology model, then the PNC can update that attribute based on information in the supporting microwave radio link layer (e.g. bandwidth). If there is no corresponding attribute, then changes have to be done to the higher layer models and/or the functionality of the PCE (e.g. availability).
     *   The mapping/aggregation of microwave radio link information to higher layers requires intelligence (SW-code) in the PNC and cannot be derived from the model. An example is the calculation of the resulting availability on a higher layer link that might be composed of a number of different underlying microwave radio links, each based on multiple channels in protected and/or bonded configurations.

There are a few options for how to model microwave radio links.

  *   Augment ietf-te-topology (currently used in draft-ietf-ccamp-mw-topo-yang)
     *   Only a small subset of the complete model is relevant
     *   Focus should be on clearly describing which parts are relevant and which parts are not applicable, using textual descriptions and examples of instantiations.
  *   Augment ietf-network-topology
     *   Extending a basic model
     *   Attributes that already exist in ietf-te-topology might need to be added as microwave specific extensions.
  *   Multiple augmentation ietf-network-topology + ietf-te-topology
     *   Augmenting network-topology with microwave specific extensions
     *   Use multiple augmentation and include te-topology when required

Some questions related to the attributes to be included

  *   In the te-topology model there are already generic attributes for max-link-bandwidth and unreserved-bandwidth. Why do we need to add microwave specific attributes for bandwidth and unreserved bandwidth? Why can’t the generic attributes be used also for microwave?
  *   Is there a way for a PNC to keep track of the unreserved bandwidth of a microwave radio link when the allocation is done on higher (possibly multiple) layers. What does it really represent?
  *   In RFC 8330, availability level and associated bandwidth is introduced as a generic (technology independent) concept (for OSPF-TE).
Should we follow that approach of making it generic also in the modelling of topologies or is there a reason for making it microwave specific?
  *   To what extent should the topology model align with RFC 8561. Can we assume that a PNC implements both a topology model and RFC 8561, or should the topology model provide an alternative to RFC 8561 for configuration of the interfaces/termination points?
  *   There is a need to illustrate how the rw-leafs for a channel is supposed to be used for configuration/re-configuration.

Suggested way forward:

  1.  Extend the example in draft-ietf-ccamp-mw-topo-yang to a complete instantiation of all relevant parts of the te-topology

Create corresponding examples for the other two options based on ietf-network-topology & multiple augmentation

  1.  Evaluate the options and decide which one to use

  1.  Define and justify which microwave specific attributes/leafs the model should be extended with

/JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 9 januari 2020 16:02
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Microwave Topology - 2020-01-09

Hi all,

Notes from today’s meeting.
This is based on my own understanding/interpretation of our discussion. Please add any missing or incorrect information.

Use case 2: Provisioning of bridged Ethernet services

  *   Based on ETSI microwave plug-test use cases
  *   In the plug-test, the underlay concept is used to describe the relationship between the Ethernet layer and the microwave layer, whereas the supporting link is the approach used in the draft-ye-ccamp-mw-topo-yang.
     *   There is a need to clarify which approach is the correct/best
  *   Path computation is performed on the Ethernet layer and uses only information provided by that layer
  *   The microwave layer need to provide information that might be of interest for path computation, such as bandwidth and availability.
  *   How that microwave information can be made available to the Ethernet layer (and thereby the PCE) remains to be understood
     *   If there is a corresponding attribute in the Ethernet topology, then the domain controller can update that attribute based on information in the supporting microwave layer
     *   If there is no corresponding attribute in the Ethernet topology, then changes have to be done to the Ethernet topology model and/or the functionality of the PCE. But this is outside the scope of this work.

There was a discussion about possible future extensions:

  *   Point-to-multipoint implementations
     *   Is there any implementations within the industry today that we can refer to?
     *   Is the connectivity managed on the radio link layer or on higher layers, e.g. on the Ethernet layers as in implementations 10-15 years ago?
  *   IAB – Integrated Access Backhaul
     *   A new protocol (layer?), BAP, is introduced to manage the connectivity in a multi-hop IAB network.
     *   Does this really change the previous assumption that microwave is only a link-by-link topology and not a  network topology?
     *   Is IAB within the scope of our work?

Next step
A suggestion:

-          I think there are communalities in the findings from the two use cases. Let’s summarize them in a good way.

-          Based on that, let’s start to draw conclusions and define requirements for what a microwave topology model need to support.

Regards
JonasA

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jonas Ahlberg
Sent: den 19 december 2019 13:16
To: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>; ccamp <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] Microwave Topology - 2019-12-19

Hi all,

Some notes from the meeting today.

We had a short discussion about the IP/MPLS (TE) L3VPN use case. The detailed information provided by Stephen need to be further explained/discussed at our next meeting.
We agreed with the conclusion that TE information in L1 microwave topology is not necessary for the proper functioning of a PCE, but we also need to consider other aspects before we decide how to proceed.

  *   We need to understand and draw conclusions also from the remaining two use cases
  *   Other drafts augmenting te-topology (e.g. MPLS-TP, OTN and WSON) are network technologies in that sense that paths/tunnels can be created using links and connectivity matrices from within that single te-topology. Microwave is not a network topology in that sense. It is only a “link-by-link topology” since paths/tunnels can only be created on higher layer topologies, e.g. TDM and Ethernet. How should this affect the choice of basis for a microwave topology model?
  *   How to take care of future use cases that might require te-information? Does it really impact the choice today?
  *   …

Next meeting is planned for Thursday January 9, 11-12 CET.

Merry Christmas & Happy New Year.

/JonasA

-----Original Appointment-----
From: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>
Sent: den 3 oktober 2019 12:00
To: CCAMP Working Group; ccamp
Subject: [CCAMP] Webex meeting changed: Microwave topology
When: Occurs every torsdag effective 2019-11-14 until 2020-06-04 from 05:00 to 06:00 (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna.
Where: https://ietf.webex.com/ietf

CCAMP Working Group changed the Webex meeting information.

When it's time, join the Webex meeting here.

Meeting number (access code): 647 343 270

Meeting password: D7dhCJpZ

Occurs every Thursday effective Thursday, November 14, 2019 until Thursday, June 4, 2020 from 5:00 AM to 6:00 AM, (UTC-05:00) Eastern Time (US & Canada)
5:00 am  |  (UTC-05:00) Eastern Time (US & Canada)  |  1 hr

Join meeting<https://ietf.webex.com/ietf/j.php?MTID=ma65a6a5186962890ec535e711ec3d3f9>

Join by phone
Tap to call in from a mobile device (attendees only)
1-650-479-3208<tel:%2B1-650-479-3208,,*01*647343270%23%23*01*> Call-in toll number (US/Canada)
1-877-668-4493<tel:1-877-668-4493,,*01*647343270%23%23*01*> Call-in toll free number (US/Canada)
Global call-in numbers<https://ietf.webex.com/ietf/globalcallin.php?MTID=m57c83575d64804b110f94f798d438720>  |  Toll-free calling restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf>

Need help? Go to http://help.webex.com

This email message and any attachments are intended solely for the use of the addressees hereof.
This message and any attachments may contain information that is confidential, privileged and exempt from disclosure under applicable law.
If you are not the intended recipient of this message, you are prohibited from reading, disclosing, reproducing, distributing, disseminating or otherwise using this transmission.
If you have received this message in error, please promptly notify the sender at Ceragon by reply E-mail and immediately delete this message from your system.