Re: [Last-Call] Secdir last call review of draft-ietf-opsawg-yang-vpn-service-pm-12

["Wubo (lana)" <[e-mail]>]

Hi Daniel,



Thank you for the review. Please see inline for the reply.



Thanks,

Bo



-----Original Message-----
From: Daniel Migault via Datatracker [mailto:[e-mail]]
Sent: Saturday, October 8, 2022 3:55 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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].