IETF Logo Mail Archive

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

Joe Touch <touch@isi.edu> Fri, 21 July 2017 18:38 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 4E2F0131C73 for <nvo3@ietfa.amsl.com>; Fri, 21 Jul 2017 11:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ov7RZ549nVYA for <nvo3@ietfa.amsl.com>; Fri, 21 Jul 2017 11:38:22 -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 BAEF6131C6D for <nvo3@ietf.org>; Fri, 21 Jul 2017 11:38:22 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v6LIbuFi002018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Jul 2017 11:37:57 -0700 (PDT)
To: Dan Wing <dwing@vmware.com>, "Dale R. Worley" <worley@ariadne.com>
Cc: "nvo3@ietf.org" <nvo3@ietf.org>
References: <874lu6lef1.fsf@hobgoblin.ariadne.com> <770BFB45-B66F-4AA0-96EC-96CF3EBB32F4@vmware.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <da81884d-b331-9b2c-5032-3eddd282e728@isi.edu>
Date: Fri, 21 Jul 2017 11:37:53 -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: <770BFB45-B66F-4AA0-96EC-96CF3EBB32F4@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/WXLEquaZqMJ72PNQbZQTI16WUtg>
Subject: Re: [nvo3] Carrying entropy, was: 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: Fri, 21 Jul 2017 18:38:33 -0000

Hi, all,


On 7/21/2017 10:20 AM, Dan Wing wrote:
> For both points above:   are there cases where the outer header can't provide entropy of the inner headers?  With IPv4, Geneve is carried over UDP and the UDP source port works fine.  With IPv6, Geneve is carried over UDP and the UDP source port and IPv6 flow label can both be used.  Is Geneve carried over something that isn't UDP?  Said another way, do we want to burn Geneve option bits (and MTU) with this entropy information?
This seems a reasonable way forward.

I.e., entropy is useful to ECMP only if routers actually use those bits.
Using existing header fields as they're already interpreted by ECMP
makes more sense than expecting routers to peek into Geneve.

Joe

v2.23.0 | Report a Bug | By Email