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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 6 Mar 2022 13:57:09 -0000

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/xcSMXTG8Pooi3ypLNyQWEKm7qgg/

==Nits==

Section 1 para 1

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

---

2.1

s/Service Level Agreements/Service Level Agreement/

---

3.

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

---

3.1

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

---

Obviously, draft-ietf-opsawg-vpn-common is an RFC now.
You can replace the reference and fix CCCC.

---

         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?

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of Joe Clarke (jclarke)
Sent: 28 February 2022 23:05
To: [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]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 7 Mar 2022 17:13:06 +0000

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.

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?

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?

Thanks.

Joe

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

Thanks.

Joe

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 28 Mar 2022 13:52:44 +0000

In preparing for IETF 113, I let the close of this slip, but that turns
out to be a good thing.

During her presentation, Bo called out the authors made a substantive
change in the latest revision to introduce a choice for vpn-pm-type. 
Therefore, we are extending LC for another week to close on Monday,
April 4, 2022.

Joe

---

From: tom petch <[email-masked]>
Date: Wed, 30 Mar 2022 11:30:30 +0000

From: OPSAWG <[email-masked]> on behalf of Joe Clarke (jclarke) <jclarke=[email-masked]>
Sent: 28 March 2022 14:52

<tp>

Now I have lost my excuse for Last Call comments:-(

I do not understand how OWAMP is default.  AFAICT it is 'config false' so I do not understand 'default'

YANG module references  11 RFC - two are not in the I-D References AFAICT and three are Informative - latter may be ok, former not

SLA is not a starred abbreviation

one way measurement protocol (e.g. OWAMP)
what others are there?

delay is gauge64, jitter is gauge32; probably ok even if a ratio of 4B to one is unlikely

discards I am told are a sign of congestion which I always wonder about - I notice you do not mention that possibility!

Overall, I have a disconnect between PM and topology.  Topology is relatively static, you get it or set it and that is that for the time being.  PM for me is not.  It changes every interval and I want the history or I want an alert when some value for an interval exceeds or falls below a threshold.  Adding a single set of values for a single interval seems unrelated to topology and I see nothing in the text related to that.

Tom Petch

Joe