Hi Eric, Thanks for your suggestion. As OPSAWG also recommended that the model should be consistent with RFC 8343 (Interface YANG), we would like to use separate multicast and broadcast counters as you suggested earlier and will update in the next revision.
Thanks, Bo From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] Sent: Tuesday, October 18, 2022 5:39 PM To: Wubo (lana) <lana.w...@huawei.com>; mohamed.boucad...@orange.com; The IESG <i...@ietf.org> Cc: draft-ietf-opsawg-yang-vpn-service...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; adr...@olddog.co.uk Subject: Re: Éric Vyncke's No Objection on draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT) Hello Bo, Thanks for your reply, may I still wonder why not naming this leaf as ``inbound-bum` ? Again, nothing blocking, just trying to improve Regards -éric From: "Wubo (lana)" <lana.w...@huawei.com<mailto:lana.w...@huawei.com>> Date: Tuesday, 18 October 2022 at 11:08 To: Eric Vyncke <evyn...@cisco.com<mailto:evyn...@cisco.com>>, "mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>" <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>, The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc: "draft-ietf-opsawg-yang-vpn-service...@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service...@ietf.org>" <draft-ietf-opsawg-yang-vpn-service...@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service...@ietf.org>>, "opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>" <opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>>, "opsawg@ietf.org<mailto:opsawg@ietf.org>" <opsawg@ietf.org<mailto:opsawg@ietf.org>>, "adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>" <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> Subject: RE: Éric Vyncke's No Objection on draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT) Hi Eric, Thanks for the comments. Regarding the last issue, please see inline. I have removed the part that we agreed on. Thanks, Bo -----Original Message----- From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] Sent: Tuesday, October 18, 2022 3:23 PM To: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>; The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc: draft-ietf-opsawg-yang-vpn-service...@ietf.org<mailto:draft-ietf-opsawg-yang-vpn-service...@ietf.org>; opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk> Subject: Re: Éric Vyncke's No Objection on draft-ietf-opsawg-yang-vpn-service-pm-13: (with COMMENT) Hello Med, Thank you for such a prompt reply. While my comments were non-blocking, I really appreciate your time to reply. I agree with most of them, for the remaining look below for EV> (and feel free to ignore) Regards -éric On 18/10/2022, 09:07, "mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>" <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> wrote: Hi Éric, Thank you for the comments. Please see inline. I let my co-authors further comment as appropriate. Cheers, Med ... %< a lot of text elided .... > > ### Section 4.4 > > Would it be useful to split `inbound-non-unicast` into broadcast > and multicast ? > [Med] This was raised also by Rob during his review (https://mailarchive.ietf.org/arch/msg/opsawg/bGqJ7V2EvVzJv7H-Xi2Y-jIOsKw/). Please search for "bum". EV> still unsure though ;-) [Bo Wu] This definition takes L2VPN into account, e.g. rfc7432 (BGP MPLS-Based Ethernet VPN) needs to Identify and process Broadcast, unknown unicast, or multicast (BUM) traffic. Hope this helps to clarify.
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
