Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

[Rob Wilton (rwilton)]

Hi Bo,

I think that “limit-number” name makes more sense in the context of the other 
peer leaves around it when it is defined under “mac-addr-limit”, i.e., the 
“time-interval”, and what action is being taken.

My “no hats” opinion is that I would still go for consistency with the other 
counters under entry-summary.  E.g., using the same naming convention between 
the “maximum” and the “active”, and between v4, v6 and mac addresses.  If it 
helps you could also make the relationship to mac-policies/limit-number clear 
as part of the description.

But I’ll leave this entirely as the authors decision, this is just a minor 
non-blocking comment.

Regards,
Rob


From: Wubo (lana) 
Sent: 21 October 2022 10:41
To: Rob Wilton (rwilton) ; 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: adr...@olddog.co.uk; opsawg@ietf.org
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt


Hi Rob,



Thanks for the review and suggestion.



Per the naming of "mac-limit-number", we are considering to be consistent with 
L2NM definition:



https://datatracker.ietf.org/doc/html/rfc9291:

  | +--rw mac-policies

  | |  +--rw mac-addr-limit

  | |  |  +--rw limit-number?uint16

  | |  |  +--rw time-interval?   uint32

  | |  |  +--rw action?  Identityref



Do you think this makes sense?



Thanks,

Bo



-Original Message-
From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Sent: Friday, October 21, 2022 5:31 PM
To: 
draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: adr...@olddog.co.uk; 
opsawg@ietf.org
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt



Hi authors, shepherd,



Thanks for quickly posting a new version of 
draft-ietf-opsawg-yang-vpn-service-pm addressing the AD comments during the 
IESG review.



The changes all look good to me, except that I question one of the changes that 
were made (in response to one of Eric's comments I think):



 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-limit-number?   uint32

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



mac-num-limit has been changed from mac-num-limit to max-limit-number, but I 
was wondering whether you considered trying to make the names for the mac entry 
limits more consistent with the names of the IP route limits.  E.g.,



 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 maximum-mac-entries?   uint32

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



This is a just a suggestion.  Please let me know if you wish to make this 
change and post an updated draft, or whether you would like me to proceed with 
approving the -14 version.



Regards,

Rob





> -Original Message-

> From: internet-dra...@ietf.org 
> mailto:internet-dra...@ietf.org>>

> Sent: 21 October 2022 09:37

> To: adr...@olddog.co.uk; Rob Wilton (rwilton) 
> mailto:rwil...@cisco.com>>

> Subject: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-

> 14.txt

>

>

> A new version (-14) has been submitted for draft-ietf-opsawg-yang-vpn-

> service-pm:

> https://www.ietf.org/archive/id/draft-ietf-opsawg-yang-vpn-service-pm-14.txt

>

> Sub state has been changed to AD Followup from Revised ID Needed

>

>

> The IETF datatracker page for this Internet-Draft is:

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/

>

> Diff from previous version:

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

>

> IETF Secretariat.

>


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

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

[Wubo (lana)]

Hi Rob,



Thanks for the review and suggestion.



Per the naming of "mac-limit-number", we are considering to be consistent with 
L2NM definition:



https://datatracker.ietf.org/doc/html/rfc9291:

  | +--rw mac-policies

  | |  +--rw mac-addr-limit

  | |  |  +--rw limit-number?uint16

  | |  |  +--rw time-interval?   uint32

  | |  |  +--rw action?  Identityref



Do you think this makes sense?



Thanks,

Bo



-Original Message-
From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Sent: Friday, October 21, 2022 5:31 PM
To: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: adr...@olddog.co.uk; opsawg@ietf.org
Subject: RE: New Version Notification - 
draft-ietf-opsawg-yang-vpn-service-pm-14.txt



Hi authors, shepherd,



Thanks for quickly posting a new version of 
draft-ietf-opsawg-yang-vpn-service-pm addressing the AD comments during the 
IESG review.



The changes all look good to me, except that I question one of the changes that 
were made (in response to one of Eric's comments I think):



 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-limit-number?   uint32

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



mac-num-limit has been changed from mac-num-limit to max-limit-number, but I 
was wondering whether you considered trying to make the names for the mac entry 
limits more consistent with the names of the IP route limits.  E.g.,



 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 maximum-mac-entries?   uint32

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



This is a just a suggestion.  Please let me know if you wish to make this 
change and post an updated draft, or whether you would like me to proceed with 
approving the -14 version.



Regards,

Rob





> -Original Message-

> From: internet-dra...@ietf.org 
> mailto:internet-dra...@ietf.org>>

> Sent: 21 October 2022 09:37

> To: adr...@olddog.co.uk; Rob Wilton (rwilton) 
> mailto:rwil...@cisco.com>>

> Subject: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-

> 14.txt

>

>

> A new version (-14) has been submitted for draft-ietf-opsawg-yang-vpn-

> service-pm:

> https://www.ietf.org/archive/id/draft-ietf-opsawg-yang-vpn-service-pm-14.txt

>

> Sub state has been changed to AD Followup from Revised ID Needed

>

>

> The IETF datatracker page for this Internet-Draft is:

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/

>

> Diff from previous version:

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

>

> IETF Secretariat.

>


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

Re: [OPSAWG] New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-14.txt

[Rob Wilton (rwilton)]

Hi authors, shepherd,

Thanks for quickly posting a new version of 
draft-ietf-opsawg-yang-vpn-service-pm addressing the AD comments during the 
IESG review.

The changes all look good to me, except that I question one of the changes that 
were made (in response to one of Eric's comments I think):

 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-limit-number?   uint32
 +--ro total-active-mac-num?   uint32

mac-num-limit has been changed from mac-num-limit to max-limit-number, but I 
was wondering whether you considered trying to make the names for the mac entry 
limits more consistent with the names of the IP route limits.  E.g.,

 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 maximum-mac-entries?   uint32
 +--ro total-active-mac-entries?   uint32

This is a just a suggestion.  Please let me know if you wish to make this 
change and post an updated draft, or whether you would like me to proceed with 
approving the -14 version.

Regards,
Rob


> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: 21 October 2022 09:37
> To: adr...@olddog.co.uk; Rob Wilton (rwilton) 
> Subject: New Version Notification - draft-ietf-opsawg-yang-vpn-service-pm-
> 14.txt
> 
> 
> A new version (-14) has been submitted for draft-ietf-opsawg-yang-vpn-
> service-pm:
> https://www.ietf.org/archive/id/draft-ietf-opsawg-yang-vpn-service-pm-14.txt
> 
> Sub state has been changed to AD Followup from Revised ID Needed
> 
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/
> 
> Diff from previous version:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-14
> 
> IETF Secretariat.
> 

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

[OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-14.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-14.txt
  Pages   : 44
  Date: 2022-10-21

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

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


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