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

Robert Sparks <> Mon, 31 August 2020 13:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 046AE3A1387; Mon, 31 Aug 2020 06:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.948, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A8ELJfHkXwtL; Mon, 31 Aug 2020 06:16:48 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F08353A1376; Mon, 31 Aug 2020 06:16:47 -0700 (PDT)
Received: from unescapeable.local ([]) (authenticated bits=0) by (8.16.1/8.15.2) with ESMTPSA id 07VDGj0n002863 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 31 Aug 2020 08:16:46 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1598879807; bh=Xr2K6tKbSbj1yWyyfWmFnUymy+COix5MuCFASePt1xs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=CJWkYdC5rdvrZPMYVvFh2B07ESQCqpSCyiUm5aejvnBJXn+mQG3ObNoZNhFz10tkk CiVmNEoO/mLpI7fMUQtH1+yQGRIW822q9/18m6gq7w/wcLQu6CuBABlM48KsptLj/Z 8/mXbBtSLsqC4QQvcbsrO2CxqFaVO0rIHlF57tmg=
X-Authentication-Warning: Host [] claimed to be unescapeable.local
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <>, "" <>
Cc: "" <>, "" <>, "" <>
References: <> <>
From: Robert Sparks <>
Message-ID: <>
Date: Mon, 31 Aug 2020 08:16:43 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------FEB1C3DAE0D9AB58A7AFD65F"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-bess-evpn-na-flags-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Aug 2020 13:16:55 -0000

Thanks for considering my suggestions Jorge - your edits address all my 


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: * <>
> *Cc: * 
> <>, 
> <>, <>
> *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-
>          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.