Re: [OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early code point allocation

[Joe Clarke (jclarke)]

Hey, Thomas.  I’m a wee bit nervous declaring stability since IETF 115 hasn’t 
happened yet, but I do think you’re on track, and I can request of the WG their 
thoughts as to whether there is consensus that early allocation is warranted.

So, I think a, b, and d from Section 2 are met (speaking for ADs on d).  I just 
want to make sure we’re not bit by anything at the ‘thon at 115.

In terms of process, once we are satisfied that c is met, it is on us (chairs) 
to request approval from the ADs.  You do not need to contact IANA.  If this is 
approved, we will make that request.

Joe

From: OPSAWG  on behalf of thomas.g...@swisscom.com 

Date: Friday, September 23, 2022 at 8:27 AM
To: opsawg-cha...@ietf.org 
Cc: opsawg@ietf.org , pierre.franc...@insa-lyon.fr 

Subject: [OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early 
code point allocation
Dear OPSAWG chairs,

We believe that the draft is reaching stable state. At IETF 115 hackathon in 
November we will have one open-source and one closed-source implementation of 
draft-ietf-opsawg-ipfix-srv6-srh-01.

Therefore we believe we are satisfying the conditions for early allocation of 
code points as described https://www.rfc-editor.org/rfc/rfc7120#section-2.

With your permission we would like to go ahead an get in contact with IANA and 
clarify Med's comments on the

srhFlagsIPv6
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.1

and

srhSegmentEndpointBehavior
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.11

registry commented at 
https://github.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/pull/15/commits/470424596d9eeaa368a497a1a53f19573b764df9

first and then go ahead with the IPFIX entity early allocation.

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

Re: [OPSAWG] AD review of draft-ietf-opsawg-sap-09

[mohamed.boucadair]

Hi Rob, 

Thank you for the review. The changes can be tracked at: 
https://tinyurl.com/sap-latest

Please note that I made a change to better allow for reuse of the SAP 
information in other modules (this can be tracked here: 
https://github.com/IETF-OPSAWG-WG/lxnm/commit/e8b406d7fad5225dd84ad7ff03f6da446eae6736).
 

Please see inline for more context. 

Cheers,
Med

> -Message d'origine-
> De : Rob Wilton (rwilton) 
> Envoyé : vendredi 23 septembre 2022 14:01
> À : draft-ietf-opsawg-sap@ietf.org; opsawg@ietf.org
> Objet : AD review of draft-ietf-opsawg-sap-09
> 
> Hi authors, WG,
> 
> Thank you for this document.  I also think that this document is
> well written and in good shape, and I mostly found the
> explanations and examples clear.  There were two specific points
> that I found slightly confusing related to differentiating between
> SAPs in use, and those that are not, and also parent interfaces
> also be listed as SAPs, details below.

[Med] Thanks

> 
> Moderate level comments:
> 
> (1) p 10, sec 5.  SAP Module Tree Structure
> 
>   SAPs that are associated with the interfaces that are
> directly
>   hosting services, interfaces that are ready to host per-
> service
>   sub-interfaces (but not yet activated), or service that are
>   already instantiated on sub-interfaces are listed as SAPs.
> 
> >From the model, is isn't clear to me how different differentiates
> between a SAP that has been pre-provisioned to potentially be used
> for a service in future, v.s., one is that is actively
> provisioned.

[Med] This is inferred from the service-status=down for these SAPs.


  I think that it would be helpful if these two cases
> can be clearly distinguished.  Note, I have made a similar comment
> related to appendix D about identifying a "free" SAP.

[Med] Added this NEW to the appendix: 

"SAPs that are ready to host per-service (but not yet activated) are identified 
by the "service-status" set to "ietf-vpn-common:op-down"."

> 
> 
> (2) p 28, sec Appendix B.  A Simple Example of SAP Network Model:
> Node Filter
> 

[Med] Please note "Simple" in the title :-)

>A service orchestrator can query what services are provided on
> which
>SAPs of PE1 from the network controller by sending, e.g., a GET
>RESTCONF request.  Figure 9 shows the body of the RESTCONF
> response
>that is received from the network controller.
> 
> In this example, you have GE0/6/4 as being ready to host SAPs, but
> I could equally imagine that given GE0/6/4 is just a UNI, then you
> may not want the parent interface to be available to host SAPs
> directly at all.  I.e., it may always the case that sub-interfaces
> are used as SAPs.  Hence, did you consider whether it makes sense
> for there to be a different category of SAP service-types for
> UNI's and NNI's that don't host services directly on the
> interface, but always on sub-interfaces?

[Med] Yes, we do need this for the LxVPN case. 

  Related to this, it
> feels slightly strange to me to have GE0/6/4 listed under both
> l3vpn and vpls SAP lists.

[Med] Actually there are attached to distinct sub-interfaces:   

   Also, let us assume that, for
   the SAPs that are associated with the physical interface "GE0/6/4",
   VPLS and L3VPN services are activated on the two sub-interfaces
   "GE0/6/4.1" and "GE0/6/4.2", respectively.

Updated the example to align with this text. 

  Having the same information twice in
> the data model introduces the risk that a device could export
> inconsistent information and hence it hard for the customer to
> know which data is accurate.  I can understand why having it twice
> might be convenient, but having an indication that it is actually
> just a container node for SAPs rather than a SAP itself might be
> better.
> 
> 
> 
> Minor level comments:
> 
> (3) p 3, sec 3.  Sample SAP Network Model Usage
> 
>Management operations of a service provider network can be
> automated
>using a variety of means such as interfaces based on YANG
> modules
>[RFC8969].
> 
> Would a reference to NETCONF and potentially RESTCONF be helpful
> here in addition to RFC8969?
> 

[Med] They are indirectly cited via 8969, but does not harm to have explicit 
pointers.

> 
> (4) p 4, sec 3.  Sample SAP Network Model Usage
> 
>The service orchestration layer does not need to know about the
>internals of the underlying network (e.g., P nodes).
> 
> Would "all the internals" be better than just "internals".  I.e.,
> presumably the service orchestration layer probably does need to
> know about some of the internals of the underlying network.
> 

[Med] Indeed.

> 
> (5) p 10, sec 5.  SAP Module Tree Structure
> 
>These service types build on the types that are already defined
> in
>[RFC9181] and additional types that are defined in this
> document.
>Other service types can be defined in future YANG modules, if
> needed.
> 
> In future YANG modules, or perhaps also future versions of the
> YANG model 

Re: [OPSAWG] Last Call: (A YANG Model for Network and VPN Service Performance Monitoring) to Proposed Standard

[Wubo (lana)]

Hi Tom,



Thanks for your careful review. We have posted rev-11. Please see if this 
version addresses your comments.

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



Please also see inline for the detailed reply.

Thanks,

Bo



-Original Message-

From: tom petch [mailto:daedu...@btconnect.com]

Sent: Thursday, September 22, 2022 7:24 PM

To: last-c...@ietf.org

Cc: adr...@olddog.co.uk; opsawg@ietf.org; opsawg-cha...@ietf.org; 
draft-ietf-opsawg-yang-vpn-service...@ietf.org

Subject: Re: Last Call:  (A YANG 
Model for Network and VPN Service Performance Monitoring) to Proposed Standard



On 20/09/2022 17:24, The IESG wrote:

>

> The IESG has received a request from the Operations and Management

> Area Working Group WG (opsawg) to consider the following document: -

> 'A YANG Model for Network and VPN Service Performance Monitoring'

> as Proposed Standard





I struggled to understand what this I-D offered until the AD Review where the 
AD had issues similar to mine.  Even now, I am unclear if I understand it; the 
problem is wording and inconsistent use thereof.



In many places, the I-D says

'This document  defines a YANG module for performance monitoring (PM) of both 
underlay networks and overlay VPN services '

and it is that 'both' that I think starts to lead the reader, or at least me, 
up the garden path.



s.4.2 says

The model can be used for performance monitoring both for the

underlay network and the VPN services.  The two would be separate

entries in the network list [RFC8345].



and then talks of  the effect of the  "service" presence container being absent 
or present, which would doubtless twitch the nostrils of a YANG Doctor.



What it is saying, I think, is that the YANG module

- either provides data for PM of a VPN service

- or provides data for PM for the network itself but cannot do both, except in 
the sense that the YANG model in a node may contain multiple entries in the 
network list one or more of which is for a VPN service and one or more of which 
is for a network itself and that Netconf, e.g., can retrieve data for both in a 
single 'get'.  I think that the use of 'both' above is a stretch for that use 
of the word, more precisely it is either VPN service or network itself.



Bo: Thanks for the comments. But the module really covers the both, though the 
network or VPN service PM instances can be accessed through separate network 
list entries.



The rest of the I-D increases my confusion.



s.4

' The performance monitoring data augments the service topology as shown in 
Figure 2.'

Figure 2 has no mention of service.  Perhaps the reader must infer that what is 
meant is

The YANG module for performance monitoring data augments the YANG module for 
service topology - i.e. ietf-network, ietf-network-topology -



Bo: Thanks for pointing this out. Yes. Here is the change of new revision:

OLD:

   This document defines the YANG module, "ietf-network-vpn-pm", which

   is an augmentation to the "ietf-network" and "ietf-network-topology"

   modules.



   The performance monitoring data augments the service topology as

   shown in Figure 2.



NEW:

   This document defines the YANG module, "ietf-network-vpn-pm", which

   is an augmentation to the "ietf-network" and "ietf-network-topology"

   modules as shown in Figure 2.

END





The presence container alluded to above appears as

'  container service {

  presence

"Presence of the container indicates a service

 topology, absence of the container indicates an

 underlay network.";  '

The use of service topology here seems at odds with that in s.4.2 but later, in 
several places, there is

when '../nw:network-types/nvp:service' {

  description

"Augments only for VPN node attributes."; Well no, the augments 
only occurs when 'service' is present and that has just been defined as 
'Presence of the container indicates a service topology'; seems contradictory 
here and in several places.

Bo: Yes. I agree this is not clear enough. Fixed in the new revision.





Also, in most places, it is 'underlay tunnel' or 'underlay-tunnel'

whereas here it is 'underlay network' as it is in the Abstract and that, for 
me, again, leads the reader - me - astray.



Bo: Agree this is confusing. I have changed "underlay tunnel " to "vpn-tunnel" 
in most places and replaced one with underlay links.



In a similar vein, I see

  leaf start-time { type yang:date-and-time;

config false; description

  "The time that the current measurement started."; The YANG 
type is date and time so that is 'The date and time ..'.  I often see 
monitoring at the same time every day which is what the description might mean 
but does not.



Bo: Thanks. Fixed with "The date and time the measurement last started."



Likewise

  leaf unit-value {

  

[OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-01 - RFC 7120 IANA early code point allocation

[Thomas.Graf]

Dear OPSAWG chairs,

We believe that the draft is reaching stable state. At IETF 115 hackathon in 
November we will have one open-source and one closed-source implementation of 
draft-ietf-opsawg-ipfix-srv6-srh-01.

Therefore we believe we are satisfying the conditions for early allocation of 
code points as described https://www.rfc-editor.org/rfc/rfc7120#section-2.

With your permission we would like to go ahead an get in contact with IANA and 
clarify Med's comments on the

srhFlagsIPv6
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.1

and

srhSegmentEndpointBehavior
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-05#section-4.11

registry commented at 
https://github.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/pull/15/commits/470424596d9eeaa368a497a1a53f19573b764df9

first and then go ahead with the IPFIX entity early allocation.

Best wishes
Thomas


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-11.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-11.txt
  Pages   : 41
  Date: 2022-09-23

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

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


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

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-01.txt

[Thomas.Graf]

Dear OPSAWG, SPRING and 6MAN,

Version -01 of draft-ietf-opsawg-ipfix-srv6-srh has been published to address 
various comments from the lists since IETF 114. Many thanks for all who 
reviewed and contributed. This is much appreciated.

We added section 6.3, Multiple Segment Routing Headers in the Operational 
Considerations section to address off list feedback to clarify how IPFIX export 
should be supported when more then one SRH is present in the packet.

We would appreciate your review and comment on the changes of the -01 version.

We are going to join the IETF 115 hackathon 
(https://wiki.ietf.org/en/meeting/115/hackathon) where we validate the first 
implementations. If you have interest to participate please feel free to ping 
me off list.

Best wishes
Thomas

-Original Message-
From: OPSAWG  On Behalf Of internet-dra...@ietf.org
Sent: Friday, September 23, 2022 1:19 PM
To: i-d-annou...@ietf.org
Cc: opsawg@ietf.org
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-01.txt


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   : Export of Segment Routing over IPv6 Information in IP 
Flow Information Export (IPFIX)
Authors : Thomas Graf
  Benoit Claise
  Pierre Francois
  Filename: draft-ietf-opsawg-ipfix-srv6-srh-01.txt
  Pages   : 26
  Date: 2022-09-23

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   Information Elements to identify a set of Segment Routing over IPv6
   (SRv6) related information such as data contained in a Segment
   Routing Header (SRH), the SRv6 control plane, and the SRv6 behavior
   that traffic is being forwarded with.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-01

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

smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] AD review of draft-ietf-opsawg-sap-09

[Rob Wilton (rwilton)]

Hi authors, WG,

Thank you for this document.  I also think that this document is well written 
and in good shape, and I mostly found the explanations and examples clear.  
There were two specific points that I found slightly confusing related to 
differentiating between SAPs in use, and those that are not, and also parent 
interfaces also be listed as SAPs, details below.

Moderate level comments:

(1) p 10, sec 5.  SAP Module Tree Structure

  SAPs that are associated with the interfaces that are directly
  hosting services, interfaces that are ready to host per-service
  sub-interfaces (but not yet activated), or service that are
  already instantiated on sub-interfaces are listed as SAPs.

>From the model, is isn't clear to me how different differentiates between a 
>SAP that has been pre-provisioned to potentially be used for a service in 
>future, v.s., one is that is actively provisioned.  I think that it would be 
>helpful if these two cases can be clearly distinguished.  Note, I have made a 
>similar comment related to appendix D about identifying a "free" SAP.


(2) p 28, sec Appendix B.  A Simple Example of SAP Network Model: Node Filter

   A service orchestrator can query what services are provided on which
   SAPs of PE1 from the network controller by sending, e.g., a GET
   RESTCONF request.  Figure 9 shows the body of the RESTCONF response
   that is received from the network controller.

In this example, you have GE0/6/4 as being ready to host SAPs, but I could 
equally imagine that given GE0/6/4 is just a UNI, then you may not want the 
parent interface to be available to host SAPs directly at all.  I.e., it may 
always the case that sub-interfaces are used as SAPs.  Hence, did you consider 
whether it makes sense for there to be a different category of SAP 
service-types for UNI's and NNI's that don't host services directly on the 
interface, but always on sub-interfaces?  Related to this, it feels slightly 
strange to me to have GE0/6/4 listed under both l3vpn and vpls SAP lists.  
Having the same information twice in the data model introduces the risk that a 
device could export inconsistent information and hence it hard for the customer 
to know which data is accurate.  I can understand why having it twice might be 
convenient, but having an indication that it is actually just a container node 
for SAPs rather than a SAP itself might be better.



Minor level comments:

(3) p 3, sec 3.  Sample SAP Network Model Usage

   Management operations of a service provider network can be automated
   using a variety of means such as interfaces based on YANG modules
   [RFC8969].

Would a reference to NETCONF and potentially RESTCONF be helpful here in 
addition to RFC8969?


(4) p 4, sec 3.  Sample SAP Network Model Usage

   The service orchestration layer does not need to know about the
   internals of the underlying network (e.g., P nodes).

Would "all the internals" be better than just "internals".  I.e., presumably 
the service orchestration layer probably does need to know about some of the 
internals of the underlying network.


(5) p 10, sec 5.  SAP Module Tree Structure

   These service types build on the types that are already defined in
   [RFC9181] and additional types that are defined in this document.
   Other service types can be defined in future YANG modules, if needed.

In future YANG modules, or perhaps also future versions of the YANG model 
defined in this document?


(6) p 11, sec 5.  SAP Module Tree Structure

  This data node can be used, for example, to decide whether an
  existing SAP can be (re)used to host a service or if a new sub-
  interface has to be instantiated.

So, is this field effectively also being used to determine if the SAP is in use?


(7) p 12, sec 5.  SAP Module Tree Structure

  When both a sub-interface and its parent interface are present,
  the status of the parent interface takes precedence over the
  status indicated for the sub-interface.

This seems strange to me.  E.g., if the parent-interface was up, but the 
sub-interface was administratively down then would you be expected to report 
the sap-status as up?  I would think that this should always be reporting the 
sub-interface state, but that the sub-interface state should inherit


(8) p 16, sec 6.  SAP YANG Module

 identity logical {
   base interface-type;
   description
 "Refers to a logical sub-interface that is typically
  used to bind a service. This type is used only
  if none of the other logical types can be used.";
 }

Perhaps clarify what you mean by "other logical types".  E.g., do you just mean 
loopback or irb, or does this include local-bridge as well?


(9) p 17, sec 6.  SAP YANG Module

 leaf peer-sap-id {
   type string;
   description
 "Indicates an identifier of the peer's termination
  identifier (e.g., Customer Edge (CE)). This
   

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

[Rob Wilton (rwilton)]

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 
> Sent: 23 September 2022 12:20
> To: Rob Wilton (rwilton) ; 'Wubo (lana)'
> ; 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 
> 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.
> 
> 
> 
> 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  On Behalf Of tom petch
> Sent: 15 September 2022 11:37
> 
> 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).
> 
> 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
> 
> 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. 

Re: [OPSAWG] Last Call: (A YANG Model for Network and VPN Service Performance Monitoring) to Proposed Standard

[tom petch]

Thinking some more ...

On 22/09/2022 12:24, tom petch wrote:

On 20/09/2022 17:24, The IESG wrote:


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'A
YANG Model
for Network and VPN Service Performance Monitoring'
as Proposed Standard


The problem starts with the title.  Does it meane

A YANG Model for Network Monitoring and VPN Service Performance Monitoring'
or perhaps
A YANG Model for Network Performance Monitoring and VPN Service 
Performance Monitoring

or perhaps
A  YANG Model for Network Service Performance Monitoring and VPN Service 
Performance Monitoring'

while if it was
A  YANG Model for Monitoring the Perfomance of a Network and a VPN Service
I would be in no doubt and it would be even clearer if it used the 
terminology of the Abstract, to whit
A YANG Model for Monitoring the Perfomance of an Overlay VPN Service and 
its Underlay Network



Tom Petch



I struggled to understand what this I-D offered until the AD Review
where the AD had issues similar to mine.  Even now, I am unclear if I
understand it; the problem is wording and inconsistent use thereof.

In many places, the I-D says
'This document  defines a YANG module for performance monitoring (PM) of
both underlay networks and overlay VPN services '
and it is that 'both' that I think starts to lead the reader, or at
least me, up the garden path.

s.4.2 says
The model can be used for performance monitoring both for the
underlay network and the VPN services.  The two would be separate
entries in the network list [RFC8345].

and then talks of  the effect of the  "service" presence container being
absent or present, which would doubtless twitch the nostrils of a YANG
Doctor.

What it is saying, I think, is that the YANG module
- either provides data for PM of a VPN service
- or provides data for PM for the network itself
but cannot do both, except in the sense that the YANG model in a node
may contain multiple entries in the network list one or more of which is
for a VPN service and one or more of which is for a network itself and
that Netconf, e.g., can retrieve data for both in a single 'get'.  I
think that the use of 'both' above is a stretch for that use of the
word, more precisely it is either VPN service or network itself.

The rest of the I-D increases my confusion.

s.4
' The performance monitoring data augments the service topology as
shown in Figure 2.'
Figure 2 has no mention of service.  Perhaps the reader must infer that
what is meant is
The YANG module for performance monitoring data augments the YANG
module for service topology - i.e. ietf-network, ietf-network-topology -

The presence container alluded to above appears as
'  container service {
  presence
"Presence of the container indicates a service
 topology, absence of the container indicates an
 underlay network.";  '
The use of service topology here seems at odds with that in s.4.2 but
later, in several places, there is
when '../nw:network-types/nvp:service' {
  description
"Augments only for VPN node attributes.";
Well no, the augments only occurs when 'service' is present and that has
just been defined as
'Presence of the container indicates a service topology';
seems contradictory here and in several places.

Also, in most places, it is 'underlay tunnel' or 'underlay-tunnel'
whereas here it is 'underlay network' as it is in the Abstract and that,
for me, again, leads the reader - me - astray.

In a similar vein, I see
  leaf start-time { type yang:date-and-time;
config false; description
  "The time that the current measurement started.";
The YANG type is date and time so that is 'The date and time ..'.  I
often see monitoring at the same time every day which is what the
description might mean but does not.

Likewise
  leaf unit-value {
type identityref {  base lime:time-unit-type;  }
default "lime:milliseconds";
description
  "Time units, where the options are s, ms, ns, etc.";
This is taken from  RFC8532 where the options are hours minutes seconds
milliseconds microseconds nanoseconds.  I think that the reader deserves
a more accurate description.

I see it as a clever idea to have one YANG module in two different roles
determined by a presence container - perhaps too clever for me.

Tom Petch




The IESG plans to make a decision in the next few weeks, and solicits
final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2022-10-04. Exceptionally,
comments may
be sent to i...@ietf.org instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.

Abstract


The data model for network topologies defined in RFC 8345 introduces
vertical layering relationships between networks that 

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

[tom petch]

From: Adrian Farrel 
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.



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  On Behalf Of tom petch
Sent: 15 September 2022 11:37

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

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

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, 

[OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-01.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   : Export of Segment Routing over IPv6 Information in IP 
Flow Information Export (IPFIX)
Authors : Thomas Graf
  Benoit Claise
  Pierre Francois
  Filename: draft-ietf-opsawg-ipfix-srv6-srh-01.txt
  Pages   : 26
  Date: 2022-09-23

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   Information Elements to identify a set of Segment Routing over IPv6
   (SRv6) related information such as data contained in a Segment
   Routing Header (SRH), the SRv6 control plane, and the SRv6 behavior
   that traffic is being forwarded with.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-01


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

Re: [OPSAWG] review of draft-ietf-opsawg-service-assurance-architecture-08

[Michael Richardson]

Benoit Claise  wrote:
> If you speak about RFC 7942, it mentions:

>We recommend that the Implementation Status section should be
> removed from Internet-Drafts before they are published as RFCs.


> So isn't sufficient to have this information in the write-up.  You can
> write down: "Huawei has a prototype implementation of this architecture
> and specifically of the YANG module"

Updated the shepherd review to day that.

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

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

[Benoit Claise]

Hi,

The issues are that:
1. we are redefining the scope field 
(https://datatracker.ietf.org/doc/html/rfc7011#section-3.4.2.1) for 
instance. Actually multiple identical scope fields in the flow records, 
which is not foreseen in the IPFIX spec.

2. we still depend on the order ... of the scope in this case.
    At this one is a MUST

   If a
   different order of Scope Fields would result in a Record having a
   different semantic meaning, then the order of Scope Fields MUST be
   preserved by the Exporting Process.

3. we start to put instance specific into fixed IE. RFC6313 is the 
answer but doesn't fly for data plane flows


Regards, Benoit

On 9/20/2022 3:00 PM, mohamed.boucad...@orange.com wrote:


Re-,

Yes, you got it.

Maybe it is simple to consider a new IE that carries in the first 8 
bits the routing type and the occurrence in the remaining 8 bits. 
Multiple instances can be then sent if needed. Another approach for 
encoding both the order and occurrence is to have an IE that prepends 
the types with the same type repeated when multiple instances are 
present.


Cheers,

Med

*De :*thomas.g...@swisscom.com 
*Envoyé :* mardi 20 septembre 2022 14:06
*À :* BOUCADAIR Mohamed INNOV/NET ; 
benoit.cla...@huawei.com; jclarke=40cisco@dmarc.ietf.org; 
opsawg@ietf.org

*Cc :* pierre.franc...@insa-lyon.fr
*Objet :* RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi Med,

You read my mind. If I read yours correctly you mean that there can be 
multiple extension headers which could be exposed each with one IE64 
ipv6ExtensionHeaders. What we don't know is how many times each header 
type occurs and the order in the packet. What is also missing is the 
distinguisher between the routing types. Correct?

Best wishes
Thomas

*From:*mohamed.boucad...@orange.com 
*Sent:* Tuesday, September 20, 2022 11:13 AM
*To:* Graf Thomas, INI-NET-TCZ-ZH1 ; 
benoit.cla...@huawei.com; jclarke=40cisco@dmarc.ietf.org; 
opsawg@ietf.org

*Cc:* pierre.franc...@insa-lyon.fr
*Subject:* ***Signed_Message*** RE: CALL FOR ADOPTION: 
draft-tgraf-opsawg-ipfix-srv6-srh


Hi Thomas,

This is a useful addition. Thanks.

A more general question is to check whether one can report the 
identity of the EHs that form the Header Chain, but this is not 
specific to this draft. The current ipv6ExtensionHeaders does not 
allow for that.


Cheers,

Med

*De :*thomas.g...@swisscom.com 
*Envoyé :* lundi 19 septembre 2022 16:47
*À :* BOUCADAIR Mohamed INNOV/NET ; 
benoit.cla...@huawei.com; jclarke=40cisco@dmarc.ietf.org; 
opsawg@ietf.org

*Cc :* pierre.franc...@insa-lyon.fr
*Objet :* RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi Med,

Benoit will feedback on your reply.

In the meanwhile I like to take the opportunity to get your feedback 
on an additional operational consideration section I added based on an 
off list feedback I received from a software developer implementing 
the draft document.


https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt 



5.3.  Multiple Segment Routing Headers

   [RFC8200] describes the support of multiple extension headers in one

   IPv6 packet.  Allowing the use of multiple SRH per SRv6 packet.  The

   export of the same IE multiple times in one data-record and data-

   template is supported and the order within the packet SHOULD be

   preserved in the IPFIX export according to Section 8 of [RFC7011].

   If the network node is not capable to export IPFIX for more than one

   SRH, it MUST export IPFIX for the active SRH.

Best wishes

Thomas

*From:*mohamed.boucad...@orange.com 
*Sent:* Monday, September 19, 2022 2:22 PM
*To:* Benoit Claise ; Graf Thomas, 
INI-NET-TCZ-ZH1 ; 
jclarke=40cisco@dmarc.ietf.org; opsawg@ietf.org

*Cc:* pierre.franc...@insa-lyon.fr
*Subject:* RE: CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

Hi Benoît,

Thank you for the follow-up.

Actually, the more I look into this, the more I’m convinced that we 
don’t need a new registry for the flags and that the statement “Values 
for this Information Element are listed in the "IPFIX IPv6 SRH Flags" 
registry” is restrictive (inaccurate(?)). The flags should be exported 
as ** observed ** not as set in the registry.


Think about discarded packets because some flags are set (including 
those already for which a meaning is already defined such as the O 
flag) while the processing of these flags is not supported by a 
router. In such cases, one use of the 

Re: [OPSAWG] comment for draft-ietf-opsawg-sap-09

[mohamed.boucadair]

Hi Asad,

Please see inline.

Cheers,
Med

De : Arafat, Asad (Nokia - DE/Stuttgart) 
Envoyé : jeudi 22 septembre 2022 17:29
À : BOUCADAIR Mohamed INNOV/NET ; opsawg@ietf.org
Cc : Arafat, Asad (Nokia - DE/Stuttgart) 
Objet : Re: comment for draft-ietf-opsawg-sap-09

Thanks for the explanations Med..

It brings me to another questions

  *   Is there any standard method to augment some parameter that not included 
in service dataModel (L2NM/L3NM). Ie: dhcp snooping?
[Med] L2NM/L3Nm can be augmented following rfc7950#section-4.2.8. You can write 
an I-D with the proposed augmentations and share them with the list.


  *   Appendix A in the draft made me curious, is there any standard that 
define service stitching?
[Med] I'm not aware of a generic model and would be surprised to see as I guess 
this depends on the service.

It could be inter-as option A or even L2VPN-to-L3VPN?

Cheers/Asad

From: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Date: Thursday, 22. September 2022 at 16:52
To: Arafat, Asad (Nokia - DE/Stuttgart) 
mailto:asad.ara...@nokia.com>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Subject: RE: comment for draft-ietf-opsawg-sap-09
Hi Asad,

Thank you for the comment.

I hear you. It is tempting to include such details into the SAP network model 
but we tried to avoid interfering with other device models or other network 
models (L3NM/L2NM). That's is why we have the following note in the draft:

   Advanced interface-specific data nodes are not included in the SAP
   model.  The interface identifiers listed in the SAP model can be used
   as filters to set or get such data using device models (e.g.,
   [RFC7224]).

For the particular case of L2NM/L3NM we do have the following:


  For example, 'sap-id' may be the VPN network access identifier in

  Section 7.6 of [RFC9182].  An example to illustrate the use of

  this attribute during service creation is provided in Appendix D.

...which means that the attachment circuit configuration will be directly 
included into the L2NM/L3NM while sap-id=vpn-network-access-id is used to 
correlate between the two.

I understand you want to do it in the other way around.

Cheers,
Med

De : OPSAWG mailto:opsawg-boun...@ietf.org>> De la 
part de Arafat, Asad (Nokia - DE/Stuttgart)
Envoyé : jeudi 22 septembre 2022 16:31
À : opsawg@ietf.org
Objet : [OPSAWG] comment for draft-ietf-opsawg-sap-09

Hi draft-ietf-opsawg-sap-09 authors

I have several comment regarding the draft.

Since I don't see a placeholder for configuration object that can be configured 
in the service attachment point. I believe it would be better to enrich the SAP 
model with the popular attachment circuit configuration of l2vpn and l3vpn, 
such as:

  *   Multicast protocol like IGMP(snooping), MLD(snooping)
  *   DHCP (snooping)
  *   IP/mac filter
  *   QOS policy
  *   OAM
  *   IP address
  *   Some extra fields can be reserved for arbitrarily usage

The use case that I can think of is when a Controller wanna config a service 
with L2NM or L3NM the following path can be augmented with the detail of SAP 
model


  *   
/l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service/l3nm:vpn-nodes/l3nm:vpn-node/l3nm:vpn-network-accesses
  *   
/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services/l2vpn-ntw:vpn-service/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses

Similar can also for the service configuration retrieval.


Cheers/Asad


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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