Re: [OPSAWG] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

[Benoit Claise]

Hi Med,

Thanks for your comments.

I visited IANA in Philly to validate this propose, but we could 
re-evaluate & discuss about it.


We need a registry because just telling that we take the value from 
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags 
is not sufficient as we also need to specify the following IPFIX fields:

- Abstract Data Type. (unsigned8 in this srhFlagsIPv6 case)
- Data Type Semantics (flags in srhFlagsIPv6 case)

Now, if your point is that we don't really to mention the initial values ...

   Initial values in the registry are defined by the table
  below.

   ++---+--+
  | Value  |    Description    | Reference   |
   ++---+--+
  | 0-1    | Unassigned |  |
   ++---+--+
  | 2  | O-flag    |
   [RFC-ietf-6man-spring-srv6-oam-13]  |
   ++---+--+
  | 3-7    | Unassigned |  |
   ++---+--+

   Table 2: "IPFIX IPv6 SRH Flags" registry

... I agree it's not strictly necessary but it helps (me/the IPFIX 
experts) to understand, from this document, which type of values are 
currently available.


See inline.

On 9/16/2022 9:34 AM, mohamed.boucad...@orange.com wrote:


Hi Thomas,

Thank you for preparing this revised version.

I think almost all my comments are addressed in this version. However, 
I still don’t see the need to have new registries that only mirror 
existing ones. For example, and unless I missed some subtleties, it 
would be sufficient to say that the flag values are taken from 
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags 
rather 
than adding the following in the I-D:


++---+--+

  | Value  |    Description |  Reference   |

++---+--+

  | 0-1    | Unassigned |  |

++---+--+

  | 2  | O-flag    | [RFC-ietf-6man-spring-srv6-oam-13]  |

++---+--+

  | 3-7    | Unassigned |  |

++---+--+

   Table 2: "IPFIX IPv6 SRH Flags" registry

which is similar in term of encoding and values as what was set by 
RFC9256:


   IANA has registered the following in the "Segment Routing Header
   Flags" subregistry in the "Internet Protocol Version 6 (IPv6)
   Parameters" registry:
 +=+=+===+
 | Bit | Description | Reference |
+=+=+===+
  | 2   | O-flag  |RFC 9259  
   |
  +-+-+---+

BTW, I guess you initially meant:

NEW:

   Table 2: "IPFIX IPv6 SRH Flags" registry

   Note to IANA:  Add a note to the "Segment Routing Header Flags" 
registry


  so that new values are echoed in the new "IPFIX IPv6 SRH Flags”

You are right (since 
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-flags 
is "IETF review" while 
https://www.iana.org/assignments/ipfix/ipfix.xhtml is "Expert Review")




instead of CURRENT:

   Table 2: "IPFIX IPv6 SRH Flags" registry

   Note to IANA:  Add a note to the registry so that new values are

  echoed in the new "IPFIX SRv6 EndPoint Behavior

The same comment applies for the values that can be directly taken 
from 
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors.




Yes
OLD:

   Table 4: "IPFIX SRV6 Endpoint Behavior" registry


   Note to IANA:  Add a note to the registry so that new values are
  echoed in the new "IPFIX SRv6 EndPoint Behavior

NEW:

   Table 4: "IPFIX SRV6 Endpoint Behavior" registry


   Note to IANA:  Add a note to the "IPFIX SRV6 Endpoint Behavior" 
registry so that new values are

  echoed in the new "IPFIX SRv6 EndPoint Behavior

Regards, Benoit


Cheers,

Med

*De :*thomas.g...@swisscom.com 
*Envoyé :* jeudi 15 septembre 2022 20:08
*À :* BOUCADAIR Mohamed INNOV/NET ; 
jclarke=40cisco@dmarc.ietf.org; opsawg@ietf.org

*Cc :* benoit.cla...@huawei.com; pierre.franc...@insa-lyon.fr
*Objet :* RE: CALL 

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

[Wubo (lana)]

Hi Rob,



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



Best regards,

Bo



-Original Message-
From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Sent: Friday, September 16, 2022 8:39 PM
To: adr...@olddog.co.uk; 'tom petch' ; Wubo (lana) 
; draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: opsawg@ietf.org
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 mailto:adr...@olddog.co.uk>>

> Sent: 16 September 2022 10:34

> To: 'tom petch' mailto:ie...@btconnect.com>>; Rob Wilton 
> (rwilton)

> mailto:rwil...@cisco.com>>; 'Wubo (lana)' 
> mailto:lana.w...@huawei.com>>; draft-ietf-

> opsawg-yang-vpn-service-pm@ietf.org

> Cc: opsawg@ietf.org

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

> 

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

[Wubo (lana)]

Hi Adrian, all,



Many thanks for your shepherd. Please see inline.



Best regards,

Bo



-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Friday, September 16, 2022 5:34 PM
To: 'tom petch' ; 'Rob Wilton (rwilton)' 
; Wubo (lana) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: opsawg@ietf.org
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 mailto:opsawg-boun...@ietf.org>> On 
Behalf Of tom petch

Sent: 15 September 2022 11:37

To: Rob Wilton (rwilton) 
mailto:rwilton=40cisco@dmarc.ietf.org>>;
 Wubo (lana) mailto:lana.w...@huawei.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org

Cc: opsawg@ietf.org

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



From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Rob Wilton (rwilton) 
mailto: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.





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) mailto:lana.w...@huawei.com>>

Sent: 15 September 2022 03:17

To: Rob Wilton (rwilton) mailto: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 

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

[Wubo (lana)]

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) ; Wubo (lana) 
; 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  on behalf of Rob Wilton (rwilton) 


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.





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) 

Sent: 15 September 2022 03:17

To: Rob Wilton (rwilton) ; 
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) mailto:lana.w...@huawei.com>>; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org

抄送: 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) 

[OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : A YANG Model for Network and VPN Service Performance 
Monitoring
Authors : Bo Wu
  Qin Wu
  Mohamed Boucadair
  Oscar Gonzalez de Dios
  Bin Wen
  Filename: draft-ietf-opsawg-yang-vpn-service-pm-10.txt
  Pages   : 41
  Date: 2022-09-17

Abstract:
   The data model for network topologies defined in RFC 8345 introduces
   vertical layering relationships between networks that can be
   augmented to cover network and service topologies.  This document
   defines a YANG module for performance monitoring (PM) of both
   underlay networks and overlay VPN services that can be used to
   monitor and manage network performance on the topology of both
   layers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-vpn-service-pm-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-10


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg