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

[Stephen Cheng <[e-mail]>]

Amy, please see below for my opinion.

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

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.
[SC] The ETSI 1st mWT plug-test specify the following microwave topology sub-tree.
[cid:image001.png@01D57486.66146530]
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.

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.
[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.

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
[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
________________________________
发件人: CCAMP [[e-mail]] 代表 Jonas Ahlberg [jonas.ahlberg=[e-mail]]
发送时间: 2019年9月19日 22:00
收件人: CCAMP Working Group; ccamp
主题: Re: [CCAMP] Webex meeting invitation: Microwave topology
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 <[e-mail]<mailto:[e-mail]>>
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


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:[phone],,*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