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

Alissa Cooper <> Thu, 27 June 2019 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6360C1200E9; Thu, 27 Jun 2019 07:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key) header.b=zbMzoAXD; dkim=pass (2048-bit key) header.b=DjSpbDKm
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QazyIjQ4atAB; Thu, 27 Jun 2019 07:38:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCCCB1200D6; Thu, 27 Jun 2019 07:38:15 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 84570513; Thu, 27 Jun 2019 10:38:14 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute7.internal (MEProxy); Thu, 27 Jun 2019 10:38:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=; 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 (unknown []) by (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 <>
In-Reply-To: <>
Date: Thu, 27 Jun 2019 10:38:10 -0400
Cc: IETF Gen-ART <>,, IETF <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Pete Resnick <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


> On Jun 4, 2019, at 11:41 AM, Pete Resnick via Datatracker <>; 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
> <>;.
> 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