Re: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT

Joe Touch <touch@isi.edu> Thu, 13 July 2017 20:00 UTC

Return-Path: <touch@isi.edu>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68A313176A; Thu, 13 Jul 2017 13:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 z6NNA-o_y-iS; Thu, 13 Jul 2017 13:00:14 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 1F6CC1316A9; Thu, 13 Jul 2017 13:00:14 -0700 (PDT)
Received: from [10.31.59.150] (ip-64-134-100-23.public.wayport.net [64.134.100.23]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v6DJxKaL016311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Jul 2017 12:59:22 -0700 (PDT)
To: Dan Wing <dwing@vmware.com>
Cc: Linda Dunbar <linda.dunbar@huawei.com>, "draft-ietf-nvo3-encap@ietf.org" <draft-ietf-nvo3-encap@ietf.org>, NVO3 <nvo3@ietf.org>
References: <4A95BA014132FF49AE685FAB4B9F17F6593FAA91@SJCEML702-CHM.china.huawei.com> <F254185B-6142-479D-BBDA-983A1189580D@vmware.com> <07212cff-8dbd-8ae9-3ca7-35244007ad6b@isi.edu> <63F0786E-681F-45E5-9288-79C28978C9BB@vmware.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <20426a5c-766b-323b-203c-113adf35c8ce@isi.edu>
Date: Thu, 13 Jul 2017 12:59:19 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <63F0786E-681F-45E5-9288-79C28978C9BB@vmware.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/twtuVXkk9Si0X8PZzbNV9BBFeIk>
Subject: Re: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jul 2017 20:00:15 -0000


On 7/13/2017 12:39 PM, Dan Wing wrote:
>> On Jul 13, 2017, at 6:52 AM, Joe Touch <touch@isi.edu> wrote:
>>
>> FWIW, why not just add the entropy in the IPv6 flow ID rather than
>> expecting it at the transport layer? Intermediate network devices should
>> be relying only on the flow ID for that entropy anyway.
> I don't know if IPv6 routers do ECMP using flow ID, and I don't know if physical NICs do RSS CPU load balancing based on IPv6 flow ID.
I don't either, but *if* they (either one) does, they really should.

RFC 6438 discusses this issue and implies that flow ID isn't used
because it's mostly zero, but I wouldn't be surprised if that were to
change over time.

>
>> (and yes, that doesn't solve the problem for IPv4, but perhaps that's a
>> good reason to encourage use of IPv6)
> Yeah, for v4 we're stuck with using source UDP port to provide the ECMP and receiver benefit.
>
>
> What of NAT64?

Sure, that'd help, except we'd have to expect that an IPv4 router would
know to jump into the IPv6 flow ID to do ECMP. That seems more of a
stretch than the above, IMO.

Joe