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

[tom petch <[e-mail]>]

From: Rob Wilton (rwilton) <[e-mail]>
Sent: 23 September 2022 12:53

Hi Tom,

Perhaps you can suggest some text/clarifications and the authors could consider it as part of the IETF last-call?

<tp>
Rob

Consistency is my biggest concern with -10.  Search on 'underlay' and I see 
underlay network
underlay networks
underlay link
underlay technology
underlay-tunnel
underlay tunnels
underlay transport type
underlay network instances
underlay network links 
underlay network termination  points 

which leaves me uncertain, confused even and this I think should be addressed.  I see similar variation in the use of 'overlay, 'VPN', 'service'.  

The difference between 'network' and 'networks' may be slight but I find it material.  The I-D talks of Layer 3 and Layer 2 in a stack.  My sense of the I-D is a focus on a L2VPN over a Layer 2 network.  Layer 3 and L3VPN get a mention but  L3VPN will have a Layer 3 underlay network which will have a Layer 2 underlay network but in places, the use of 'network' singular suggests that this is not what the model is about, that the model only countenances a single underlay network to a service network.  One of the changes in the I-D was the augment of 'link' becoming a list, that there might be more than one link involved, and I have the same uncertainty about 'network'. Is it just the one underlay and service or more than one and if more than one, what are the relationships?  I do not know .  It is the sort of uncertainty that some Genart reviewers are good at spotting so I will wait to see what else Last Call brings up.

Tom Petch
Thanks,
Rob


> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: 23 September 2022 12:20
> To: Rob Wilton (rwilton) <[e-mail]>; 'Wubo (lana)'
> <[e-mail]>; draft-ietf-opsawg-yang-vpn-service-
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-yang-vpn-service-pm-
> 09
>
> From: Adrian Farrel <[e-mail]>
> 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 <[e-mail]> On Behalf Of tom petch
> Sent: 15 September 2022 11:37
>
> From: OPSAWG <[e-mail]> on behalf of Rob Wilton
> (rwilton) <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]>
> 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:[e-mail]]
> 发送时间: 2022年9月14日 22:53
>
> Hi Bo, authors,
>
> Okay, thanks for the clarifications.  Please see inline …
>
>
> From: Wubo (lana)
> <[e-mail]<mailto:[e-mail]>>
> Sent: 14 September 2022 15:31
> To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:draft-ietf-
> [e-mail]>
>
>
> 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
>
> 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
>
> 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
>
> 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
>
> Hi Rob,
>
> Many thanks for your thoughtful review. Please see inline.
>
> Thanks,
>
> Bo
>
>
> -----邮件原件-----
> 发件人: Rob Wilton (rwilton) [mailto:[e-mail]]
> 发送时间: 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
>