Re: [nvo3] RTG Dir QA review of draft-ietf-nvo3-gue

Tom Herbert <> Tue, 28 June 2016 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1ABA12D5CE for <>; Tue, 28 Jun 2016 10:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D-7ANjkkyaIc for <>; Tue, 28 Jun 2016 10:10:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22E3612D5C8 for <>; Tue, 28 Jun 2016 10:10:09 -0700 (PDT)
Received: by with SMTP id f30so22709207ioj.2 for <>; Tue, 28 Jun 2016 10:10:09 -0700 (PDT)
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=nztZvGKCCoYp+aBtn71ID69FJdUsGI9Ax7kSAE/RHKw=; b=RTXfaWJnQfTEQIqFlMCbAGSRSqYb0TKoKz4jmJ1Ar3X1g3wTzCFAFB98RaNcsXRKdu UXzVuOZg1edb1h5RlWP9QV5BGE6swCh6gauSzGr8nXA7berwbnY2jOK2ANdeMGwjvQK4 7BVhl9rVantiwkZPhUoKPID22XgkIsFtHM1EXJR1t2pyRstKva13gXoverNYn4t84bun G1Zn3R5Hhx+9Aa98iVsVc7T4uyV5g53uaiW/VZdQjlPtGvIPPtmNtVYf23FHkPQESc6T RGpCtUk1Lh77ruQHYToi4Xd7vWy+aSYQ2QvHp5WnA78XFXVADMgpslxppbig943mTHx8 /How==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nztZvGKCCoYp+aBtn71ID69FJdUsGI9Ax7kSAE/RHKw=; b=QVap55fOaW/FnlV0GnWOoo8bxUji1y4FtGL73pkXuuoiOvOV9BRZHu7Zio3Oev0Qdy rFz/34so5keBy+iT4OFydmDuiKuepTogAeqYhWdhE0Y2w8/M6C9euA69sX16OWezGfpK a2vPjWBbV+j4sCnQndf5lpYRIIhTKT4EQugYwdtbsm+/60YZel+H/UAX2dn7O/nEA21o /+nHwgBgSCIvThMhc8hlyPBrsOe+r5EmfX6ljbCV2rsf8rp84/NwsIWNg/Dad5szhyBv 59UBNpTxUL+jGqX2XrCz2/7ailCLhGA62teu+EXKD5wNWmQ886ZB7ziomOealX9iasEf E9Lg==
X-Gm-Message-State: ALyK8tL2myQl4EFkC/RB2vrTal1ox3Lj5vBxYQ6Hlj2w9F4xanh0X0cgGqtnCqCQ5+oeDvhatxUuawuhjUEOcA==
X-Received: by with SMTP id v26mr5259189ioi.107.1467133808424; Tue, 28 Jun 2016 10:10:08 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Jun 2016 10:10:07 -0700 (PDT)
In-Reply-To: <063201d1d11c$d5322da0$7f9688e0$>
References: <0e6201d1cb03$5f2f2280$1d8d6780$> <> <063201d1d11c$d5322da0$7f9688e0$>
From: Tom Herbert <>
Date: Tue, 28 Jun 2016 10:10:07 -0700
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc:, "" <>,, "" <>
Subject: Re: [nvo3] RTG Dir QA review of draft-ietf-nvo3-gue
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jun 2016 17:10:11 -0000

>> Yes, security and identifiers are being defined as well known
>> extensions. The reason for having a private data section is to allow
>> implementations or sites to extend the protocol for their own
>> purposes. They may or may not intend standardize. What we don't want
>> to happen is that people randomly reserved bits for their own purposes
>> so that in the future we we need to define a standard use for them we
>> can't because there is some significant deployment already using them.
>> This is especially a concern for an nvo3 protocol which is more of DC
>> protocol then protocol used on the Internet so we anticipate more
>> "customization".
> Yeah, I get the use case. I just don't like it :-)
> It's a hard line to draw. There's payload and there's overhead. I don't see that there is a way here to make people do the right thing - perhaps we shouldn't worry about that?
> An option is to define a new payload protocol and put it all in there. It's marginal.
> Anyway, I still think you might consider the use of an OID to help prevent surprises while processing what is otherwise unstructured/unknown data.
If we go this route I would suggest we add a "TLVs present" bit that
would indicate that the private data region contains well known TLVs.
The TLV format and name space could be based on those defined in
Geneve. With this Geneve protocol would then effectively be a subset
of GUE functionality, and conceptually is a way to unify two of the
three nvo3 proposed protocols.