Re: [CCAMP] EXTERNAL: RE: Comments and questions on draft-ietf-ccamp-mw-topo-yang-01

["Yemin (Amy)" <[e-mail]>]

To coordinate the time between 4 time zones is not so easy.
The only possible time is: China(19:00), Europe(13:00), east coast of US/Canada(7:00), New Zealand(23:00).

The access information of the call will be sent out later.

Amy
From: Stephen Cheng [mailto:[e-mail]]
Sent: Friday, July 12, 2019 12:28 PM
To: Jonas Ahlberg <[e-mail]>; [e-mail]
Subject: RE: EXTERNAL: RE: Comments and questions on draft-ietf-ccamp-mw-topo-yang-01

Thank you for quick response.

I am based in New Zealand, and so 14:00 to 15:00 UTC+2 is not the best time for me. It would be midnight to 1am.
I would appreciate an earlier time. Thanks.

Looking forward to the conversation.

Warm regards,
Stephen Cheng

From: Jonas Ahlberg <[e-mail]<mailto:[e-mail]>>
Sent: 2019年7月12日 1:59 AM
To: Stephen Cheng <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: EXTERNAL: RE: Comments and questions on draft-ietf-ccamp-mw-topo-yang-01

Hi Stephen,

Thank you for your comments on the draft. They are relevant & valuable and I suggest that we discuss them in the working team together with you, in order to fully understand how they should impact the draft. As changes/updates and/or further clarifications and examples.

Vacation periods are coming up and the next meeting is therefore planned to Thursday August 22 and every Thursday going forward after that.

Currently we have representation on our meetings from China, Europe and sometimes also from the east coast of US/Canada, and we normally meet from 14:00 to 15:00 UTC+2.

That time is however flexible and I wonder when it would be suitable for you to meet.
That question is of course valid for the rest of you on the CCAMP list who has an interest in joining the discussion.

Looking forward to the discussion in August.

Regards
JonasA



From: Stephen Cheng <[e-mail]<mailto:[e-mail]>>
Sent: den 8 juli 2019 00:22
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Comments and questions on draft-ietf-ccamp-mw-topo-yang-01

Dear draft-ietf-ccamp-mw-topo-yang-01 authors,

I have been reviewing the current draft, and I have a number of questions and comments attached below. I am looking forward to your illumination and feedback. Thank you.

Warm regards,
Stephen Cheng


The current draft of ietf-microwave-topology augments ietf-te-topology. I would like to better understand the basis of this design choice.

  *   Is it to enable the modelling of a fully traffic engineered network from L1 all the way to L2/L3/MPLS and beyond?
  *   It appears that many aspects of ietf-te-topology that would unlikely to be applicable to Microwave topology, such as
     *   TTP
     *   TE-Path
     *   Inter-Layer Lock
     *   Transition Link
     *   Can the authors clarify if they would be applicable to a L1 microwave topology?
  *   Appendix A.1 and A.2 examples do not show how any of the attributes defined in ietf-te-topology are used in the context of modelling microwave L1 topology. They only show the attributes defined in ietf-microwave-topology. It would be useful to show such examples.
  *   It would be helpful if a section is added to the I-D to explain which aspects defined in ietf-te-topology would be typically applicable to a L1 microwave topology, and how they should be used in conjunction with ietf-microwave-topology.

I would like to understand how authors intend to model/use connectivity matrix/LLCL in ietf-microwave-topology. I would argue that connectivity matrix/LLCL is of limited applicability for modelling L1 microwave network:

  *   Most microwave-capable devices have microwave links and links of other L1 technology (such as Ethernet and optical).
     *   At a radio site, a microwave device is typically connected to other microwave devices, switches or routers via an Ethernet or optical link
  *   Traffic between different links (whether microwave/non-microwave) within a node are typically switched at layer 2, or routed at layer 3 or IP/MPLS, and not at L1 level.
  *   As such if it is desired to describe traffic engineering between links (whether microwave/non-microwave), it should be described at the layer which the traffic switching/routing occurs.
     *   For example:
        *   a L2 topology (perhaps augmenting ietf-te-topology) could describe the switching capability at the layer 2, with L1 TE topology as the underlay topology
        *   a ietf-te-topology topology could be used to describe the traffic engineering for IP/MPLS, with L1 TE topology as the underlay topology
     *   Due to the fact that a L1 TE topology being an underlay for L2 TE, L3, MPLS TE topologies, the domain controller or operators can still determine if a L1 microwave link is over-subscribed.
  *   If the above reasoning is correct, ietf-microwave-topology should not need to augment connectivity matrix/LLCL with new microwave specific attributes, unless L1 switching is expected on microwaves.

It is a common requirement for users (of a domain controller) to expect a single layer 1 topology to describe all the physical devices and all the L1 links no matter what the L1 technology is. In most networks where microwave plays a part, there would be other L1 technologies such as Ethernet and optical. As such it would be desirable to structure ietf-microwave-topology so that it could co-exist with the modelling of other L1 technologies.

  *   At the moment this is not possible with the proposed ietf-microwave-topology, even although RFC 8345 section 4.1 says
"a network can even have multiple types simultaneously. The type or types are captured underneath the container "network-types""
     *   It is not possible to determine if a LTP is a microwave termination point or another type of link
     *   It is not possible to determine if a link is a microwave link or another type of link
  *   One possible solution is as follow:
     *   Add a "microwave" presence container under nt:tp to indicate that it is a microwave TP
     *   Add a "microwave" presence container under nt:link to indicate that it is a microwave link
     *   the mw-link-attributes in nt:tp are conditional on the "microwave" presence container under nt:tp
     *   the mw-tp-attributes in nt:link are conditional on the "microwave" presence container under nt:link
  *   If other L1 technology topology models follow a similar protocol (i.e. technology-specific presence container for TP and link), it would be possible to have a single L1 TE topology instance to model a network with a mix of L1 technologies.