Re: Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

Jen Linkova <> Mon, 01 July 2019 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37147120128; Mon, 1 Jul 2019 08:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nuM2wF4lnMmO; Mon, 1 Jul 2019 08:24:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72C1A12011B; Mon, 1 Jul 2019 08:24:24 -0700 (PDT)
Received: by with SMTP id h21so15017322qtn.13; Mon, 01 Jul 2019 08:24:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6g84bn2zrGNvQQhSBM6iMSDRPoiIqFFIaDxi/r9rk58=; b=lzZKbkn6nDsmRc7dyl9PjhQ+vpBtyH/YZFYt829YZRnO79SvoHSp/dJgSDXoqzZKyd fvLi0ITFX68Ox1tJ2ccO4aGwDBvXQJ02teoHJfVrHpqA0LEyhgVvnQ/2+gCRV1/nnwHq +WPUsA/kufI67STWAIhumHuRxz8Z1aoMFrvPWcu11fJFPDIEIV5eIXZ1mNB78MJUE8hG J+R113J5PMriFZHffRcNZI/U0vHxbuJMsB9/kWevnOz6qUqEI09Z5x3gC9rmASx1b4kC 5bq7ryRfO7sOgfK8Z2ijVjQG5Z+xRmJP2s+XFbacoIOOaazFOh8warBQ0VQKhgYse1dz KkNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6g84bn2zrGNvQQhSBM6iMSDRPoiIqFFIaDxi/r9rk58=; b=W0mrd1DBRhzpOmHI7D82INtDTJZEsLlqFfiGYNvXJdLOAyC6YP5fXD+RcRidLFQvwe b1vm34OTraWcTD3T4FyPRfbGSD83f6l8K3t8ze6zrvnE6ttIuKUARvQXROjtn5EJIiZB EMLWcKDNCn1NBnPCgGplLPJ0jqk+jEgDyeQj+KNMT6WrPUld9zkKOJJrRI9VEUkIp7rf 9Hrb1OMANMBDcbEMnFUN1/9ZKUuIp+aJsV0G5B1M80CzDd9iJzRb3v7klB7X2HKa4/vk eo2ofQZ6WmKNSXNFavbJSYm3xOH2pFktIAqjcW3g3Uym0k9tup+0TpqTbcqLxuC37j0d zT6g==
X-Gm-Message-State: APjAAAWHt/AzpssXoZkW3eQyfqPbq/+vn8zLdbdo3obG+g0nb/W5z2uT pqD9yZUwqvgPSACpVBPvCnuRBFDw0UTrDMcQ3bFTF1ItbYw=
X-Google-Smtp-Source: APXvYqwyIBzz/NcEH4yqNVFLfXbcLUee7ixy3lcRYsQtbLFxC79H9PZqf1GN+xur7ZFfi9zG/iD+zIK+JHJeqvlnetg=
X-Received: by 2002:ac8:2b90:: with SMTP id m16mr20569117qtm.384.1561994663359; Mon, 01 Jul 2019 08:24:23 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jen Linkova <>
Date: Tue, 2 Jul 2019 01:24:12 +1000
Message-ID: <>
Subject: Re: Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
To: Pete Resnick <>
Cc:,, IETF Rinse Repeat <>, Routing WG <>
Content-Type: text/plain; charset="UTF-8"
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: Mon, 01 Jul 2019 15:24:27 -0000

Hi Pete,

Thanks for reviewing the draft - not the shortest one...;)

On Wed, Jun 5, 2019 at 1:42 AM Pete Resnick via Datatracker
<>; wrote:
> 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.
> 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.

Oh. Very good point - looks like I assumed that it's obvious and did
not mention it anywhere explicitly. Yes, all address selection
processes mentioned are for new connections.
And indeed the applications/upper-layers could override the default
address selection algorithm..

I've added some text to clarify. In particular:

1) Section 6:

First we look at how a host is currently expected to select the
   source and destination address with which it sends a packet for a new

2) Section 6.1

"It should be noted that [RFC6724] defines the default behaviour for

   IPv6 hosts.  The applications and uppler-layer protocols can make
   their own choices on selecting source addresses.  However the
   mechanism proposed in this document attempts to ensure that the
   subset of source addresses available for applications and upper-layer
   protocols is selected with the up-to-date network state in mind."

> 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.

I've added Section 6.7 - Solution Limitations

If you could review and let me know if it addresses your concern, it
would be great!

> 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.

I've added "(even if new releases of operating systems get multipath
protocols support
   there will be a long tail of legacy hosts)."
to clarify my lack of optimism..

> 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.

Fixed, thanks!

SY, Jen Linkova aka Furry