Re: [bess] Genart last call review of draft-ietf-bess-evpn-na-flags-05

2020-08-31 Thread Robert Sparks 
Thanks for considering my suggestions Jorge - your edits address all my 
concerns!


RjS

On 8/31/20 3:46 AM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:


Robert,

Thank you very much for the review. Great points.

Please see in-line with [Jorge]. All the changes will be included in 
the next revision.


Thank you!

Jorge

*From: *Robert Sparks via Datatracker 
*Date: *Tuesday, August 18, 2020 at 6:11 PM
*To: *gen-...@ietf.org 
*Cc: *draft-ietf-bess-evpn-na-flags@ietf.org 
, last-c...@ietf.org 
, bess@ietf.org 

*Subject: *Genart last call review of draft-ietf-bess-evpn-na-flags-05

Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bess-evpn-na-flags-05
Reviewer: Robert Sparks
Review Date: 2020-08-18
IETF LC End Date: 2020-08-28
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC but with nits to
address before publication

The protocol being defined seems fine, and the IANA considerations are 
well
constructed. I have a nagging feeling that there are new security 
concerns this
introduces, but haven't been able to identify anything specific. I 
appreciate

that the document discusses what happens when a bad-actor introduces
intentionally mis-configured flags.

Editorial Issues:

The Abstract is full of acronyms that are not universally understood, 
and it

buries the point of the document. Please consider rewriting to focus more
specifically on the goal of the draft (see the introduction in the 
shepherd's
writeup), keeping in mind that the abstract should make sense to 
people who

don't know yet what PE stands for. Much of what you currently have in the
Abstract can be left to the Introduction. I expect a shorter (two or three
sentence) abstract will suit the document better.

[Jorge] we simplified the abstract as follows, hopefully it addresses 
your comment:


   Ethernet Virtual Private Network (EVPN) uses MAC/IP Advertisement

   routes to advertise locally learned MAC and IP addresses associated

   to host or routers.  The remote Provider Edge (PE) routers may use

   this information to populate their Address Resolution Protocol (ARP)

   or Neighbor Discovery (ND) tables and then reply locally to ARP

   Requests or Neighbor Solicitation messages on behalf of the owner of

   the IP address.  However, the information conveyed in the MAC/IP

   route may not be enough for the remote PE to reply to local ARP or ND

   requests.  This document defines an Extended Community that is

   advertised along with an EVPN MAC/IP Advertisement route and carries

   information relevant to the ARP/ND resolution, so that an EVPN PE

   implementing a proxy-ARP/ND function can reply to ARP Requests or

   Neighbor Solicitations with the correct information.



In section 3.2: The list of three things in the list under "R and O Flags
processing" are all processing steps. But the list of 6 things under 
"I Flag

processing" are not all processing steps. Please change the list to only
include processing steps, and move the examples and commentary to regular
paragraphs after the processing has been specified.

Consider moving the third top-level bullet in 3.2 ("MUST be ignored") 
to be the

first bullet, and after that bullet say "otherwise".

[Jorge] ok, section 3.2 changed as follows:

3.2.  Reception of the EVPN ARP/ND Extended Community
   In addition to the procedures specified in [RFC7432] a PE receiving a
   MAC/IP Advertisement route will process the EVPN ARP/ND Extended
   Community as follows:
   o  The R, O and I Flags MUST be ignored if they are advertised along
  with an EVPN MAC/IP Advertisement route that does not contain an
  IP (IPv4 or IPv6) address.  Otherwise they are processed as
  follows.
   o  R and O Flags processing:
  *  If the EVPN MAC/IP Advertisement route contains an IPv6 address
 and the EVPN ARP/ND Extended Community, the PE MUST add the R
 and O Flags to the ND entry in the ND or proxy-ND table and use
 that information in Neighbor Advertisements when replying to a
 Solicitation for the IPv6 address.
  *  If no EVPN ARP/ND Extended Community is received along with the
 route, the PE will add the default R and O Flags to the entry.
 The default R Flag SHOULD be an administrative choice.  The
 default O Flag SHOULD be 1.
  *  A PE MUST ignore the received R and O Flags for an EVPN MAC/IP
 Advertisement route that contains an IPv4->MAC pair.
   o  I Flag processing:
  *  A PE receiving an EVPN MAC/IP Advertisement route containing an
 IP->MAC and the I Flag set SHOULD

Re: [bess] Genart last call review of draft-ietf-bess-evpn-na-flags-05

2020-08-31 Thread Rabadan, Jorge (Nokia - US/Mountain View) 
Robert,

Thank you very much for the review. Great points.
Please see in-line with [Jorge]. All the changes will be included in the next 
revision.
Thank you!
Jorge

From: Robert Sparks via Datatracker 
Date: Tuesday, August 18, 2020 at 6:11 PM
To: gen-...@ietf.org 
Cc: draft-ietf-bess-evpn-na-flags@ietf.org 
, last-c...@ietf.org 
, bess@ietf.org 
Subject: Genart last call review of draft-ietf-bess-evpn-na-flags-05
Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bess-evpn-na-flags-05
Reviewer: Robert Sparks
Review Date: 2020-08-18
IETF LC End Date: 2020-08-28
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC but with nits to
address before publication

The protocol being defined seems fine, and the IANA considerations are well
constructed. I have a nagging feeling that there are new security concerns this
introduces, but haven't been able to identify anything specific. I appreciate
that the document discusses what happens when a bad-actor introduces
intentionally mis-configured flags.

Editorial Issues:

The Abstract is full of acronyms that are not universally understood, and it
buries the point of the document. Please consider rewriting to focus more
specifically on the goal of the draft (see the introduction in the shepherd's
writeup), keeping in mind that the abstract should make sense to people who
don't know yet what PE stands for. Much of what you currently have in the
Abstract can be left to the Introduction. I expect a  shorter (two or three
sentence) abstract will suit the document better.
[Jorge] we simplified the abstract as follows, hopefully it addresses your 
comment:
   Ethernet Virtual Private Network (EVPN) uses MAC/IP Advertisement
   routes to advertise locally learned MAC and IP addresses associated
   to host or routers.  The remote Provider Edge (PE) routers may use
   this information to populate their Address Resolution Protocol (ARP)
   or Neighbor Discovery (ND) tables and then reply locally to ARP
   Requests or Neighbor Solicitation messages on behalf of the owner of
   the IP address.  However, the information conveyed in the MAC/IP
   route may not be enough for the remote PE to reply to local ARP or ND
   requests.  This document defines an Extended Community that is
   advertised along with an EVPN MAC/IP Advertisement route and carries
   information relevant to the ARP/ND resolution, so that an EVPN PE
   implementing a proxy-ARP/ND function can reply to ARP Requests or
   Neighbor Solicitations with the correct information.



In section 3.2: The list of three things in the list under "R and O Flags
processing" are all processing steps. But the list of 6 things under "I Flag
processing" are not all processing steps. Please change the list to only
include processing steps, and move the examples and commentary to regular
paragraphs after the processing has been specified.

Consider moving the third top-level bullet in 3.2 ("MUST be ignored") to be the
first bullet, and after that bullet say "otherwise".
[Jorge] ok, section 3.2 changed as follows:

3.2.  Reception of the EVPN ARP/ND Extended Community



   In addition to the procedures specified in [RFC7432] a PE receiving a

   MAC/IP Advertisement route will process the EVPN ARP/ND Extended

   Community as follows:



   o  The R, O and I Flags MUST be ignored if they are advertised along

  with an EVPN MAC/IP Advertisement route that does not contain an

  IP (IPv4 or IPv6) address.  Otherwise they are processed as

  follows.



   o  R and O Flags processing:



  *  If the EVPN MAC/IP Advertisement route contains an IPv6 address

 and the EVPN ARP/ND Extended Community, the PE MUST add the R

 and O Flags to the ND entry in the ND or proxy-ND table and use

 that information in Neighbor Advertisements when replying to a

 Solicitation for the IPv6 address.



  *  If no EVPN ARP/ND Extended Community is received along with the

 route, the PE will add the default R and O Flags to the entry.

 The default R Flag SHOULD be an administrative choice.  The

 default O Flag SHOULD be 1.



  *  A PE MUST ignore the received R and O Flags for an EVPN MAC/IP

 Advertisement route that contains an IPv4->MAC pair.



   o  I Flag processing:



  *  A PE receiving an EVPN MAC/IP Advertisement route containing an

 IP->MAC and the I Flag set SHOULD install the IP->MAC entry in

 the ARP/ND or proxy-ARP/ND table as an "Immutable binding".

 This Immutable binding entry will override an existing non-