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

On 2/17/2017 9:04 AM, Tom Herbert wrote: > But again, we don't have any examples of a protocol with ordered TLVs > that does this and there is no concrete proposal for doing this in > Geneve so this idea is just speculation. Ordered TLVs are the same thing as bitfields in known orders. The only

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

>> 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. > > I gave an example above where that's not the case. A value in a

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

> On Feb 16, 2017, at 6:17 PM, Tom Herbert wrote: > >> 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

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

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

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

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:

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

On Thu, Feb 16, 2017 at 4:20 PM, Joe Touch wrote: > Hi Tom, > > > On 2/16/2017 4:10 PM, Tom Herbert wrote: > > But, as I said this idea creates a new dependency on a control plane > which is TBD. I'm afraid this could be a opening a Pandora's box of > new complexity that the group

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

Hi Tom, On 2/16/2017 4:10 PM, Tom Herbert wrote: >>> But, as I said this idea creates a new dependency on a control plane >>> which is TBD. I'm afraid this could be a opening a Pandora's box of >>> new complexity that the group didn't bargain for... >> You need a control plane to setup the

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

On 2/16/2017 3:45 PM, Tom Herbert wrote: > On Thu, Feb 16, 2017 at 3:30 PM, Joe Touch wrote: >> >> On 2/16/2017 3:26 PM, Tom Herbert wrote: >>> Admittedly, without any actual TLVs defined in Geneve all of this is >>> all just speculation on my part! >>> >>> Tom >> Agreed, and

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

On Thu, Feb 16, 2017 at 3:30 PM, Joe Touch wrote: > > > On 2/16/2017 3:26 PM, Tom Herbert wrote: >> Admittedly, without any actual TLVs defined in Geneve all of this is >> all just speculation on my part! >> >> Tom > Agreed, and more specifically, regardless of the flexibility of

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

On Thu, Feb 16, 2017 at 1:21 PM, Joe Touch wrote: > > > On 2/16/2017 1:14 PM, Tom Herbert wrote: >> On Thu, Feb 16, 2017 at 1:11 PM, Joe Touch wrote: >>> >>> On 2/16/2017 12:27 PM, Tom Herbert wrote: The problems of TLVs, particularly that they are unordered,

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

On 2/16/2017 1:14 PM, Tom Herbert wrote: > On Thu, Feb 16, 2017 at 1:11 PM, Joe Touch wrote: >> >> On 2/16/2017 12:27 PM, Tom Herbert wrote: >>> The problems of TLVs, particularly that they are unordered, require >>> iterative processing, >> That's trivially avoided by forcing

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

On Thu, Feb 16, 2017 at 1:11 PM, Joe Touch wrote: > > > On 2/16/2017 12:27 PM, Tom Herbert wrote: >> The problems of TLVs, particularly that they are unordered, require >> iterative processing, > That's trivially avoided by forcing the order. > > As I noted before, all that is

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

On 2/16/2017 12:27 PM, Tom Herbert wrote: > The problems of TLVs, particularly that they are unordered, require > iterative processing, That's trivially avoided by forcing the order. As I noted before, all that is required for equivalently easy processing is that both TLVs and bitfields use

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

> In the security section you provided text for, we talked about the > possibility of authenticating the tunnel header and payload via extensions > to address concern of spoofing VNI and payload security. Please look at draft-herbert-gue-extensions, that draft realizes the "possibility of

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

On 2/15/17, 2:36 PM, "Tom Herbert" wrote: >On Wed, Feb 15, 2017 at 9:36 AM, Sami Boutros wrote: >> Hi Tom, >> >> >> >>>The Security Considerations section needs content. First and foremost, >>>in a multi-tenant data center ensuring strict

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

On Wed, Feb 15, 2017 at 9:36 AM, Sami Boutros wrote: > Hi Tom, > > > >>The Security Considerations section needs content. First and foremost, >>in a multi-tenant data center ensuring strict isolation between >>different tenants traffic seems fundamental and the mechanisms for

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

Hi Tom, >The Security Considerations section needs content. First and foremost, >in a multi-tenant data center ensuring strict isolation between >different tenants traffic seems fundamental and the mechanisms for >doing that should be explicit in the description of an encapsulation. >Bear in