Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team

Tom Herbert <> Fri, 17 February 2017 02:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE4391297EF for <>; Thu, 16 Feb 2017 18:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id soC1Q1CyUXDW for <>; Thu, 16 Feb 2017 18:17:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D78D71297E9 for <>; Thu, 16 Feb 2017 18:17:57 -0800 (PST)
Received: by with SMTP id k15so30525630qtg.3 for <>; Thu, 16 Feb 2017 18:17:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6BvD3Zahw7/lbvocypTFa2JIwK6OMUUf2cjkob/4DXY=; b=PZqeln2etR69yoCnblSK0HunTLpuUpSxpFzOQwCztwAAIUCLHfm0i/Irrvn3Cx8Y3z CNNCfuPk3KRZN3bWo0nnkQ7YFnyAC0uA+CoVyh/7u67+tOHk8EDlb1CrPtvw18AsCoV5 WSzEr0YZZGapCfnm0Ay3ySmMue6VANYfD1Xf9nWal5ryf1UX0JEu6eRO9Y6h5zV2nPMZ bHqffBCT7LiAmptQ1+6xfsC0utTTOsJ275mAaIszB0u7UaqPcAp7+DrxebqHgWGIeCbb doXdqRldyAVfj8k6XDNwMlwIIvpczG9dtX1BJWypcufn865gDDmCwBDvO2ItEYb1ML8F POsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6BvD3Zahw7/lbvocypTFa2JIwK6OMUUf2cjkob/4DXY=; b=DZ+1Z7U5y5h0detFx/2QX/ijAe+UefEABivWr0oLR+dBJU7hAIkHPrC8w5zKqIsnql uSlHVqT333zfnQBvAecLBdzWa9t/aMhn2Bgy8KSK9KA+TdqS6xGofgv0IRVB6uEzPrMy QcZqqyyBOXVGjVtiWK/usppv9xyJKMn6Yp5t2+7A05RNmMrFa9c+azqvKk1Py262jC0u AnBiaGkxauaYFBMPNIS1SQR6TFNdtguDjKk5sD59Mx1G0yV088R+Do6Vk5lczbTqELlE /JEYslY3iBXJT5i/JGP0oLQxjT7LlFLS/1443eilj9Ld3uTHR1zePsrbF3mTfr6qbwcl Q1uw==
X-Gm-Message-State: AMke39mAx0xC1tU7zWGarfIeXKgpovH5ux5BHT6OC0pRKQmsYPCVyUjvmyYfhWSGKWeWdJx5ebUL68AgjwqzRA==
X-Received: by with SMTP id 46mr4962586qtr.167.1487297876961; Thu, 16 Feb 2017 18:17:56 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 16 Feb 2017 18:17:56 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Thu, 16 Feb 2017 18:17:56 -0800
Message-ID: <>
To: Joe Touch <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Sam Aldrin <>, Sami Boutros <>, "" <>, "" <>, "" <>
Subject: Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Private mailing list for internal NVO3 Encapsulation Design Team discussions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Feb 2017 02:18:02 -0000

On Thu, Feb 16, 2017 at 4:48 PM, Joe Touch <> wrote:
> On 2/16/2017 4:39 PM, Tom Herbert wrote:
>> The operational issues we see with TLVs in terms of performance and
>> DDOS are not aberrations, they are fundamental issues we face in
>> deployment.
> Agreed, in the case where TLV sets are not fixed for a given path. The
> same is also true for bitfields: Ethernet uses a different Ethertypes
> for IPv4 and IPv6, even though they're intended to be treated as a
> single protocol class with internal versioning indicated by bitfields.
> Unknowns are the cause of the problem - in either case.

I agree with that, however there are fewer unknowns to deal with when
using bit-fields as opposed to TLVs. Once the sender and receiver
agree on options to be used, with bit-fields the order and length are
fixed. With TLVs these are variables that need to be considered with
each packet. This is why bit-fields naturally yield the simpler and
more feasible implementation. The trade-off for this simplicity is
loss of flexibility as pointed out by the draft. Defining 100s of
bit-fields in GUE probably wouldn't work. My response to that argument
is to ask why would we ever want to define 100s of extensions in a
protocol? Again, looking at other protocols that have extensibility we
see relatively few extensions being defined. IP has around 20 options,
TCP around 50. Grant it some of these options allow different lengths,
but for the most part defining new extensions seems to be a rare
occurrence. For GUE we estimated that after an initial set of
extensions have been defined (about ten), we'll maybe add one per
year. Extrapolating from this, we believe the protocol can accommodate
all the necessary extensibility for at least a thirty years.