Re: [OPSAWG] A review of draft-ietf-opsawg-yang-vpn-service-pm-01

[Adrian Farrel <[e-mail]>]

Hi Bo,

Thanks for the positive response.

Replies to you below. Summary: all good!

Best,
Adrian

>> Looking at Figure 1, an obvious question is why this model doesn't
augment the
>> L2/L3NM or the common VPN model. It is OK (for me) that you have chosen
to
>> augment the network topology model, but it is not clear to the reader why
you
>> have done this.
>> 
> [Bo]Thanks. We think it is useful to add some text to explain. How about
adding some text like this:
> The performance of VPN services is associated with the performance changes
of the underlay network that carries VPN services, such as the delay of the
underlay tunnels and the packet loss status of the device interfaces.
> Additionally, the integration of Layer 2/Layer 3 VPN performance and
network performance data enables the orchestrator to subscribe to VPN
service performance in a unified manner. 
> Therefore, this document defines a YANG module for both network and VPN
service performance monitoring (PM).

Nice

>> I wonder whether the work in this document would benefit from using data
>> tags (draft-ietf-netmod-node-tags). I might be wrong, but it seems
particularly
>> related and useful.
>> 
> [Bo]Agree. We think draft-ietf-netmod-node-tags can helps PM accurately
subscribe to metric-related data. How about the following text in section 3
Network and VPN Service Performance Monitoring Model Usage:
> VPN and network performance management focus on the performance metric
data of network devices. To avoid receiving a large amount of operational
data of VPN instances, VPN interfaces, or tunnels, 
> The controller can specifically subscribe to metric-specific data using
the methods defined in draft-ietf-netmod-node-tags.

Good

>> 5.
>> 
>> General question about counters based on my memory of how we did MIBs (So
>> I am old! Quite possible that YANG does this differently.) Don't you need
>> something to handle resets? That is, to distinguish between wrapping and
>> resetting, we used to include a timestamp for when the counters were last
>> reset. Sometimes this was a timestamp per counter, but usually enough for
one
>> timestamp across all counters.
>> 
>> (This probably makes a difference to the gauges and percentiles, too.)
>> 
>> Re-reading, it is possible that this is covered by 'reference-time' and
>> 'measurement-interval'.  If so, this could be a lot clearer in 4.4.
>> 
> [Bo] Yes. Your understanding about 'reference-time' and
'measurement-interval' is correct. We will add text in 4.4 to make it
clearer.
> 'reference-time': Indicates the start time of the performance measurement.
> 'measurement-interval' : Specifies the performance measurement interval,
in seconds.

Perfect