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

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

Hi Rob,



Thanks for your accurate summary and further review. Please see inline.



Best regards,

Bo



-----Original Message-----
From: Rob Wilton (rwilton) [mailto:[e-mail]]
Sent: Friday, September 16, 2022 8:39 PM
To: [e-mail]; 'tom petch' <[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



My interpretation of the draft was basically this:



(1) The YANG topology model (rfc8345) can model both an underlay network and overlaying services.

(2) The base YANG topology model is missing some generic attributes to identify that a topology represents a service (e.g., service-type, vpn-id, vpn-service-topology).  I don't think that these attributes necessarily have anything to with PM, but they were added here because they were needed.  E.g., arguably they could have been put into a separate YANG module, but it would perhaps be too small to be worthwhile).

(3) The performance monitoring data can largely be gathered either at the network layer or at the service layer and this is really distinguished by which entry in the topology list the PM data nodes are being returned for.



Authors, is my understanding correct and accurate?



[Bo Wu] Thanks for the accurate summary.

On the second point, we agree that these VPN attributes are not PM data, but we think these are context information, for example, SLA requirements are different between hubs and between hub and spokes.



For (2), that does raise a further question:  In section 4.3, the "role" leaf has been placed under pm-attributes.  But again, I wonder whether this "role" is really just a generic description of the service endpoint.  Hence, would it be better to name this "vpn-service-role" and augment it directly under /nw:networks/nw:network/nw:node?  Possibly, it could be made conditional on /nw:networks/nw:network/nw:network-types/service/service-type



[Bo Wu] Thank you for pointing this out. Yes, we can take this out the PM attributes. How about we reconstructed YANG as follows:

  augment /nw:networks/nw:network/nw:node:

    +--rw node-type?       identityref

    +--ro entry-summary

       +--ro ipv4-num

       |  +--ro maximum-routes?        uint32

       |  +--ro total-active-routes?   uint32

       +--ro ipv6-num

       |  +--ro maximum-routes?        uint32

       |  +--ro total-active-routes?   uint32

       +--ro mac-num

          +--ro mac-num-limit?          uint32

          +--ro total-active-mac-num?   uint32

  augment /nw:networks/nw:network/nw:node:

+--rw role?   Identityref



For the complete change, please find at:

Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-10



Rob







> -----Original Message-----

> From: Adrian Farrel <[e-mail]<mailto:[e-mail]>>

> Sent: 16 September 2022 10:34

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

> <[e-mail]<mailto:[e-mail]>>; 'Wubo (lana)' <[e-mail]<mailto:[e-mail]>>; draft-ietf-

> [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

>

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

>

> 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]>>; draft-ietf-opsawg-yang-vpn-service-

> [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]>>;

> draft-ietf-opsawg-yang-vpn- [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]>>>; draft-ietf-

> [e-mail]<mailto:draft-ietf-opsawg-yang-<mailto:[e-mail]%3cmailto:draft-ietf-opsawg-yang->

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

> [e-mail]<mailto:[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]>>>; draft-ietf-

> [e-mail]<mailto:draft-ietf-opsawg-yang-<mailto:[e-mail]%3cmailto:draft-ietf-opsawg-yang->

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

> [e-mail]<mailto:[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]>>>; draft-ietf-

> [e-mail]<mailto:draft-ietf-opsawg-yang-<mailto:[e-mail]%3cmailto:draft-ietf-opsawg-yang->

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

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

> [e-mail]<mailto:[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