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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
