[OPSAWG] 答复: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

"Wubo (lana)" <lana.wubo@huawei.com> Tue, 13 September 2022 06:38 UTC

From: "Wubo (lana)" <lana.wubo@huawei.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "draft-ietf-opsawg-yang-vpn-service-pm.all@ietf.org" <draft-ietf-opsawg-yang-vpn-service-pm.all@ietf.org>
CC: "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09
Thread-Index: AdjDgY74oamysRH/SPqEo+WFhVCtXADmwSfg
Date: Tue, 13 Sep 2022 06:37:50 +0000
Message-ID: <53d5992a47c7487fa0de55d2a34c05a8@huawei.com>
References: <BY5PR11MB4196E8A452961895B97B284CB5439@BY5PR11MB4196.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB4196E8A452961895B97B284CB5439@BY5PR11MB4196.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_53d5992a47c7487fa0de55d2a34c05a8huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/IujvlnwSVokoH4YUl4UaktG-nnw>
Subject: [OPSAWG] 答复: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09
Precedence: list

Hi Rob,

Many thanks for your thoughtful review. Please see inline.

Thanks,

-----邮件原件-----
发件人: Rob Wilton (rwilton) [mailto:rwilton@cisco.com]
发送时间: 2022年9月9日 18:43
收件人: draft-ietf-opsawg-yang-vpn-service-pm.all@ietf.org
抄送: opsawg@ietf.org
主题: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi,

Here are my AD review comments for draft-ietf-opsawg-yang-vpn-service-pm-09, apologies for the delay.

I think that this document is in good shape and hence most of my comments are only minor or nits.

Minor level comments:

(1) p 0, sec

The data model for network topologies defined in RFC 8345 introduces

vertical layering relationships between networks that can be

augmented to cover network and service topologies. This document

defines a YANG module for performance monitoring (PM) of both

networks and VPN services that can be used to monitor and manage

network performance on the topology at higher layer or the service

topology between VPN sites.

"the topology at higher layer" doesn't scan particularly well to me, please can you tweak it.

Bo: Thanks for pointing this out. Is this better that we simply change to “the underlay topology”?

(2) p 1, sec 1. Introduction

[RFC8969] describes a framework for automating service and network

management with YANG [RFC6020] models.

Please update reference to RFC 7950 for YANG.

Bo: Thanks. Will do.

(3) p 4, sec 3. Network and VPN Service Performance Monitoring Model Usage

As shown in Figure 1, in the context of the layering model

architecture described in [RFC8309], the network and VPN service

performance monitoring (PM) model can be used to expose a set of

performance information to the above layer. Such information can be

used by an orchestrator to subscribe to performance data.

Perhaps rephase? I.e., is it the performance data that is being used to create a subscription based on the performance data, or is it just that the model makes the performance data readily available, which can then be subscribed do?

Bo: Thanks for the suggestion. How about:

The model makes the performance data readily available, which can then be subscribed by the client application, such as an orchestrator.

(4) p 4, sec 3. Network and VPN Service Performance Monitoring Model Usage

In addition, the amount of performance data collected from the

devices can be huge. To avoid receiving a large amount of

operational data of VPN instances, VPN interfaces, or tunnels, the

network controller can specifically subscribe to metric-specific data

using the tagging methods defined in [I-D.ietf-netmod-node-tags].

At the moment, my reading of the ietf-netmod-node-tags draft is that it doesn't currently allow you do this. I.e., you can't just make a subscription to all datanodes that have been tagged in a particular way. Hence, I would suggest removing this paragraph, since it doesn't seem to be directly related to what is described in this model.

Bo: Thanks and agree with your suggestion. Will remove this paragraph.

(5) p 5, sec 3.1. Collecting Data via Pub/Sub Mechanism

Some applications such as service-assurance applications, which must

maintain a continuous view of operational data and state, can use the

subscription model specified in [RFC8641] to subscribe to the

specific network performance data or VPN service performance data

they are interested in, at the data source. For example, network or

VPN topology updates may be obtained through on-change notifications

[RFC8641]. For dynamic PM data, various notifications can be

specified to obtain more complete data.

Can you elaborate a bit on what is meant by dynamic PM data please.

Bo: Thanks for pointing this out. How about we change:

For dynamic PM data, e.g. VRF routes or MAC entries, link metrics, and interface metrics, various notifications can be specified to obtain more complete data.

(6) p 5, sec 3.1. Collecting Data via Pub/Sub Mechanism

A periodic notification

[RFC8641] can be specified to obtain real-time performance data, a

replay notification defined in [RFC5277] or [RFC8639] can be

specified to obtain historical data

If this data is coming from a device then ideally it would not hold on to much historical data.

Bo: Is it better that we change to “can be specified to obtain historical data in a limited period of time.”? E.g. in some implementation, a controller can store PM data for a year?

(7) p 6, sec 4.1. Layering Relationship between Multiple Layers of Topology

Figure 3: Example of Topology Mapping Between VPN Service

Topology and Underlying Network

Note, I don't find this diagram brilliantly clear, it is hard to see when the dotted lines go but the explanatory text is clear (and probably sufficient).

Bo: Thanks. We can remove the lines if it doesn't help.

(8) p 7, sec 4.1. Layering Relationship between Multiple Layers of Topology

Apart from the association between the VPN topology and the underlay

topology, VPN Network PM can also provide the performance status of

the underlay network and VPN services. For example, network PM can

provide link PM statistics and port statistics. VPN PM can provide

statistics on VPN access interfaces, the number of current VRF routes

or L2VPN MAC entry of VPN nodes, and performance statistics on the

logical point-to-point link between source and destination VPN nodes

or between source and destination VPN access interfaces. Figure 4

illustrates an example of VPN PM and the difference between two VPN

PM measurement methods. One is the VPN tunnel PM and the other is

inter-VPN-access interface PM.

By "VPN Network PM", do you mean the "VPN Network PM YANG module", or is this just referring to performance monitoring in general?

Bo: "VPN Network PM" mean "VPN Network PM YANG module". How about we rephrase:

Apart from the association between the VPN topology and the underlay

topology, VPN Network PM YANG module can also provide the performance status of

the underlay network and VPN services. For example, network PM the module can

provide link PM statistics and port statistics of a underlay network. And it can also provide

VPN PM statistics, which can be further split into PM for the VPN tunnel and PM at the VPN PE access node, as illustrated in the following diagram.

such as statistics on VPN access interfaces, the number of current VRF routes

or L2VPN MAC entry of VPN nodes, and performance statistics on the

logical point-to-point link between source and destination VPN nodes

or between source and destination VPN access interfaces. Figure 4

illustrates an example of the module VPN PM and shows the difference between two VPN

PM measurement methods. One is including the VPN tunnel PM and the other is

inter-VPN-access interface PM. // The newly added text are blue.

Figure 4 illustrates an example of VPN PM and two VPN PM measurement methods including the VPN tunnel PM and the inter-VPN-access interface PM. VPN PM can also provide

statistics on VPN access interfaces, the number of current VRF routes or L2VPN MAC entry of VPN node

(9) p 7, sec 4.1. Layering Relationship between Multiple Layers of Topology