Re: [Gen-art] Genart last call review of draft-ietf-bess-evpn-na-flags-05
Robert Sparks <rjsparks@nostrum.com> Mon, 31 August 2020 13:16 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046AE3A1387; Mon, 31 Aug 2020 06:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8ELJfHkXwtL; Mon, 31 Aug 2020 06:16:48 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08353A1376; Mon, 31 Aug 2020 06:16:47 -0700 (PDT)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (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 rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; 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: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Cc: "draft-ietf-bess-evpn-na-flags.all@ietf.org" <draft-ietf-bess-evpn-na-flags.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "bess@ietf.org" <bess@ietf.org>
References: <159776707925.23974.18030617296445881198@ietfa.amsl.com> <MWHPR08MB35206C143B85A1D556ABC03DF7510@MWHPR08MB3520.namprd08.prod.outlook.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <696da4c7-9e64-7d6b-0e4c-b6e53c1f04d6@nostrum.com>
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: <MWHPR08MB35206C143B85A1D556ABC03DF7510@MWHPR08MB3520.namprd08.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------FEB1C3DAE0D9AB58A7AFD65F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/-J6uDXgWwrkPnRW7dLzv7t6dXrI>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-bess-evpn-na-flags-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2020 13:16:55 -0000
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 <noreply@ietf.org> > *Date: *Tuesday, August 18, 2020 at 6:11 PM > *To: *gen-art@ietf.org <gen-art@ietf.org> > *Cc: *draft-ietf-bess-evpn-na-flags.all@ietf.org > <draft-ietf-bess-evpn-na-flags.all@ietf.org>, last-call@ietf.org > <last-call@ietf.org>, bess@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 > > <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] Genart last call review of draft-ietf-b… Robert Sparks via Datatracker
- Re: [Gen-art] Genart last call review of draft-ie… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [Gen-art] Genart last call review of draft-ie… Robert Sparks
- Re: [Gen-art] Genart last call review of draft-ie… Alissa Cooper