Hi Tom,
Thanks for your comments. Please see inline. Thanks, Bo -----Original Message----- From: tom petch [mailto:ie...@btconnect.com] Sent: Thursday, September 15, 2022 6:37 PM To: Rob Wilton (rwilton) <rwilton=40cisco....@dmarc.ietf.org>; Wubo (lana) <lana.w...@huawei.com>; draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org Cc: opsawg@ietf.org Subject: Re: AD review of draft-ietf-opsawg-yang-vpn-service-pm-09 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). Bo: Thanks for the comments. The authors has designed this model with the following considerations: 1) This model is a complementary performance monitoring model for both RFC8345, and LxNM (e.g. RFC8299 L3NM ), not just for custom VPN service. 2) Following the design method of RFC8345, this model could be used for both underlay networks and overlay VPN networks. 3) The PM metrics and counters of the underlay network are the same as those of the VPN network, such as the delay, jitter, and loss of links or overlay links (tunnels) and the counters of physical interfaces or VPN access interfaces (e.g. VLAN interfaces). We updated the draft to try to clarify the above, please see Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-10 Thanks, Bo 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 To: Rob Wilton (rwilton) <rwil...@cisco.com>; draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org Cc: opsawg@ietf.org 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:rwil...@cisco.com] 发送时间: 2022年9月14日 22:53 收件人: Wubo (lana) <lana.w...@huawei.com<mailto:lana.w...@huawei.com>>; draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org> 抄送: opsawg@ietf.org<mailto:opsawg@ietf.org> 主题: 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) <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> Cc: opsawg@ietf.org<mailto:opsawg@ietf.org> 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:rwil...@cisco.com] 发送时间: 2022年9月14日 17:18 收件人: Wubo (lana) <lana.w...@huawei.com<mailto:lana.w...@huawei.com>>; draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org> 抄送: opsawg@ietf.org<mailto:opsawg@ietf.org> 主题: 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) <lana.w...@huawei.com<mailto:lana.w...@huawei.com>> Sent: 14 September 2022 09:25 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> Cc: opsawg@ietf.org<mailto:opsawg@ietf.org> 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:rwil...@cisco.com] 发送时间: 2022年9月13日 17:24 收件人: Wubo (lana) <lana.w...@huawei.com<mailto:lana.w...@huawei.com>>; draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org> 抄送: opsawg@ietf.org<mailto:opsawg@ietf.org> 主题: 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) <lana.w...@huawei.com<mailto:lana.w...@huawei.com>> Sent: 13 September 2022 07:38 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> Cc: opsawg@ietf.org<mailto:opsawg@ietf.org> 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:rwil...@cisco.com] 发送时间: 2022年9月9日 18:43 收件人: draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service-pm....@ietf.org> 抄送: opsawg@ietf.org<mailto:opsawg@ietf.org> 主题: 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
