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

Jen Linkova <furry13@gmail.com> Thu, 04 July 2019 01:08 UTC

Return-Path: <furry13@gmail.com>
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 57E6F1202E3; Wed, 3 Jul 2019 18:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 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, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wxi3DnAJxvpj; Wed, 3 Jul 2019 18:07:58 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 BF1891206C2; Wed, 3 Jul 2019 18:07:57 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id a15so6391962qtn.7; Wed, 03 Jul 2019 18:07:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ba6NOGA42EIB594eEHCBXRfxO2TyHWwSLuiByAVjAKE=; b=AUtr5HL2sEgEYX1HccpvnfOlLU40JYr5Rpcs9zvA1CRYE8hfV2wqdZd9ELTR02FDwg 7SCIakdW8gYFIdWDGg16cA0juLb4svyur0W3aaTKcr5t5UMgwwiw5NFqItSJQf51b/p7 8BOLm/wSDwEArfzujz/zLr8k4yK2vusBvJrRDixOoOdb3uNOXtczgaHWHw55Rbuyb038 NuMxiGknqHpTsK7MJjNmxEGGLV9DkPCmgcihfHq+ZUyT5TrnoS+L7RQbijpAVeH4bohv GPT74L8slhkI318BBsxTP8bNkm+7XuDiB0go1HdLtv7inuSDLjRkXF2uSjHCoURefok1 Ku/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ba6NOGA42EIB594eEHCBXRfxO2TyHWwSLuiByAVjAKE=; b=s0IGQPBuQOdjrFsAoD5sh0Q1DDX5Y3ytvfmvwk8QtN8z+EvkX3Pzl4IUNyjaGESDrY aKQgmW/ZKv2mRV4BOJFSE3C8neiGwfRVKYjekMzOlVNYYl7I+DPOnQcAduWqpQNN3mUr 9rsIlVPqiVVvsT9pBo9wocaDTMuV56ZibIvpoAFv8/jY8pon8UBlrhZw5dCQ2Ar9tL/k RclvdLXjbXl8JP6cUH0s3q+4hQgpOEPkVYFhdwcbB7WdD7Mny3D+FqA7lKqRFdVxVlki pS4+feRzh7sbJlXAzD8/48SUer+Uh7uspAYF8QXr7cbcrIfamBhCL2CckXMO7s99N/nm cH/g==
X-Gm-Message-State: APjAAAXNum8O81aozvyASdPfH9ttZ94CpbWvav3ZnKnDdLYwVRZfIG2T vjFXMcl7wn28qurGS/XZcfLEMdgxpS6OoJYkiBo=
X-Google-Smtp-Source: APXvYqxtG75VWsEfTOPS+YckQQMojGa4abz2EFBmWV4e5nlyEu76uzhcPEi431J0JZ3kgl5XF3BYeAOT0FHJqvoR8sc=
X-Received: by 2002:a0c:af8a:: with SMTP id s10mr35669513qvc.182.1562202476714; Wed, 03 Jul 2019 18:07:56 -0700 (PDT)
MIME-Version: 1.0
References: <155966291865.28051.17270657886362926135@ietfa.amsl.com> <CAFU7BAQh46z1BTp2o6o+aB3QckASSZ+5qaPyoeW3S8=NCp-pgA@mail.gmail.com> <E6B546F9-67FD-49DF-B615-11564C3745C7@episteme.net>
In-Reply-To: <E6B546F9-67FD-49DF-B615-11564C3745C7@episteme.net>
From: Jen Linkova <furry13@gmail.com>
Date: Thu, 4 Jul 2019 11:07:44 +1000
Message-ID: <CAFU7BAQqGd-O-vvNpoo9yg66M7KNcTp2LbU1rZ-7ejB1tx7_=Q@mail.gmail.com>
Subject: Re: Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
To: Pete Resnick <resnick@episteme.net>
Cc: gen-art@ietf.org, draft-ietf-rtgwg-enterprise-pa-multihoming.all@ietf.org, IETF <ietf@ietf.org>, Routing WG <rtgwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/5Bw8riS7meJYJUdyDftY25syxYQ>
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, 04 Jul 2019 01:08:05 -0000

Hi Pete,

On Tue, Jul 2, 2019 at 8:47 AM Pete Resnick <resnick@episteme.net>; wrote:
> It's not just that the address selection is for new connections, though
> that is certainly true. It's also the question of who is doing what:
> Hosts figure out the address for default address selection, and
> applications are the ones that do the selecting (whether it is to choose
> the host default or choose a different one). Part of what the document
> is missing is use of the word "default", at least in a few places. So,
> in -09, a couple of suggestions:
>
> In the Abstract, change "select appropriate source addresses" to "select
> appropriate default source addresses".

Done!

> In the Introduction, you have:
>
>     Section 6 discusses existing and proposed
>     mechanisms for hosts to select the source address applied to
> packets.
>     It also discusses the requirements for routing that are needed to
>     support these enterprise network scenarios and the mechanisms by
>     which hosts are expected to select source addresses dynamically
> based
>     on network state.
>
> Hosts definitely don't select the source address to be applied to any
> given packet; that's (at best) an application thing. Also, "dynamically"
> here seems to imply "during the life of the connection", but that's
> certainly not what you meant. Something like this seems better:
>
>     Section 6 discusses existing and proposed mechanisms for hosts to
>     select the default source address to be used by applications.
>     It also discusses the requirements for routing that are needed to
>     support these enterprise network scenarios and the mechanisms by
>     which hosts are expected to update default source addresses based
>     on network state.

Done, thanks for suggesting the text.

> Again, hosts pick default addresses for applications to use, and
> applications pick the addresses that packets will use.

OK, I guess we are just using different terminology here...
For me 'a host' is a whole element connected to the network, including
all subsystems and applications running.
Until your email I was thinking about an application as an element of
a host. If I got you right, when the draft says 'host' you read it as
'network stack on a host', right?

> How about this? :
>
> "It should be noted that [RFC6724] only defines the behavior of IPv6
> hosts to select default addresses that applications and upper-layer
> protocols can use. Applications and upper-layer protocols can make their
> own choices on selecting source addresses. The mechanism proposed in
> this document attempts to..."

I've updated that paragraph:

"It should be noted that [RFC6724] only defines the behavior of IPv6
hosts to select default addresses that applications and upper-layer
protocols can use. Applications and upper-layer protocols can make
their own choices on selecting source addresses. 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. The rest of the
document discusses various aspects of the default source address
selection defined in [RFC6724], calling it for the sake of brevity
"the source address selection".

I hope that the last sentence makes the rest of the document less confusing.
What do you think?

> I'd also suggest taking a look through the rest of section 6 for use of
> the word "host" and see if the word "default" needs to be inserted
> somewhere after it (like "...hosts to choose the correct *default*
> source address"), or if it needs to be changed to "application".

I've updated a number of places as well.

> Nice. If it were me, I'd add a forward pointer to mptcp in 8.3 as
> another mechanism (in addition to BGP) to deal with the problem.

It is there:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3

> >> My suspicion is that section 7.3 underestimates the availability
> >> (current and
> >> future) of multipath transport.

> You can have the half empty glass; I'll take the half full one. ;-)

As per Magnus's suggestion, I've updated the text to mention that
PA-based multihoming and MP transport could benefit from each other:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3


-- 
SY, Jen Linkova aka Furry