Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

Alissa Cooper <alissa@cooperw.in> Thu, 27 June 2019 14:38 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6360C1200E9; Thu, 27 Jun 2019 07:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=zbMzoAXD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DjSpbDKm
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 QazyIjQ4atAB; Thu, 27 Jun 2019 07:38:15 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCCB1200D6; Thu, 27 Jun 2019 07:38:15 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 84570513; Thu, 27 Jun 2019 10:38:14 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 27 Jun 2019 10:38:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=0 AwF+X0zDoTyz6/bMRACEiZ5EIEhKfbEVYHmK+RtXxQ=; b=zbMzoAXDOnQtCu/8n ouVhCp+qs5Och2y1+qGgRCMKpNLu31Xg6tAqmmbUue1ACMNy27dgNWkF469mKbIb pDxt6vmZXqahZEdAf1/BlJ4TIa4hmyIeoRe1d4r9INhxuqonfVpIIbp5kgnzx2Yd Glo3EODqcu33JrRQV6BUiucSqozcsKrChYPg4237MJySCmg0DXVhlnwHWtZSHOoi Vv2HWaHt/IueijSBt5wt76sBT43gaxauLnT5m/b6SZRL/D+9LWxwirs1ygMe1pcs IOAWmtIBTlJJGdHLGNuGbq1Z4/5eS2kLZQI4sIPGIYGeFJvFpPhi46HKhpBJVkT9 Wyreg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=0AwF+X0zDoTyz6/bMRACEiZ5EIEhKfbEVYHmK+RtX xQ=; b=DjSpbDKmsyEzqOB7HaaaZnMZQnlu9eKH479RybUzNz59qvPMplT622Y9Q 45o62arWuuas7K44ZgDrS9YlB6l10S/YJuFVH/vktyMrGw3JIP9/bMcWqPyfSQi7 Yy0W+Zq0aTobkOyntIijf1euOqbV4+xD0xLPPS5bBk0vLy6NaA4En5e5N1DCD/tZ k/ODRARiiuLdKo+Ob22Bd/aLhaHLAsa41lSFMkaUEAj8yQV9GS9pexLg/fCBOfOf hnq5CeIpiT0+bD8heT8gVeeBKG1uUdmNZ85cwMWuABTb2cTaT1kNDtirZtKbxq5Y a/peeeF+C1+uC8aSrxWtpH+APnKHA==
X-ME-Sender: <xms:1dQUXfuGi1JysGGYeZCjaw_uJxBFnqFnOwn9BLGqVcUp84XTNO_hmg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudekgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdelvdenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt
X-ME-Proxy: <xmx:1dQUXcXN9pCbybKMm0aTbtwJ32Z_gotdDWNuIU1At-pv97DQJjOWPQ> <xmx:1dQUXfy1W831K6yrxylcMjMrTGq7KN0gVfj3WQwMuKC_m1UIL9VkRQ> <xmx:1dQUXTFPDt_1jI5Ol-2b1oPocQVPwRqu2yLRRdc4iMrOP547SiZLIg> <xmx:1dQUXR7beBDxmP-XQN02rfdw59Hkl9VWG19nO5WVwl4svurW1kpGQg>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.92]) by mail.messagingengine.com (Postfix) with ESMTPA id A6E3F380076; Thu, 27 Jun 2019 10:38:12 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <155966291865.28051.17270657886362926135@ietfa.amsl.com>
Date: Thu, 27 Jun 2019 10:38:10 -0400
Cc: IETF Gen-ART <gen-art@ietf.org>, draft-ietf-rtgwg-enterprise-pa-multihoming.all@ietf.org, IETF <ietf@ietf.org>, rtgwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F9B8C6C9-C68D-4442-A041-2724B13AB4BE@cooperw.in>
References: <155966291865.28051.17270657886362926135@ietfa.amsl.com>
To: Pete Resnick <resnick@episteme.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/QE2JXybXKW10YLK2Uy2CT1TW5BA>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 14:38:19 -0000

Pete, thank you for your review. I entered a DISCUSS ballot on the basis of your first point.

Alissa

> On Jun 4, 2019, at 11:41 AM, Pete Resnick via Datatracker <noreply@ietf.org>; wrote:
> 
> Reviewer: Pete Resnick
> Review result: Almost Ready
> 
> 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-rtgwg-enterprise-pa-multihoming-08
> Reviewer: Pete Resnick
> Review Date: 2019-06-04
> IETF LC End Date: 2019-06-04
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Almost Ready.
> 
> I found this overall to be an excellent document with clear technical
> explanations that even an upper-layer knucklehead like me could understand.
> However, there a couple of issues could use more discussion. I put them as
> "Minor issues", in that they're not showstoppers, but I do think they're
> important and hope you'll be able to address them.
> 
> Major issues:
> 
> None.
> 
> Minor issues:
> 
> Throughout, but particularly in section 5, this document refers to "hosts"
> doing address selection. To be fair, so does RFC 6724, but 6724 is referring to
> *default* address selection. In reality, *applications* do address selection on
> a host; the host stack will only do address selection if the application
> requests a default address. That works well for the scenarios in 6724, but in
> this document, for example section 5.2.3, I'm not so sure. The idea that a host
> would receive an ICMP destination unreachable and re-arrange its address
> selection seems at least an incomplete picture: An application with a (normal,
> non-multi-path) TCP connection to a remote application is not able to "try
> another source address to reach the destination"; the source address is already
> set for that TCP connection, so the only choice is to close the connection
> entirely. If the application chooses to re-establish the connection with a
> default address, yes, the host stack could then give a new default address back
> to the application, but this is hardly the dynamic and quickly adjusting
> process that the document seems to be envisioning.
> 
> I don't think the above invalidates the core of the document or requires some
> grand rewrite. But I do think some clarification is in order, saying that the
> mechanisms described help with the *default* address selection, and some short
> discussion of the limitations for what applications can (and more importantly
> cannot) do with these mechanisms would be useful.
> 
> My suspicion is that section 7.3 underestimates the availability (current and
> future) of multipath transport. Apple is using it now in production, and Linux
> already has it in their implementation. I think this is actually a reasonable
> possible solution in the future, and I would be a little more optimistic than
> the WG in this section.
> 
> Nits/editorial comments:
> 
> Two editorial bits in section 1:
> 
>   This document defines routing requirements for enterprise multihoming
>   using provider-assigned IPv6 addresses.  We have made no attempt to
>   write these requirements in a manner that is agnostic to potential
>   solutions.  Instead, this document focuses on the following general
>   class of solutions.
> 
> Is that second sentence right? If you are giving a general class of solutions,
> that seems agnostic to the particular solution. Just a bit confusing.
> 
>   A host SHOULD be able respond dynamically...
> 
> Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone.
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art