Subject: Re: [bess] Murray Kucherawy's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 17 Mar 2021 14:33:34 +0000

Hi Murray,

Thanks for reviewing. Please see my comments in-line with [jorge].
We have addressed your comments, you should see the changes in the next revision.

Thx
Jorge

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Thursday, January 21, 2021 at 5:23 AM
To: The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>
Subject: Murray Kucherawy's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)
Murray Kucherawy has entered the following ballot position for
draft-ietf-bess-evpn-proxy-arp-nd-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In addition to Barry's comments, I found that "BD" appears in the glossary
twice, and "SLLA" appears in the glossary but nowhere else in the document.
[jorge] fixed both things, thanks.

Are "Address Resolution" and "Large Data Center" formal terms?  If not, they
should be lowercase.
[jorge] fixed address resolution. Since we are using DC as an acronym, I’m using DC consistently now, throughout the document. Thanks.

Alluding to a lot of things Alvaro pointed out: Many of the SHOULDs in this
document are bare, in that they give the implementer a choice but no guidance
on how to make that choice.  For instance:

   A Proxy-ARP/ND implementation SHOULD support static, dynamic and
   EVPN-learned entries.

How would I decide whether I've got a use case that justifies not doing one of
those, and what are the interoperability implications of that decision?

I suggest reviewing these.
[jorge] we reviewed all those after Alvaro’s review. About the one you point out, I changed it to:
“A Proxy-ARP/ND implementation in an EVPN BD MUST support dynamic and EVPN-learned entries, and SHOULD support static entries.”
Since if the solution is implemented, at least dynamic and evpn entries are needed.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Mar 2021 09:42:55 -0700

These are great, thanks!

On Wed, Mar 17, 2021 at 7:33 AM Rabadan, Jorge (Nokia - US/Mountain View) <
[email-masked]> wrote:

> *From: *Murray Kucherawy via Datatracker <[email-masked]>
> *Date: *Thursday, January 21, 2021 at 5:23 AM
> *To: *The IESG <[email-masked]>
> *Cc: [email-masked] <
> [email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <[email-masked]>, Bocci, Matthew
> (Nokia - GB) <[email-masked]>
> *Subject: *Murray Kucherawy's No Objection on
> draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)
>
> [jorge] fixed address resolution. Since we are using DC as an acronym, I’m
> using DC consistently now, throughout the document. Thanks.
>
>
>
>
>
> “A Proxy-ARP/ND implementation in an EVPN BD MUST support dynamic and
> EVPN-learned entries, and SHOULD support static entries.”
>