Re: [OPSAWG] Last Call: <draft-ietf-opsawg-yang-vpn-service-pm-10.txt> (A YANG Model for Network and VPN Service Performance Monitoring) to Proposed Standard

["Wubo (lana)" <[e-mail]>]

Hi Tom,



Thanks for your careful review. We have posted rev-11. Please see if this version addresses your comments.

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-11



Please also see inline for the detailed reply.

Thanks,

Bo



-----Original Message-----

From: tom petch [mailto:[e-mail]]

Sent: Thursday, September 22, 2022 7:24 PM

To: [e-mail]

Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]

Subject: Re: Last Call: <draft-ietf-opsawg-yang-vpn-service-pm-10.txt> (A YANG Model for Network and VPN Service Performance Monitoring) to Proposed Standard



On 20/09/2022 17:24, The IESG wrote:

>

> The IESG has received a request from the Operations and Management

> Area Working Group WG (opsawg) to consider the following document: -

> 'A YANG Model for Network and VPN Service Performance Monitoring'

>    <draft-ietf-opsawg-yang-vpn-service-pm-10.txt> as Proposed Standard





I struggled to understand what this I-D offered until the AD Review where the AD had issues similar to mine.  Even now, I am unclear if I understand it; the problem is wording and inconsistent use thereof.



In many places, the I-D says

'This document  defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services '

and it is that 'both' that I think starts to lead the reader, or at least me, up the garden path.



s.4.2 says

    The model can be used for performance monitoring both for the

    underlay network and the VPN services.  The two would be separate

    entries in the network list [RFC8345].



and then talks of  the effect of the  "service" presence container being absent or present, which would doubtless twitch the nostrils of a YANG Doctor.



What it is saying, I think, is that the YANG module

- either provides data for PM of a VPN service

- or provides data for PM for the network itself but cannot do both, except in the sense that the YANG model in a node may contain multiple entries in the network list one or more of which is for a VPN service and one or more of which is for a network itself and that Netconf, e.g., can retrieve data for both in a single 'get'.  I think that the use of 'both' above is a stretch for that use of the word, more precisely it is either VPN service or network itself.



Bo: Thanks for the comments. But the module really covers the both, though the network or VPN service PM instances can be accessed through separate network list entries.



The rest of the I-D increases my confusion.



s.4

' The performance monitoring data augments the service topology as shown in Figure 2.'

Figure 2 has no mention of service.  Perhaps the reader must infer that what is meant is

The YANG module for performance monitoring data augments the YANG module for service topology - i.e. ietf-network, ietf-network-topology -



Bo: Thanks for pointing this out. Yes. Here is the change of new revision:

OLD:

   This document defines the YANG module, "ietf-network-vpn-pm", which

   is an augmentation to the "ietf-network" and "ietf-network-topology"

   modules.



   The performance monitoring data augments the service topology as

   shown in Figure 2.



NEW:

   This document defines the YANG module, "ietf-network-vpn-pm", which

   is an augmentation to the "ietf-network" and "ietf-network-topology"

   modules as shown in Figure 2.

END





The presence container alluded to above appears as

'      container service {

          presence

            "Presence of the container indicates a service

             topology, absence of the container indicates an

             underlay network.";  '

The use of service topology here seems at odds with that in s.4.2 but later, in several places, there is

        when '../nw:network-types/nvp:service' {

          description

            "Augments only for VPN node attributes."; Well no, the augments only occurs when 'service' is present and that has just been defined as 'Presence of the container indicates a service topology'; seems contradictory here and in several places.

Bo: Yes. I agree this is not clear enough. Fixed in the new revision.





Also, in most places, it is 'underlay tunnel' or 'underlay-tunnel'

whereas here it is 'underlay network' as it is in the Abstract and that, for me, again, leads the reader - me - astray.



Bo: Agree this is confusing. I have changed "underlay tunnel " to "vpn-tunnel" in most places and replaced one with underlay links.



In a similar vein, I see

              leaf start-time { type yang:date-and-time;

                config false; description

                  "The time that the current measurement started."; The YANG type is date and time so that is 'The date and time ..'.  I often see monitoring at the same time every day which is what the description might mean but does not.



Bo: Thanks. Fixed with "The date and time the measurement last started."



Likewise

          leaf unit-value {

            type identityref {  base lime:time-unit-type;      }

            default "lime:milliseconds";

            description

              "Time units, where the options are s, ms, ns, etc."; This is taken from  RFC8532 where the options are hours minutes seconds milliseconds microseconds nanoseconds.  I think that the reader deserves a more accurate description.

Bo: Yes. Have fixed with "Time units, where the options are hours, minutes, seconds, milliseconds, microseconds, nanoseconds."





I see it as a clever idea to have one YANG module in two different roles determined by a presence container - perhaps too clever for me.



Tom Petch







> The IESG plans to make a decision in the next few weeks, and solicits

> final comments on this action. Please send substantive comments to the

> [e-mail] mailing lists by 2022-10-04. Exceptionally,

> comments may be sent to [e-mail] instead. In either case, please

> retain the beginning of the Subject line to allow automated sorting.

>

> Abstract

>

>

>     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

>     underlay networks and overlay VPN services that can be used to

>     monitor and manage network performance on the topology of both

>     layers.

>

>

>

>

> The file can be obtained via

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

> /

>

>

>

> No IPR declarations have been submitted directly on this I-D.

>

>

>

>

>

> _______________________________________________

> IETF-Announce mailing list

> [e-mail]

> https://www.ietf.org/mailman/listinfo/ietf-announce

> .

>