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

worley@ariadne.com (Dale R. Worley) Sat, 22 July 2017 00:31 UTC

Return-Path: <worley@alum.mit.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 EE39D1243F3 for <nvo3@ietfa.amsl.com>; Fri, 21 Jul 2017 17:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 ZFFUG-IcEoDO for <nvo3@ietfa.amsl.com>; Fri, 21 Jul 2017 17:31:17 -0700 (PDT)
Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C23C120721 for <nvo3@ietf.org>; Fri, 21 Jul 2017 17:31:16 -0700 (PDT)
Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id YiKBd403O8biCYiKBdIBh5; Sat, 22 Jul 2017 00:31:15 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-05v.sys.comcast.net with SMTP id YiK9dq9leWEpEYiKAd9mmB; Sat, 22 Jul 2017 00:31:15 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v6M0VCJ9021876; Fri, 21 Jul 2017 20:31:12 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v6M0VBaX021863; Fri, 21 Jul 2017 20:31:11 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Dan Wing <dwing@vmware.com>
Cc: nvo3@ietf.org, touch@isi.edu
In-Reply-To: <770BFB45-B66F-4AA0-96EC-96CF3EBB32F4@vmware.com> (dwing@vmware.com)
Sender: worley@ariadne.com
Date: Fri, 21 Jul 2017 20:31:10 -0400
Message-ID: <87k231jos1.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfCZ9smK3EsIts04hZmpiQYvPeKj+fwWtbTAeVLJPhzWtLk5rzaVghNqw1jaisOws75+gBabyIfJjyWbjnc9jlDWy3l+mg/gaomD/wjhAStaBNClg9bGu p8kMRFQ9K3MogAAqjWBKNd6eXiUfkwpvF3cpjQry4Udrpv8udm5k58OEjNcq9vkktvGLP+UX+np/oJayZZfbssIzc1yHKUpRJU4=
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/iNhAQnEZF4MmZ420DrHsacGYHsQ>
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: Sat, 22 Jul 2017 00:31:18 -0000

Dan Wing <dwing@vmware.com> writes:
> 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?

I envision Geneve -- as a *generalized* encapsulation technique -- being
used in a broader class of applications.  E.g., Geneve directly over IP,
or over 802.1, or possibly even Geneve directly over the physical medium
(presumably for point-to-point use).  I've always been in favor of
generalizing mechanisms, as long as nobody is *required* to support its
use in full generality and as long as it doesn't introduce overhead into
systems that don't need the generality.

Hence, in this case, having ways of permitting an operational
environment to put entropy in Geneve headers that don't constrain users
of Geneve in more prosaic circumstances.

Dale