Hi Adrian, Thanks for your review and comments. Please see inline.
Thanks, Bo -----邮件原件----- 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Adrian Farrel 发送时间: 2021年2月3日 7:09 收件人: 'Joe Clarke (jclarke)' <jclarke=40cisco....@dmarc.ietf.org>; opsawg@ietf.org 主题: Re: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm Hi Joe, I think this document fills a hole in the set of YANG models we have for managing and operating services over our network, and I'd like the WG to pick it up and polish it. I commit to doing a review or two as the draft advances. To kick that off there are a few comments below. None of these needs to be addressed before adoption. Best, Adrian --- It is unclear to me from Section 1 whether this document is intended to be limited to L3VPNs or applies to all VPNs. The very first sentence gives a strong hint that the scope is restricted to L3VPN, but I think that is not the intention. [Bo]Thanks for pointing this out. The intention is to support both L3VPN and L2VPN, and we will fix section 1 to reflect this. --- Maybe Figure 1 should be set in the context of RFC 8309. In particular, s/Service Network Models/Network Service Models/ But it might also be nice to include a reference to 8309 to help give meaning to the figure. [Bo] Thanks, will add RFC 8309 as the context. --- Looking at... +--ro inbound-octets? yang:counter64 +--ro inbound-unicast? yang:counter64 +--ro inbound-nunicast? yang:counter64 +--ro inbound-discards? yang:counter32 +--ro inbound-errors? yang:counter32 +--ro inbound-unknown-protocol? yang:counter32 +--ro outbound-octets? yang:counter64 +--ro outbound-unicast? yang:counter64 +--ro outbound-nunicast? yang:counter64 +--ro outbound-discards? yang:counter32 +--ro outbound-errors? yang:counter32 I tend to agree that there are likely to be an order of magnitude fewer discards and errors than legitimate packets, but I can also consider times (such as during attacks) then every packet is in error or is discarded. I think it would be wise (and possibly helpful) to have all of the counters at 64bits. This would also mean that the four counters under loss-statistics should also be counter64. [Bo] The counters currently follow the definition of ietf-interfaces YANG. Your suggestion to consider additional use case also makes sense, we will expand those counters. -----Original Message----- From: OPSAWG <opsawg-boun...@ietf.org> On Behalf Of Joe Clarke (jclarke) Sent: 29 January 2021 14:18 To: opsawg@ietf.org Subject: [OPSAWG] CALL FOR ADOPTION: draft-www-opsawg-yang-vpn-service-pm Hello, WG. The draft-www-opsawg-yang-vpn-service-pm (A YANG Model for Network and VPN Service Performance Monitoring) work has been steadily progressing with the other VPN network model work. This was presented last at IETF 109 (https://datatracker.ietf.org/doc/slides-109-opsawg-a-yang-model-for-network -and-vpn-service-performance-monitoring/), and there has been some recent discussion on list that has been addressed by the authors. We would like to know if the working group wants to formally adopt this work. Please respond with your comments and thoughts on the draft. We will conduct a two week CFA, concluding on February 12, 2021. Joe (on behalf of co-chairs) _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
