Hi Tom, Perhaps you can suggest some text/clarifications and the authors could consider it as part of the IETF last-call?
Thanks, Rob > -----Original Message----- > From: tom petch <ie...@btconnect.com> > Sent: 23 September 2022 12:20 > To: Rob Wilton (rwilton) <rwil...@cisco.com>; 'Wubo (lana)' > <lana.w...@huawei.com>; draft-ietf-opsawg-yang-vpn-service- > pm....@ietf.org; adr...@olddog.co.uk > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-pm- > 09 > > From: Adrian Farrel <adr...@olddog.co.uk> > Sent: 16 September 2022 10:33 > > 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. > > 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. > > <tp> > > Adrian > > As I expect you will have seen, I took a look at -10 and still get confused. > It > seems that several different terms get used and I am left uncertain as to > whether or not it is just two concepts,, 'underlay networks and overlay VPN > services' to quote the Abstract, or if there is more involved. > > From your discussion with the authors I think just two, but I do not find the > body of the I-D clear on that. > Tom Petch > > Cheers, > Adrian > > -----Original Message----- > From: OPSAWG <opsawg-boun...@ietf.org> On Behalf Of tom petch > Sent: 15 September 2022 11:37 > > From: OPSAWG <opsawg-boun...@ietf.org> on behalf of Rob Wilton > (rwilton) <rwilton=40cisco....@dmarc.ietf.org> > 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) <lana.w...@huawei.com> > Sent: 15 September 2022 03:17 > > 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:rwil...@cisco.com] > 发送时间: 2022年9月14日 22:53 > > Hi Bo, authors, > > Okay, thanks for the clarifications. Please see inline … > > > From: Wubo (lana) > <lana.w...@huawei.com<mailto:lana.w...@huawei.com>> > Sent: 14 September 2022 15:31 > To: Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>>; > draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org<mailto:draft-ietf- > opsawg-yang-vpn-service-pm....@ietf.org> > > > Hi Rob, > > Thanks again for your review. Please find our reply inline. > > Thanks, > Bo > > 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] > 发送时间: 2022年9月14日 17:18 > > 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) > <lana.w...@huawei.com<mailto:lana.w...@huawei.com>> > Sent: 14 September 2022 09:25 > > Hi Rob, > > Thank again for your deep review. Please find our response inline for the > open points. > > Best regards, > Bo > > > 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] > 发送时间: 2022年9月13日 17:24 > > 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) > <lana.w...@huawei.com<mailto:lana.w...@huawei.com>> > Sent: 13 September 2022 07:38 > > Hi Rob, > > Many thanks for your thoughtful review. Please see inline. > > Thanks, > > Bo > > > -----邮件原件----- > 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] > 发送时间: 2022年9月9日 18:43 > > 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
