Re: [multipathtcp] Multipath TCP Address advertisement 5/5 - Communities

Alan Ford <> Mon, 14 November 2016 07:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D022A1295C0 for <>; Sun, 13 Nov 2016 23:05:50 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zi5zH6vyDxLO for <>; Sun, 13 Nov 2016 23:05:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 358641294E3 for <>; Sun, 13 Nov 2016 23:05:46 -0800 (PST)
Received: by with SMTP id c4so16029877pfb.1 for <>; Sun, 13 Nov 2016 23:05:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=phK1VTOAPO9o/MCakBfllQ9ntYwmoYKR0Tm4pvcx3D8=; b=SCOKGDXwATMMrYYcJYZYvfu9s/1nUgbWfjJKNWtNF01OdHSrjzCNtUprI7F9EKizU9 LvyyBZnTSWMdst4/HljlkWDtSMWoibSS5dizn2jHst1FficLk812BqJDudgzZu52XtZW JLvxC1zzgd6lzsww7ml+KfkgOaQNbv8aSzjuM1gNk3Civa9qS40B/X4wN/sNQA/vGfRe aUCzZD06f38LaTCBRHDAazekQmIxS6l8wpma4lfPvV8b5S1aeCi6NlhbSVlRL0eRZjzd NKqRVw39Ej2tJdMBS/mJTz9/5KqIchZZLtGkKYS+04wM79T4njE2+ITqK9rd0Yqbg1cI nuog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=phK1VTOAPO9o/MCakBfllQ9ntYwmoYKR0Tm4pvcx3D8=; b=KyD7Gw9GixYXNNulUR6gsDalJyePp7Bh35WNlW4Al5Ldx7UOu1uIVPnrvRQrloPbMy +a31jpy2LUqgFGrTS1yySUNX7SSO+6qqodRJzAX1GDZPV5ZGRzdbIWX7O7TyFeyRNAtO Eh9diW6TJFiCHp468LN8MQIn5PX0qpgocNs+TrLx2nyJy19ft70pWq9LH4/N3gNN4/ap u3KC7YxSjUvO3GRQlPXbRRNu5CP0Wr+opNVd74aMskvv4LiECqZ+PZTqk/y+7VYa4br4 jkTE4Zrx8nJyFZkfh/Il9aM6QfrHftoEmjg6vlVlwIzMR+rW+Yf37762TMF88TxJ1ZHk MsaA==
X-Gm-Message-State: ABUngvfEG96KNWjT/FMQFVsvjbk1mf1wNoQVfBut1RXVQJpWPVaQ2yhmgdzOejYly2PugQ==
X-Received: by with SMTP id 204mr66659058pge.77.1479107145813; Sun, 13 Nov 2016 23:05:45 -0800 (PST)
Received: from ( []) by with ESMTPSA id dc3sm32474110pad.32.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Nov 2016 23:05:45 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Mon, 14 Nov 2016 07:05:42 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Fabien Duchêne <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] Multipath TCP Address advertisement 5/5 - Communities
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Nov 2016 07:05:57 -0000

Hi all,

After discussion at IETF97, I do not support this proposal. I can’t see any scenarios where this would actually be particularly useful.

Specifically, no end host really has enough knowledge to say their IPv4 and IPv6 addresses go over the same path, other than they share the same physical interface at an end host. Some ends may have a good idea, e.g. data centres.

But if you as a server know your IPv6 and IPv4 share a path, you may choose not to use one or the other. Same for the client. So under what circumstances does signalling this to the far end actually help?


> On 6 Nov 2016, at 12:38, Fabien Duchêne <> wrote:
> Hello,
> As we agreed in Berlin during IETF96, here are a few email to discuss
> the contributions proposed in
> To allow a host to inform the receiving host about the diversity of
> several addresses we propose to modify the ADD_ADDR to include 4 bits
> describing a "Community" associated to this address.
> The community values are an opaque field and it is expected that two
> addresses having the same community share some resources.
> With the community bits, a dual-stack host could elect to regroup all
> the addresses attached to a single interface under the same community,
> allowing the receiving host to decide on which advertised addresses it
> wants to establish new subflows.
> This is because in the case of a dual-stack host, establishing v4 and V6
> subflows
> is not always the best solution.
> The idea here is to design a generic solution to regroup the address
> that shares
> the same forwarding type in a specific class.
> Fabien
> _______________________________________________
> multipathtcp mailing list