Hi Sergey, Thanks for your review and comments. Please find my response inline with tag [SD].
Thanks Saumya. From: Sergey Fomin [mailto:i...@sergey.dev] Sent: Saturday, September 4, 2021 8:07 AM To: Dikshit, Saumya <saumya.diks...@hpe.com>; bess@ietf.org Subject: RE: [bess] FW: New Version Notification for draft-saum-bess-dampening-backoff-00.txt Hi authors, I have a few general comments 1. The introduction (section 2) is confusing. You start by saying that RFC7432 addresses the duplication issue (which is mostly right), but then start to describe “an unending cycle”.. And just to be clear: RFC7432 does not prescribe an automatic recovery action, it’s always a choice (also relevant to p.3 below) [SD]I agree, that’s open ended as far as RFC7432 is concerned. That’s what we intend to call-out/address in this document. 1. I’m not entirely sure why did you add section 2.2 with a broadcast loop via backdoor link to this draft? [SD] My intention was not to show a backdoor path but a network loop on the same PE device (VTEP). A loops between, let’s say, two layer-2 tenant ports (switchports) configured over same VLAN/bridge-domain on the PEs. I will update this in the next revision. [SD]This issue is observed in existing EVPN deployments, wherein, the Vxlan fabric operator does not have any hold/control on the way tenant network is managed/operated. And any such errors like l2-looping will have an impact on the shared fabric as it will lead to never ending mac movement. Anyhow this problem was addressed in draft-snr-bess-evpn-loop-protect (there are a few implementations), and became a part of the updated -7432bis draft. [SD] For backdoor links, problem for sure is addressed via method mentioned in draft-snr-bess-evpn-loop-protect and merged with 7432. Let me go through draft-snr-bess-evpn-loop-protect once more to firm up the author’s understanding. 1. The problem statement (section 4) is very vague and hardly justifies the existence of this draft: > It is observed that plethora of implementations defreeze the MAC in > deterministic > time after freezing it with a positive assumption that admin shall > take corrective action meanwhile. Else, the subsequent unfreeze > shall end up in the same cycle of MAC Duplication detection and > freezing the MAC. It is an implementation detail, and nothing prevents you from doing it in a configurable (or any other way) you want. [SD] If I see it the other way, then “count” and “timer’ based implementation for arriving at MAC-duplication conclusion is also one way of implementing it. It’s just that this way of implementation has been standardized. “Plethora” might be a bad choice of wording: I know at least 3 different implementations from major vendors that provide the flexibility by giving a choice to a user whether auto-retry should be enabled, with configurable delay parameters etc. [SD]I agree ”Plethora” is a bad choice of words and we will be more specific in the next revision. But I been involved in couple of implementations at-least and can’t vouch for the third and fourth’s current state. If you just want to expand on these options and document them, that might be fine (although you may want to choose informational vs standard track?), but this need to be more explicitly stated. [SD] Please provide your inputs on firming up on existing options and any more you have in mind. It will be great to hear from you on that. -- Sergey -----Original Message----- From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> On Behalf Of Dikshit, Saumya Sent: Friday, September 3, 2021 5:35 AM To: bess@ietf.org<mailto:bess@ietf.org>; bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> Subject: [bess] FW: New Version Notification for draft-saum-bess-dampening-backoff-00.txt Hello Bess WG members, Requesting you to please provide your review comments on the draft https://datatracker.ietf.org/doc/html/draft-saum-bess-dampening-backoff-00.txt<https://datatracker.ietf.org/doc/html/draft-saum-bess-dampening-backoff-00.txt>. This draft intends to provide the optimal solution of dampening a Duplicate MAC as described in https://datatracker.ietf.org/doc/html/rfc7432#section-15.1<https://datatracker.ietf.org/doc/html/rfc7432#section-15.1> Please let us know your thoughts on the solution proposed in this document. Thanks -----Original Message----- From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [mailto:internet-dra...@ietf.org] Sent: Monday, August 23, 2021 4:08 PM To: Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>>; Shankar, Swathi <swathi.shan...@hpe.com<mailto:swathi.shan...@hpe.com>>; Joshi, Vinayak <vinayak.jo...@hpe.com<mailto:vinayak.jo...@hpe.com>> Subject: New Version Notification for draft-saum-bess-dampening-backoff-00.txt A new version of I-D, draft-saum-bess-dampening-backoff-00.txt has been successfully submitted by Saumya Dikshit and posted to the IETF repository. Name: draft-saum-bess-dampening-backoff Revision: 00 Title: EVPN Mac Dampening Back-off Document date: 2021-08-23 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-saum-bess-dampening-backoff-00.txt<https://www.ietf.org/archive/id/draft-saum-bess-dampening-backoff-00.txt> Status: https://datatracker.ietf.org/doc/draft-saum-bess-dampening-backoff/<https://datatracker.ietf.org/doc/draft-saum-bess-dampening-backoff/> Htmlized: https://datatracker.ietf.org/doc/html/draft-saum-bess-dampening-backoff<https://datatracker.ietf.org/doc/html/draft-saum-bess-dampening-backoff> Abstract: MAC move handling in EVPN deployments is discussed in detail in [RFC7432]. There are few optimizations which can be done in existing way of handling the mac duplication. This document describes few of the potential techniques to do so. The IETF Secretariat _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess<https://www.ietf.org/mailman/listinfo/bess>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
