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