Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Bo, authors,

Okay, thanks for the clarifications.  Please see inline …


From: Wubo (lana) <[e-mail]>
Sent: 14 September 2022 15:31
To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Rob,

Thanks again for your review.  Please find our reply inline.

Thanks,
Bo

发件人: Rob Wilton (rwilton) [mailto:[e-mail]]
发送时间: 2022年9月14日 17:18
收件人: Wubo (lana) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[e-mail]>
主题: RE: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Bo, authors,

Please see inline. Again, I have removed sections where we have agreement.  I think that there is just one area that I’m still slightly confused by relating to the network vs service PM, for which I’ve added some further questions inline.



From: Wubo (lana) <[e-mail]<mailto:[e-mail]>>
Sent: 14 September 2022 09:25
To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: 答复: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Rob,

Thank again for your deep review. Please find our response inline for the open points.

Best regards,
Bo


发件人: Rob Wilton (rwilton) [mailto:[e-mail]]
发送时间: 2022年9月13日 17:24
收件人: Wubo (lana) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[e-mail]>
主题: RE: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09

Hi Bo,

Thanks.  I’ve made some further comments for a few points inline.  I’ve snipped those that we already have agreement on.


From: Wubo (lana) <[e-mail]<mailto:[e-mail]>>
Sent: 13 September 2022 07:38
To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: 答复: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09


Hi Rob,



Many thanks for your thoughtful review. Please see inline.



Thanks,



Bo



-----邮件原件-----
发件人: Rob Wilton (rwilton) [mailto:[e-mail]]
发送时间: 2022年9月9日 18:43
收件人: [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[e-mail]>
主题: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi,



Here are my AD review comments for draft-ietf-opsawg-yang-vpn-service-pm-09, apologies for the delay.



I think that this document is in good shape and hence most of my comments are only minor or nits.







(11) p 8, sec 4.2.  Network Level



   For network performance monitoring, the container of "networks" in

   [RFC8345] is not extended.



I'm confused by what this sentence is meant to convey - did you mean augmented?  In particular, it isn't clear to me how you express PM for the physical (or underlay networks).  Is what you are trying to express that the "service-type" container is present for VPN service performance monitoring and absence otherwise?  Probably more words required here, and in the YANG module.



Bo: Thanks for pointing this out. Your understanding is exactly what we're trying to convey. How about we change to



As VPN Network PM YANG module includes two types of PM augmentation, the underlay networks PM is augmented on [RFC8345] when the "service-type" presence container is not defined

, and the VPN PM is augmented on [RFC8345] when the "service-type" presence container is defined.



For the underlay network performance monitoring, the container of "networks" in

   [RFC8345] is not augmented.



I think that I would still find that slightly confusing.  Perhaps:



NEW:



4.2.  Network Level



The model can be used for performance monitoring both for the network and the VPN services.



When the “service-type” presence container is absent, then it indicates

performance monitoring of the network itself.



When the “service-type” presence container is present, then it indicates

performance monitoring of the VPN service specified by the “service-type”

leaf, e.g. , L3VPN or Virtual Private LAN Service (VPLS).  The values are taken

from [RFC9181].  When a network topology instance contains the L3VPN or

other L2VPN network type, it represents a VPN instance that can perform

performance monitoring.


Bo 2: Thanks for the good suggestion. The text looks good.



One extra question:



Does this model allow you to gather PM data from both the network and L2VPN services at the same time?  If so, is there, or should there be, any text is the document that describes how to do this?


Bo2: In the current model design, the underlay network and L2VPN are separate network instances and the PM data cannot be gathered at the same time.

RW2:
Okay.  I would like to dig into this one a bit more, to understand whether this is a real limitation or not, and to ensure that I understand the model correctly:

I’m not really concerned about whether the data can be gathered at the same time (i.e., in the same request), but I would have thought that it is likely that some operators may want to do PM at both the network and overlay at the same time.

If you take the diagram in 4.1, that shows an underlay network with two VPN1 and VPN2 service overlays, then am I right to assume that they will be modelled as 3 separate list entries in the /nw:networks/nw:network/ list, one for the underlay network, and one for each of the VPN services?

Bo3: Yes. There will be 3 network list entries.

RW3:
Okay, good.


If so, presumably, this means that you could gather “network PM statistics” for the underlying network list entry, separately from “service PM statistics” for each of the VPN service entries?  I.e., presumably this would mean that it is possible to enable PM on both the network underlay and service VPNs at the same time?

Bo3: Yes. This is the goal of the model.

If what I assume above is correct then for this:

     augment /nw:networks/nw:network/nw:network-types:
       +--rw service-type!
          +--rw service-type?   identityref

I wonder why you need the service-type presence container at all?  This would only be useful if there is an intention to augment it with other extra attributes (either in a standard, vendor, or operator model) in future.  Otherwise, it would be possible to just make service-type a leaf, and having the leaf existence determine whether it represents a service VPN.  If you do want to keep the presence contain then I would suggest calling it “service” rather than “service-type” since that would arguably make more sense if it was augmented in future.

Bo3:  The “service-type” presence container is defined following the guide from https://www.rfc-editor.org/rfc/rfc8345.html#section-4.3.

RW3:
Okay.


My understanding is that this design can allow the corresponding nodes of VPN network not affected by the network augmentation, as the new data nodes of the VPN network can defined as
   conditional ("when") on the presence of the “service-type” container.

RW3:
Yes.


On the naming of  “service-type”, we agree to change the name of "service type" to "service".

RW3:
Okay.


I have a somewhat similar question for this:


     augment /nw:networks/nw:network:

       +--rw vpn-pm-attributes

          +--rw vpn-id?                 vpn-common:vpn-id

          +--rw vpn-service-topology?   identityref

Is vpn-service-topology specific to it being a service? If so, then renaming it to vpn-topology and putting it under the service-type/service presence container may make more sense.

Bo3: We agree with you that “vpn-service-topology” and “vpn-id” can be put under “service” presence container, but prefer to keep the name of “vpn-service-topology” to easily match with the name in RFC9182:

RW3:
Okay.


     +--rw vpn-services
        +--rw vpn-service* [vpn-id]
           +--rw vpn-id                   vpn-common:vpn-id
           …
           +--rw vpn-service-topology?    Identityref


How about we make such changes:

==

4.2.  Network Level



The model can be used for performance monitoring both for the network and the VPN services. However, the module does not allow to gather the performance monitoring data simultaneously for both cases. Concretely:

* When the “service-type” presence container is absent, then it indicates

performance monitoring of the network itself.



* When the “service-type” presence container is present, then it indicates

performance monitoring of the VPN service specified by the “service-type”

leaf, e.g. , L3VPN or Virtual Private LAN Service (VPLS).  The values are taken

from [RFC9181].  When a network topology instance contains the L3VPN or

other L2VPN network type, it represents a VPN instance that can perform

performance monitoring.

==



RW2:

I think that it would be helpful to have a bit more clarity on my questions above first.
Bo3: OK. Hope the reply above helps.

RW3:

Based on your additional information, then I think that saying that is does not allow the gathering of performance data simultaneously is somewhat confusing.  E.g., you could make a get request that spanned over multiple network list entries, or similar for a subscription.

I think that probably nothing extra needs to be said at all.  But if you do want to add text here then I suggest that it clarifies that networks and VPNs would be separate entries in the network list, and the underlying network would not have the “service” container set, whereas the VPN network entries would.

Thanks,
Rob

Thanks,
Bo