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

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

Hi Adrian, all,



Many thanks for your shepherd. Please see inline.



Best regards,

Bo



-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Friday, September 16, 2022 5:34 PM
To: 'tom petch' <[e-mail]>; 'Rob Wilton (rwilton)' <rwilton=[e-mail]>; Wubo (lana) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi Tom, all,



I think my review as Shepherd ran into the same concern. And it is one of my long-standing gripes that "we" (the IETF) repeatedly confuse VPN as a service with the means and mechanisms to realise the VPN within the network. Of course, as network engineers, it is understandable why we make that mistake, but it is also harmful to the way we talk about the customers' view of VPNs.



Now, in discussing this document with the authors, I wanted to distinguish between the performance measurement that the customer can perform (which is strictly edge-to-edge because the customer cannot see what is happening within the network), and the measurements that the provider can perform that can be far more analytic about the resources and routes/paths within the network. My feeling was that the authors completely got this distinction, but that they wanted to look at the performance monitoring from the provider's perspective with two viewpoints: what can they measure about how their network is performing, and what can they measure that will match what the customer might measure. Of course, the provider wants to know the latter before the customer notices and complains, but the provider also wants to be able to link the edge-to-edge measurements back to the more detailed measurements from within the network to determine causes.



[Bo Wu] Thanks for your good summary. This is the exact purpose of this model. To achieve this, we also consider the similar modeling method of RFC 8345, as both the underlay network and the overlay network share the same metrics and counters.



It is possible that I have expressed that differently from the way the document describes it, and it also possible that I have misrepresented the authors and the working group. But that was my take-away.



Cheers,

Adrian



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

From: OPSAWG <[e-mail]<mailto:[e-mail]>> On Behalf Of tom petch

Sent: 15 September 2022 11:37

To: Rob Wilton (rwilton) <rwilton=[e-mail]<mailto:rwilton=[e-mail]>>; Wubo (lana) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>

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



From: OPSAWG <[e-mail]<mailto:[e-mail]>> on behalf of Rob Wilton (rwilton) <rwilton=[e-mail]<mailto:rwilton=[e-mail]>>

Sent: 15 September 2022 09:09



Hi Bo,



Looks good.



Let me know when you have an updated version of the draft posted and I will kick off the IETF LC.



Thanks for the updates and for taking my comments onboard.



<tp>

I have been following this thread with a sense of deja vu having made similar comments, much on s.4.2 , back in May.  Except, I do not think I ever hit 'send'.  I was trying to make clear comments that were not confused but found the I-D so confusing that I kept on changing my comments to try and make them clear and never finished.



My comments were that the document contradicted the Abstract, that the I-D was mostly about VPN services and not about network level.  I concluded that this I-D was really two separate pieces of work, headed for two separate RFC, banged together because they had some groupings in common, and I think that much of the discussion in this thread has revolved around that issue.  (It is a bit like YANG modules with masses of groupings which save the author repeating a few lines of YANG while making it harder for anyone else to follow, except more so).



So, I shall try to forget what I have learnt from this thread and read the revised I-D to see if I find it any clearer but will probably end up with the same conclusion, this is two separate RFC.



Tom Petch.



Regards,

Rob





From: Wubo (lana) <[e-mail]<mailto:[e-mail]>>

Sent: 15 September 2022 03:17

To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>

Subject: Re: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi Rob,



Thank you for the review and helpful comments.



I copied your last comment here, since this is the last point to be discussed.



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.



Bo4: Thanks for the suggestion. How about the 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: The two would be separate entries in the network list. The differences are as follows:



* 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.



==



Thanks,

Bo

发件人: Rob Wilton (rwilton) [mailto:[e-mail]]

发送时间: 2022年9月14日 22:53

收件人: Wubo (lana) <[e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>>; [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>

抄送: [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>

主题: RE: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09



Hi Bo, authors,



Okay, thanks for the clarifications.  Please see inline …





From: Wubo (lana) <[e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>>

Sent: 14 September 2022 15:31

To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>>; [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>

Cc: [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[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]<mailto:[e-mail]%3cmailto:[e-mail]>>>; [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>

抄送: [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[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]<mailto:[e-mail]%3cmailto:[e-mail]>>>

Sent: 14 September 2022 09:25

To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>>; [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>

Cc: [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[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]<mailto:[e-mail]%3cmailto:[e-mail]>>>; [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>

抄送: [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[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]<mailto:[e-mail]%3cmailto:[e-mail]>>>

Sent: 13 September 2022 07:38

To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>>; [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>

Cc: [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[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]<mailto:[e-mail]%3cmailto:[e-mail]>>

抄送: [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[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









_______________________________________________

OPSAWG mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/opsawg