Subject: Re: [CCAMP] Webex meeting invitation: Microwave topology

From: Jonas Ahlberg <[email-masked]>
Date: Thu, 12 Sep 2019 12:17:13 +0000

Hi all,
Some short notes from the meeting today.

  *   Stephen went through and explained the purpose of the changes in his proposal. It was understood by the meeting and will be considered going forward.

  *   The meeting agreed that there is a need to understand & describe which attributes/concepts from te-topology are applicable to microwave radio link.
Italo & Amy to prepare a list of attributes to be reviewed/discussed at our next meeting (or the meeting after that).
The meeting also highlighted the importance of connecting this to the use cases intended to be supported by the model.
Xi will send out the latest information about the use cases discussed in earlier meetings.

  *   Based on an assumption that only a limited number of attributes/concepts from te-topology are applicable to microwave radio link, the meeting discussed another possible approach for how to structure the microwave topology in two different modules. One augmenting network-topology and another augmenting te-topology, similar to the approach used for L3 topology. An example of such an approach can be found in
RFC 8346 https://datatracker.ietf.org/doc/rfc8346/?include_text=1 and
draft-ietf-teas-yang-l3-te-topo-05 https://datatracker.ietf.org/doc/draft-ietf-teas-yang-l3-te-topo/?include_text=1

Regards
JonasA

-----Original Appointment-----
From: CCAMP Working Group <[email-masked]>
Sent: den 20 augusti 2019 07:46
To: CCAMP Working Group; ccamp
Subject: [CCAMP] Webex meeting invitation: Microwave topology
When: den 12 september 2019 07:00-08:00 America/New_York.
Where: https://ietf.webex.com/ietf

CCAMP Working Group invites you to join this Webex meeting.

Meeting number (access code): 647 343 270

Meeting password: D7dhCJpZ

Occurs every Thursday effective Thursday, August 22, 2019 until Thursday, October 24, 2019 from 7:00 AM to 8:00 AM, (UTC-05:00) Eastern Time (US & Canada)
7:00 am  |  (UTC-05:00) Eastern Time (US & Canada)  |  1 hr

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

---

From: Jonas Ahlberg <[email-masked]>
Date: Thu, 19 Sep 2019 14:00:44 +0000

Hi all,
Some short notes from the meeting September 19th.
Participants: Daniela Spreafico, Stephen Cheng, Dragos D, Jonas Ahlberg

  *   Applicability of ietf-te-topology for microwave radio link
The meeting didn’t see any obvious use cases or attributes for microwave radio link that would require a microwave radio link topology to be based on ietf-te-topology. This needs to be further analyzed and fully understood before a decision on way forward can be made. Next step is to review/discuss a list of applicable attributes from ietf-te-topology to be proposed by Amy and Italo.

  *   New presence container for identification of microwave specific termination points and links.
The meeting understood the purpose of the proposal from Stephen but need more time to consider the actual YANG fragments to be changed. To be further discussed at next meeting.

  *   Moving the replacement of interface-root
Stephen explained the reason for suggesting an update of how to make a reference to radio-link-terminal and carrier-termination interfaces. To be further discussed at next meeting.

  *   Simplified topology model
The removal of the dependency to te-topology and the other suggested changes have been compiled into a new simplified model presented by Stephen. A decision about if/how to make use of that proposal is pending the outcome of the other topics above, but it can still be used to illustrate the alternative approaches under discussion.

Regards
Jonas A

-----Original Appointment-----
From: CCAMP Working Group <[email-masked]>
Sent: den 20 augusti 2019 07:46
To: CCAMP Working Group; ccamp
Subject: [CCAMP] Webex meeting invitation: Microwave topology
When: den 19 september 2019 07:00-08:00 America/New_York.
Where: https://ietf.webex.com/ietf

Join by phone

---

From: "Yemin (Amy)" <[email-masked]>
Date: Tue, 24 Sep 2019 16:28:27 +0000

Sorry to catch up the discussion late.

Let's take the example from the ETSI 1st mWT plugtest, see attached document.
There were 7 vendors joined in 1st ETSI plugtest, which are the major suppliers in the market.
Implementation based on te-topo already shows good example of running code.

The current mw-topo model doesn’t use the all concepts from te-topo model, e.g., te-tunnel and connectivity matrix, it do use an important feature underlay topo from the te-topo. The underlay allows the links in the eth topo to be associated with mw-link.
If the mw-topo is based on ietf-network-topo, the underlay relationship between eth-topo and mw-topo is missing.
A mw controller normally doesn’t mange on mw technology only, it also need to manage other te technologies. Having a common model between those technologies would simplify the implementation.

There’re many data node definition in the te-topo which are also useful for mw domain.
ietf-te-topology:provider-id & ietf-te-topology:client-id & ietf-te-topology:te-topology-id: These attributes are useful in hierarchical domain controllers architecture to understand which controller (provider-id) is exposing the topology to which controller (client-id)
ietf-te-topology:name: The name attributes are useul to provide user-friendly labels for the operator to use
ietf-te-topology:te-node-id: The te-node-id and te-tp-id are used by the ETH topology to reference the underlying MW link supporting a logical ETH link
ietf-te-topology:oper-status: Managing the administrative and operational status of MW links is a useful feature

A model defined today should have the capability to extend for future use.
With microwave technology evolution, use case such as protection will be required, where SRLG from te-topo could be used; PtMP microwave will be introduced apart from current PtP microwave, where te-tunnel could be introduced.  te-topo provides a good basis for future extension.

BR,
Amy
________________________________
发件人: CCAMP [[email-masked]] 代表 Jonas Ahlberg [jonas.ahlberg=[email-masked]]
发送时间: 2019年9月19日 22:00
收件人: CCAMP Working Group; ccamp
主题: Re: [CCAMP] Webex meeting invitation: Microwave topology

Hi all,

Regards
Jonas A

-----Original Appointment-----
From: CCAMP Working Group <[email-masked]>
Sent: den 20 augusti 2019 07:46
To: CCAMP Working Group; ccamp
Subject: [CCAMP] Webex meeting invitation: Microwave topology
When: den 19 september 2019 07:00-08:00 America/New_York.
Where: https://ietf.webex.com/ietf

Join by phone

---

From: Stephen Cheng <[email-masked]>
Date: Thu, 26 Sep 2019 05:04:42 +0000

Amy, please see below for my opinion.

From: CCAMP <[email-masked]> On Behalf Of Yemin (Amy)
Sent: 2019年9月25日 4:28 AM
To: Jonas Ahlberg <jonas.ahlberg=[email-masked]>; CCAMP Working Group <[email-masked]>; ccamp <[email-masked]>
Subject: EXTERNAL: Re: [CCAMP] Webex meeting invitation: Microwave topology

Let's take the example from the ETSI 1st mWT plugtest, see attached document.
There were 7 vendors joined in 1st ETSI plugtest, which are the major suppliers in the market.
Implementation based on te-topo already shows good example of running code.
[SC] The ETSI 1st mWT plug-test specify the following microwave topology sub-tree.
I think the fragment above from mWT_PlugTest1_TestPlan_v1.0.docx perfectly illustrates the point that the core constructs of te-topology are not required in microwave-topology.

  1.  TTP/Tunnel/LLCL/connectivity matrix/te-link are not used in 1st ETSI mWT plug-test

     *   The portion of TE-link used is actually primarily defined in microwave-topology and could have easily been moved to the ietf-network-topology:link

  1.  The subset of te-topology that are implemented in 1st ETSI mWT plug-test has little to do with traffic engineering, and constitute a *tiny* portion of ietf-te-topology YANG

     *   Administration and operation status are standard constructs that can be easily replicable/augmented onto ietf-network.
     *   Provider-id/client-id/te-topology-id are easily replicable/augmented onto ietf-network
As such I disagree that the ETSI 1st mWT plug-test demonstrates good example of running code of ietf-te-topology portion of microwave-topology,

The current mw-topo model doesn’t use the all concepts from te-topo model, e.g., te-tunnel and connectivity matrix, it do use an important feature underlay topo from the te-topo. The underlay allows the links in the eth topo to be associated with mw-link.
If the mw-topo is based on ietf-network-topo, the underlay relationship between eth-topo and mw-topo is missing.
[SC]
1. eth-topo is defined by draft-zheng-ccamp-client-topo-yang-06. It is an individual I-D far from acceptance by the community. As such it is in my opinion a folly to design ietf-microwave-topology around an immature individual I-D that is far from last-call.
2. It is entirely possible for a upper layer topology that augments ietf-te-topology (such as eth-topo in your example) to refer to elements in a lower layer topology that is not based on ietf-te-topology. In fact the supporting link and supporting node concept would still work.
3. I believe you have misunderstood the concept of underlay in ietf-te-topology. The way I read it is that underlay is primarily for composing, and not for layering.

[SC]

  1.  I disagree that all mw controller needs traffic engineering; in fact for most of the use cases I would argue that traffic engineering at L1 microwave topology are non-applicable.
  2.  It is generally not a good idea to create a bulky kitchen-sink standard that is difficult to implement, just because there *may be* some vague/conjectural use cases that would might benefit from the kitchen sink.
  3.  A topology instance that is based on ietf-te-topology can easily layer on top of a topology instance that is based on ietf-network. Ietf-network *is* the common model, since ietf-te-topology is an augmentation of ietf-network.
  4.  If in the future, there are clearer use cases that would benefit from the TE aspects of ietf-te-topology, it is possible to have a single topology instance that implements microwave-topology *and* ietf-te-topology.
I think RFC 8346 - A YANG Data Model for Layer 3 Topologies and draft-ietf-teas-yang-l3-te-topo-05 YANG Data Model for Layer 3 TE Topologies provide a great precedence. In RFC 8346, IETF defined ietf-l3-topology as a non-TE topology to model Layer 3 IP topology. For the use cases that would benefit from traffic engineering in Layer 3, ietf-l3-te-topology defined in draft-ietf-teas-yang-l3-te-topo-05 augments ietf-te-topology, and it is designed to *work with* ietf-l3-topology to provide L3 TE topology capabilities.

[SC] These are non core constructs of ietf-te-topology and constitute less than 5% of the definition of ietf-te-topology. There had been no solid evidence provided by anyone in this discussion chain that core constructs such as TTP, tunnel, connectivity matrix and LLCL which constitute the bulk of ietf-te-topology are beneficial to microwave-topology. The equivalent of the fields you mentioned can easily can augmented on ietf-network. If we as a group agree that these fields are necessary to microwave-topology, I would be happy to agree to augmenting them on top of ietf-network as part of microwave-topology.

A model defined today should have the capability to extend for future use.
[SC] It is always a balance between ease of implementation, ease of inter-operability and capability to extend for future use. I am not convinced that basing microwave-topology on ietf-te-topology would constitute an appropriate balance. draft-ietf-teas-yang-te-topo-22 is a huge document at 221 pages.

With microwave technology evolution, use case such as protection will be required, where SRLG from te-topo could be used; PtMP microwave will be introduced apart from current PtP microwave, where te-tunnel could be introduced.  te-topo provides a good basis for future extension.
[SC] If in the future, there are clearer use cases that would benefit from the TE aspects of ietf-te-topology, it is possible to have a single topology instance that implements microwave-topology *and* ietf-te-topology.
RFC 8346 - A YANG Data Model for Layer 3 Topologies and draft-ietf-teas-yang-l3-te-topo-05 YANG Data Model for Layer 3 TE Topologies provide a great precedence. In RFC 8346, IETF defined ietf-l3-topology as a non-TE topology to model Layer 3 IP topology. For the use cases that would benefit from traffic engineering in Layer 3, ietf-l3-te-topology defined in draft-ietf-teas-yang-l3-te-topo-05 augments ietf-te-topology is designed to *work with* ietf-l3-topology to provide L3 TE topology capabilities. This allows most implementation to provide a simpler and fast-to-market and easier-to-use solution, while not restricting those vendors that need L3 TE topology capabilities to do so.
As such I believe that the RFC 8346 and draft-ietf-teas-yang-l3-te-topo-05 should be the model for us to proceed with microwave-topology. IMO microwave-topology should be simple to implement and address the core use cases that do not require TE. However microwave-topology should be written not to preclude the co-existence of ietf-te-topology in a single topology instance.

BR,
Amy

Regards
Jonas A

-----Original Appointment-----
From: CCAMP Working Group <[email-masked]<mailto:[email-masked]>>
Sent: den 20 augusti 2019 07:46
To: CCAMP Working Group; ccamp
Subject: [CCAMP] Webex meeting invitation: Microwave topology
When: den 19 september 2019 07:00-08:00 America/New_York.
Where: https://ietf.webex.com/ietf

Join by phone

---

From: Jonas Ahlberg <[email-masked]>
Date: Thu, 26 Sep 2019 13:05:29 +0000

Hi all,
Some short notes from the meeting September 26.
Participants: Amy Ye, Daniela Spreafico, Dragos D, Italo Busi, Stephen Cheng, , Jonas Ahlberg

Applicability of ietf-te-topology for microwave radio link
The meeting continued the discussion about which concepts from ietf-te-topology are applicable for microwave radio link and what use cases they support, based on the mails from Amy and Stephen.
The meeting agreed that all representatives should review ietf-te-topology and clarify what they see could be applicable for microwave radio link and which parts are not. The ambition is to get that input in time for next weeks meeting or the meeting after that at the latest.
Once there is a common and agreed view of which parts of te-topology is applicable for microwave radio link and what use cases they are supposed to support, we can get back to the discussion about how to model it in the best way.

Regards
Jonas A

-----Original Appointment-----
From: CCAMP Working Group <[email-masked]>
Sent: den 20 augusti 2019 07:46
To: CCAMP Working Group; ccamp
Subject: [CCAMP] Webex meeting invitation: Microwave topology
When: den 26 september 2019 07:00-08:00 America/New_York.
Where: https://ietf.webex.com/ietf

Join by phone

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 26 Sep 2019 13:26:06 +0000

Thanks, very good input.

I was myself struggling to understand why the TE topology is needed as opposite to the network topology. 

If I may give you a suggestion, you could provide a “profile” of the TE topology for microwave. Let me try to explain it better as I can’t the find the right work in English.

I was thinking of something along the lines of: to describe a network topology you need this e.g. 30% of the TE topology and then we propose to augment it with X,Y,Z. 

This would make the implementation of the TE topology for microwave much easier.

Thanks,

Daniele  

From: Jonas Ahlberg <[email-masked]> 
Sent: den 26 september 2019 15:05
To: CCAMP Working Group <[email-masked]>; ccamp <[email-masked]>
Subject: RE: [CCAMP] Webex meeting invitation: Microwave topology

Hi all,

Regards

Jonas A

-----Original Appointment-----
From: CCAMP Working Group <[email-masked] <mailto:[email-masked]> > 
Sent: den 20 augusti 2019 07:46
To: CCAMP Working Group; ccamp
Subject: [CCAMP] Webex meeting invitation: Microwave topology
When: den 26 september 2019 07:00-08:00 America/New_York.
Where: https://ietf.webex.com/ietf

 

 

 

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

Join by phone

 <tel:%2B1-650-479-3208,,*01*647343270%23%23*01*> 1-650-479-3208 Call-in toll number (US/Canada)

 <tel:1-877-668-4493,,*01*647343270%23%23*01*> 1-877-668-4493 Call-in toll free number (US/Canada)

 <https://ietf.webex.com/ietf/globalcallin.php?MTID=m57c83575d64804b110f94f798d438720> Global call-in numbers  |   <https://www.webex.com/pdf/tollfree_restrictions.pdf> Toll-free calling restrictions

 

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