Hi Daniel,
Thank you for the review. Please see inline for the reply. Thanks, Bo -----Original Message----- From: Daniel Migault via Datatracker [mailto:[email protected]] Sent: Saturday, October 8, 2022 3:55 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Secdir last call review of draft-ietf-opsawg-yang-vpn-service-pm-12 Reviewer: Daniel Migault Review result: Ready Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits, but I am not an expert in this area, so please take this comments as questions that came to me while reading the document. Introduction: [...] The performance of VPN services is associated with the performance changes of the underlay networks that carries VPN services. For example, link delay between PE and P <mglt> It seems to me that is the first time these acronyms are introduced - same with CE. </mglt> [Bo Wu] Thanks for the catching. Will expand on the first use. devices and packet loss status on Layer 2 and Layer 3 interfaces connecting PEs and CEs directly impact VPN service performance. Additionally, the integration of Layer 2/Layer 3 VPN performance and network performance data enables the orchestrator to subscribe uniformly. <mglt> I do not understand "subscribe uniformly". My impression is that here the orchestrator is responsible to enforce some network performances, and depending on the performance to meet, it will choose one configuration or the other. Does the use of one configuration versus the other is seen as a subscription ? If that is correct, this sounds like a cooperation between various actor. If so, that surprises me. </mglt> [Bo Wu] Thanks again for the catching. Agree that “subscribe uniformly” not accurate. The module is intended for the orchestrator to query or subscribe to the updates of the performance statistics. How about the following change? For example, link delay between Provider Edge (PE) and Provider (P) devices and packet loss status on Layer 2 and Layer 3 interfaces connecting PEs and Customer Edge (CE) devices directly impact VPN service performance. Additionally, the integration of Layer 2/Layer 3 VPN performance and network performance data enables the orchestrator to monitor consistently. End Therefore, this document defines a YANG module for both network and VPN service performance monitoring (PM). The module can be used to monitor and manage network performance on the topology level or the service topology between VPN sites. This document defines a base YANG data model for monitoring of network performance and VPN service performance. <mglt> I have the impression the text above repeats the previous paragraph. </mglt> [Bo Wu] OK. Will remove the second one. [...] 3. Network and VPN Service Performance Monitoring Model Usage As shown in Figure 1, in the context of the layered model architecture described in [RFC8309], the network and VPN service performance monitoring (PM) model can be used to expose operational performance information to the layer above, e.g., to an orchestrator or other client application, via standard network management APIs. <mglt> I am wondering if the client application is related to the Customer. I do not think so, but I might be wrong. I am wondering if that would make sense to have the client application being mentioned on the figure. </mglt> [Bo Wu] In the RFC 8309, the client application refers to BSS/OSS application, not customer. The intention here is to give an example architecture. We suggest to replace the figure title to “An Example Architecture with a Service Orchestrator” and the following change: The network and VPN service performance monitoring (PM) model can be used to expose operational performance information to the layer above, e.g., to an orchestrator or other BSS/OSS client application, via standard network management APIs. Figure 1 shows an example usage in an architecture described in [RFC 8309].
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
