Re: [nvo3] WG adoption for draft-boutros-nvo3-geneve-applicability-for-sfc
worley@ariadne.com (Dale R. Worley) Fri, 29 March 2019 02:23 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 ABC591200EA for <nvo3@ietfa.amsl.com>; Thu, 28 Mar 2019 19:23:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 8XF0dK3i0K2d for <nvo3@ietfa.amsl.com>; Thu, 28 Mar 2019 19:23:40 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 A9D2212001A for <nvo3@ietf.org>; Thu, 28 Mar 2019 19:23:40 -0700 (PDT)
Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id 9gdVhO4tS194g9hBDhVRQA; Fri, 29 Mar 2019 02:23:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1553826219; bh=dkGZx60zF2I2kqxS1KhfoiWxPk5ZCCaG5dBzHUI8N9Y=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Qe51+3D3Bw0VJwx2Br0FsrprwERRN4SpwVFer1ggc/dHP+wT/YRPtknzCCxZgCKuj FfFb0tthqUWbUIJUfG2odjIWWYVtrb3wAQ/csaPWymBLgVzBvezPxKpMJdRC972vnp GzzC2DxXgqS2fWsj/q87bcvjRDdXYP8eg0Q66EkHZ+3s0YJvjY2hwNJlSdXX34uoMW sWsfHL7UuhKgWlxM7j0zpWSSjPYp8m7FI79RlcFk/FFBLxM1lLqxPWAWbKvYzmGckb jva6uj1aDm+cPYF2y5sGy65K2xnL+HZlLRfOPyhns1WrYN419WwlD+Z+3n6BtYFfuj yf/tGsKAkPOjA==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with ESMTPA id 9hBChXdQ7OJh29hBDh9MuM; Fri, 29 Mar 2019 02:23:39 +0000
X-Xfinity-VMeta: sc=0;st=legit
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 x2T2NbHC020241; Thu, 28 Mar 2019 22:23:37 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x2T2Nbot020238; Thu, 28 Mar 2019 22:23:37 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Sami Boutros <boutross=40vmware.com@dmarc.ietf.org>
Cc: nvo3@ietf.org
In-Reply-To: <07AEF6D3-7A28-482B-A22A-D27F8481B510@vmware.com> (boutross=40vmware.com@dmarc.ietf.org)
Sender: worley@ariadne.com
Date: Thu, 28 Mar 2019 22:23:36 -0400
Message-ID: <87wokiju53.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/kojSz5_bn5jXVJcMLOSk7HYNPXs>
Subject: Re: [nvo3] WG adoption for draft-boutros-nvo3-geneve-applicability-for-sfc
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.29
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, 29 Mar 2019 02:23:43 -0000
Just a nit, but looking at the -03, version, I can see how the proposed Geneve option is parsed, but what is the plan for the future? Currently, the first 4 octets of the option data have a fixed format. If the H flag-bit is present (in the 5th bit of the option data), then the last 38 octets are the HMAC information (which seems to have redundant type and length fields). The remaining octets are divided into a list of IPv4 or IPv6 addresses. (Presumably the type is determined by context.) But it's not clear to me how this generalizes. It seems like the tail of the option data is intended to be a series of TLV items, but how does one find the dividing point between the SF address list and the TLVs? Dale
- Re: [nvo3] WG adoption for draft-boutros-nvo3-gen… Sami Boutros
- Re: [nvo3] WG adoption for draft-boutros-nvo3-gen… Dale R. Worley