IETF Logo Mail Archive

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

Joe Touch <touch@isi.edu> Thu, 13 July 2017 20:59 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 00D891267BB; Thu, 13 Jul 2017 13:59:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 d2hEHmynvSAf; Thu, 13 Jul 2017 13:59:43 -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 816EB129B19; Thu, 13 Jul 2017 13:59:43 -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 v6DKxLSM023487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Jul 2017 13:59:23 -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> <20426a5c-766b-323b-203c-113adf35c8ce@isi.edu> <08C1D3D7-F616-49B5-BED9-57AE7EC9E3BE@vmware.com> <3139e878-3aac-8eef-bfe9-1a57b08e27f3@isi.edu> <9D18C8E4-99CC-4880-8D39-0696C5516ED5@vmware.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <f57c1515-0058-aa76-86d8-718a4c8a138d@isi.edu>
Date: Thu, 13 Jul 2017 13:59:20 -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: <9D18C8E4-99CC-4880-8D39-0696C5516ED5@vmware.com>
Content-Type: multipart/alternative; boundary="------------8F282F5262963FF07AF9E426"
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/h4JuD7laWWOK6Hoh2PlgfKbiFTA>
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:59:45 -0000


On 7/13/2017 1:53 PM, Dan Wing wrote:
> I could envision a knob that if the encapsulated traffic is traversing a NAT64, then it could use the in-elegant solution (UDP source port number) *and* the IPv6 flow-ID.  An SDN controller could (or should) know if the traffic will traverse a NAT64.  If the encapsulated traffic remains on v6 (and flow-ID gives us ECMP and gives us RSS), then it could avoid putting flow entropy into the UDP source port.
Agreed.

Seems like all of this is worth including in the discussion.

Joe

v2.23.0 | Report a Bug | By Email