[CCAMP] 答复: A few thoughts for draft-yu-ccamp-optical-resource-pm-yang

[yuchaode <[e-mail]>]

Hi Daniel and CCAMP working group,

A lot of thanks to Daniel for your very professional comments.
I will issue a new version in the next week.
And comments from CCAMP working group are always welcome.


B.R.
Chaode

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 
发送时间: 2024年4月25日 17:04
收件人: 'CCAMP' <[e-mail]>
主题: [CCAMP] A few thoughts for draft-yu-ccamp-optical-resource-pm-yang

Hi draft-yu-ccamp-optical-resource-pm-yang authors, 

Re: A YANG Data Model for Optical Resource Performance Monitoring https://datatracker.ietf.org/doc/draft-yu-ccamp-optical-resource-pm-yang/

Having read the document a few times, including as a component to assist in optical network digital twin solution development and the recent discussion of fine-grain network management for ACTN, I would like to share some thoughts on the work. 

The document is well-written and proposes several YANG functions related to real-time and historical performance monitoring for optical parameters. It builds on existing core data models (topology), VPN service monitoring and ACTN telemetry autonomics. It may also be worth including the inventory work in the discussion. Overall, the proposal provides an important YANG module for optical network service setup and operation, which will be used with several other well-defined and developing YANG models.  

It's good to see the requirements derived from the TMF MTOSI specification for resource management; however, the reference
(https://www.tmforum.org/resources/collection/mtosi-4-0) used in the document takes you to the general area for MTOSI 4.0 and not the specific resource describing the requirements, which I think might be the TMF518 document, so a more direct accurate link might be useful, especially as you list this as a normative reference. Furthermore, some of the recent MEF work on (optical) transport as an underlay connectivity service - UCS activation might also referenced, as it also requires TCA capability. I will follow up with the authors offline on this topic. 

The introduction of the document does a good job of summarising existing work that relates to the proposed YANG work of optical PMs; I would suggest some additional text, maybe before the final paragraph in Section 1
(Introduction):

"The YANG data model in this document may be used to monitor and manage the performance of optical network resources. It provides the three key elements for performance management: control, retrieval and threshold crossing alert.
These interfaces can then be used with technology-specific models to collect data performance related to bandwidth utilization, latency, error rates, availability, environmental, and other key performance indicators (KPIs) specific to optical networking."

Also, the following grammar NITS could be squashed in this early section:

OLD: Performance monitoring is a basic function of optical networks management. 

NEW: Performance monitoring is a basic function of optical network management.

OLD: Mostly, they are fear of introducing issues into their network due to the protocol changes and O&M habits changes.

NEW: Mostly, they are concerned with introducing problems into their network due to protocol changes and changes to Operation and Maintenance (O&M) habits.

OLD: Such as session 10 of [ITU-T_G.7710] has provided very detail description of performance management application and functions.

NEW: Such as section 10 of [ITU-T_G.7710] provides a detailed description of performance management applications and functions.

OLD: Currently, there are some existing documents related to performance monitoring in IETF, but there is no overlap with our current work. For
example:

NEW: There are existing documents which relate to performance monitoring in IETF but do not overlap with the function in this document; these include: 

OLD: VN is determinate to be used in CMI (CNC-MDSC Interface) level and TE tunnel is more service or connection related. 

NEW: The VN is used via the CMI (CNC-MDSC Interface) level, and the Traffic Engineered (TE) tunnel is typically service or connection-based. 

The "Terminology" section needs a fuller list of acronyms (non-ACTN) used in this document. 

In the "YANG Data Model for Optical Performance Monitoring," you list some requirements; those might be easier to read as bullets rather than paragraphs.

>>
According to the business requirements stated in [TMF-518], resource performance management requirements include:

o The Interface shall support the control of performance monitoring in the network. This includes PM control, e.g., the enabling and disabling of PM collection and Threshold Crossing Alerts (TCA) control, e.g., the enabling and disabling of TCA generation;

o The Interface shall support the retrieval of current and historical performance measurements for network resources;

o The Interface shall support the distribution of TCAs to subscribed OSs.
<<

The final bullet mentions "OSs," which I think should read Operational Support System (OSS). 

Including a simple ASCII diagram showing the OSS component, ACTN architecture, and Optical Nodes would be very useful, with the relevant interfaces described earlier in the document. This would provide a useful visualization of the concepts and interface discussed.

In the "YANG Data Model for Optical Performance Monitoring" section, grammar improvements could be made. 

OLD: For these requirements of PM, there are three group of interfaces are defined in TMF, including PerformanceManagementControl, PerformanceManagementRetrieval and ThresholdCrossingAlertControl.

NEW: For PM requirements, three interface functions are defined in TMF, including PerformanceManagementControl, PerformanceManagementRetrieval and ThresholdCrossingAlertControl.

In the "Generic Resource" section, grammar improvements could be made.

OLD: And it is also similar that the functionalities of both alarm and performance monitoring can be defined with a generic structure, regardless of what kind of object is operated on. 

NEW: The functionalities of alarm and performance monitoring may be defined with a generic structure, regardless of the operated object. 

Finally, the examples (use cases) are excellent. You might mention in the Appendix that these should be removed by the RFC Editor if the document is published as an RFC. If the document becomes a WG item (and I believe it
should) the examples could be moved to the CCAMP GitHub. 

Thanks, Dan.