Subject: Re: [OPSAWG] WG LC: A YANG Model for Network and VPN Service Performance Monitoring

From: "Wubo (lana)" <[email-masked]>
Date: Mon, 7 Mar 2022 12:21:01 +0000

Hi Adrian,

Thanks again for your helpful review. Please see in line with details.

Thanks,

Bo

> -----邮件原件-----

> 发件人: OPSAWG [mailto:[email-masked]] 代表 Adrian Farrel

> 发送时间: 2022年3月6日 21:57

> 收件人: 'Joe Clarke (jclarke)' <jclarke=[email-masked]>;

> [email-masked]

> 主题: Re: [OPSAWG] WG LC: A YANG Model for Network and VPN Service

> Performance Monitoring

> Hi,

> I reviewed this draft at -01 [1]. The authors proposed acceptable changes, and

> these have appeared in the subsequent revisions.

> As part of WG last call, I have done another quick review. Asides from a few

> trivial nits (below), I think this draft is ready for publication.

> Thanks,

> Adrian

> [1]

> https://mailarchive.ietf.org/arch/msg/opsawg/xcSMXTG8Pooi3ypLNyQWEKm7<https://mailarchive.ietf.org/arch/msg/opsawg/xcSMXTG8Pooi3ypLNyQWEKm7qgg/>

> qgg/<https://mailarchive.ietf.org/arch/msg/opsawg/xcSMXTG8Pooi3ypLNyQWEKm7qgg/>

> ==Nits==

> Section 1 para 1

> This document shouldn't "propose" anything. It should "define".

[Bo Wu] Thanks. Fixed.

> ---

> 2.1

> s/Service Level Agreements/Service Level Agreement/

[Bo Wu] Thanks. Fixed.

> ---

> 3.

> s/the context of layering/the context of the layering/

[Bo Wu] Thanks. Fixed.

> ---

> 3.1

> s/specified in[RFC8641]/specified in [RFC8641]/

[Bo Wu] Thanks. Fixed.

> ---

> Obviously, draft-ietf-opsawg-vpn-common is an RFC now.

> You can replace the reference and fix CCCC.

[Bo Wu] Thanks for catching this. We will fix.

> ---

>          leaf measurement-interval {

>            type uint32;

>            units "seconds";

>            default "60";

>            description

>              "Indicates the time interval to perform PM measurement.";

>          }

> Is a value of 0 supported? What does it mean?

[Bo Wu] Thanks for pointing this out. We will add a constraint of range "1..max" to the node.

> -----Original Message-----

> From: OPSAWG <[email-masked]<mailto:[email-masked]>> On Behalf Of Joe Clarke (jclarke)

> Sent: 28 February 2022 23:05

> To: [email-masked]<mailto:[email-masked]>

> Subject: [OPSAWG] WG LC: A YANG Model for Network and VPN Service

> Performance Monitoring

> Ahead of IETF 113, we'd like to get working group consensus on

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/.  We

> are therefore conducting a two-week WG LC on this work.  I have also

> requested reviews from Yang Docs, Ops, and Routing DIRs.

> Please share you comments and reviews on list.

> WG LC will end on March 14, 2022.

> Thanks.

> Joe

> _______________________________________________

> OPSAWG mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/opsawg

> _______________________________________________

> OPSAWG mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Wubo (lana)" <[email-masked]>
Date: Wed, 9 Mar 2022 09:51:34 +0000

Hi Joe,

Thanks for your helpful review. Please see inline.

Regards,
Bo

发件人: OPSAWG [mailto:[email-masked]] 代表 Joe Clarke (jclarke)
发送时间: 2022年3月8日 1:13
收件人: Joe Clarke (jclarke) <jclarke=[email-masked]>; [email-masked]
主题: Re: [OPSAWG] WG LC: A YANG Model for Network and VPN Service Performance Monitoring

A few comments on -03.

Section 4.1

Overall, this section seems like it could use more grounding to this work.  It is a generic example of VPN layering.  What would be a nice addition is to markup points where performance monitoring would be helpful to illustrate how this work comes into play.
[Bo Wu] Thanks for the suggestion. How about adding the following text:
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 provides 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.

In the YANG module, I'm curious about two things:

First, why are inbound-discards a counter32 whereas outbound-discard a counter64?  I think both should be 64-bit, yes?
[Bo Wu] Yes. Thanks for catching this. We will fix.

Second, the description on inbound-nunicast is different than outbound-nunicast with the latter being more descriptive.  Can you do a pass to make sure these two sets of descriptions (inbound and outbond) align respective to their direction?
[Bo Wu] Sure. We will fix.

Thanks.

Joe
On 2/28/22 18:06, Joe Clarke (jclarke) wrote:

Thanks.

Joe

OPSAWG mailing list