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

[Alissa Cooper <[e-mail]>]

Robert, thanks for your review. Jorge, thanks for your response. I ran out of time to ballot on this document but I appreciate the document improvements.

Alissa


> On Aug 31, 2020, at 9:16 AM, Robert Sparks <[e-mail]> wrote:
> 
> 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 <[e-mail]> <mailto:[e-mail]>
>> Date: Tuesday, August 18, 2020 at 6:11 PM
>> To: [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
>> Cc: [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
>> 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
>> 
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
>> 
>> 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-
>>          immutable binding for the same IP->MAC.  The absence of the
>>          EVPN ARP/ND Extended Community in a MAC/IP Advertisement route
>>          indicates that the IP->MAC entry is not an "Immutable binding".
>>  
>>       *  Receiving multiple EVPN MAC/IP Advertisement routes with I=1
>>          for the same IP but different MAC is considered a
>>          misconfiguration.
>>  
>>       *  A PE originating an EVPN MAC/IP Advertisement route for
>>          IP1->MAC1 with I=1 MAY also originate the route with the Static
>>          bit set (in the MAC Mobility Extended Community).  In such a
>>          case, the IP1->MAC1 binding is not only immutable but it cannot
>>  
>>  
>>  
>> Rabadan, et al.           Expires March 5, 2021                 [Page 6]
>>  
>> Internet-Draft      EVPN Neighbor Advertisement Flags     September 2020
>>  
>>  
>>          move as well.  Even so, if an update for the same IP1->MAC1
>>          immutable and static, is received from a different PE, one of
>>          the two routes will be selected, as in the [RFC7432] case where
>>          two MAC/IP routes with Static bit are received for the same MAC
>>          from different PEs.
>>  
>>    In a situation where a host (with an IP->MAC that is configured as
>>    Immutable binding in the attached PE) is allowed to move between PEs
>>    (that is, the associated MAC is non-static), PEs can receive multiple
>>    MAC/IP advertisement routes for the same IP->MAC.  In such
>>    situations, MAC mobility procedures as in [RFC7432] dictate the
>>    reachability of the MAC.
>>  
>>    As an example of the use of the I Flag, consider PE1, PE2 and PE3 are
>>    attached to the same BD.  PE1 originates an EVPN MAC/IP Advertisement
>>    route for IP1->MAC1 with I=1; later on, PE2 also originates an EVPN
>>    MAC/IP Advertisement route IP1->MAC1 with a higher sequence number
>>    and I=1.  Then all the EVPN PEs attached to the same BD SHOULD retain
>>    their IP1->MAC1 ARP/ND binding but update MAC1's forwarding
>>    destination to PE2.  If for some reason, PE3 originates an EVPN MAC/
>>    IP Advertisement route for IP1->MAC2 (even with a higher sequence
>>    number), then the EVPN PEs in the BD SHOULD NOT update their
>>    IP1->MAC1 ARP/ND bindings, since IP1 is bound to MAC1 (MAC2 SHOULD
>>    still be programmed in the layer-2 BDs).  This is considered a
>>    misconfiguration in PE3.
>>  
>>    The use of the Flag I=1 assumes that a given IP is always bound to
>>    the same MAC address, and therefore the mobility procedures described
>>    in [I-D.ietf-bess-evpn-irb-extended-mobility] for "Host IP move to a
>>    new MAC" will not apply.
>>  
>> 
>> 
>> 
>> Editorial Nits:
>> 
>> I suggest deleting "refers to" in the terminology sentences. In all cases you
>> mean "is" and you don't need to say "is".
>> 
>> [Jorge] ok, removed
>> 
>> 
>> 
>> The last phrase in the description of Bit 4 at the end of section 2 was
>> difficult to read. Consider breaking the sentence into two or more.
>> 
>> [Jorge] ok, changed to:
>> 
>>    Bit 4 of the Flags field is defined as the "Immutable ARP/ND Binding
>>    Flag".  When set, the egress PE indicates that the IP->MAC pair sent
>>    in an EVPN MAC/IP Advertisement route (along with the Extended
>>    Community) is a configured ARP/ND entry.  The IP address in the EVPN
>>    MAC/IP Advertisement route can only be bound together with the MAC
>>    address specified in the same route.
>>  
>> 
>> 
>> 
>> At the end of section 3.1, "does not have any impact on" is confusing. I think
>> you mean "does not change"? At ", including" the sentence becomes awkward. I
>> suggest breaking that into a separate sentence. Perhaps "Specifically the
>> procedures for advertising ... are not changed."
>> 
>> [Jorge] good point, changed as suggested.
>> 
>> 
>> 
>> 
>> 
> _______________________________________________
> Gen-art mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>