Hello Tom et al.,
hmm, looking at the original email from Erik I wonder: have we made any
progress?
For the extensions hardware discussion: there is obviously no simple
truth. And ECMP is a well-defined task, this does not mean much for parsing
general TLV. I understood Erik's comment as a
Hello all,
Please find comments in-line.
-hao
发件人: nvo3 [mailto:nvo3-boun...@ietf.org] 代表 Erik Nordmark
发送时间: 2014年10月21日 23:37
收件人: nvo3@ietf.orgmailto:nvo3@ietf.org
主题: [nvo3] Concerns about NVO3 dataplane requirements document
I expressed this on the phone at the interim meeting
.
“
From: Erik Nordmark [mailto:nordm...@acm.org]
Sent: Friday, November 07, 2014 8:16 AM
To: David Mozes; Erik Nordmark
Cc: nvo3@ietf.orgmailto:nvo3@ietf.org; Marc Binderberger; Tom Herbert
Subject: Re: [nvo3] Concerns about NVO3 dataplane requirements document +BFD
On 11/6/14 10:37 AM, David Mozes
: Friday, November 07, 2014 8:16 AM
To: David Mozes; Erik Nordmark
Cc: nvo3@ietf.org; Marc Binderberger; Tom Herbert
Subject: Re: [nvo3] Concerns about NVO3 dataplane requirements document +BFD
On 11/6/14 10:37 AM, David Mozes wrote:
Sorry regarding the confusion .
However , I referring to BFD
.*
**
“
*From:*Erik Nordmark [mailto:nordm...@acm.org]
*Sent:* Friday, November 07, 2014 8:16 AM
*To:* David Mozes; Erik Nordmark
*Cc:* nvo3@ietf.org; Marc Binderberger; Tom Herbert
*Subject:* Re: [nvo3] Concerns about NVO3 dataplane requirements
document +BFD
On 11/6/14 10:37 AM, David Mozes
; Erik Nordmark; Tom Herbert
Cc: nvo3@ietf.org
Subject: Re: [nvo3] Concerns about NVO3 dataplane requirements document
On 10/22/14 5:20 PM, Marc Binderberger wrote:
To pick up some of the points:
VNI: we live with flat IP addresses and yet they support the rich
structure in the name space. I
[mailto:nvo3-boun...@ietf.org] On Behalf Of Erik Nordmark
Sent: Saturday, October 25, 2014 3:45 AM
To: Marc Binderberger; Erik Nordmark; Tom Herbert
Cc: nvo3@ietf.org
Subject: Re: [nvo3] Concerns about NVO3 dataplane requirements document
On 10/22/14 5:20 PM, Marc Binderberger wrote:
To pick up some
Nordmark; Tom Herbert
Cc: nvo3@ietf.orgmailto:nvo3@ietf.org
Subject: Re: [nvo3] Concerns about NVO3 dataplane requirements document
On 10/22/14 5:20 PM, Marc Binderberger wrote:
To pick up some of the points:
VNI: we live with flat IP addresses and yet they support the rich
structure in the name
Meta-Data: I probably missed some discussions (sorry!) but what data
would this be?
As I tried to clarify in my response to Tom the meta-data discussion in the
IETF
was mostly about vendor-specific service meta-data, but perhaps this term is
being used for more general extensibility?
On 10/26/14 1:20 PM, Tom Herbert wrote:
On Fri, Oct 24, 2014 at 5:44 PM, Erik Nordmark nordm...@acm.org wrote:
It would be good for the NVO3 WG to have a clear understanding of what data
needs to be carried with each encapsulated frame. That helps determine how
flexible and extensible the
On 10/25/14 11:28 PM, Marc Binderberger wrote:
For my comment about IPSEC/AH:
One question is whether the higher assurance is just for the VNI or for the
whole encapsulated frame. Using something like ESP/AH takes us down the
path of protecting the whole frame, which might be overkill.
agree.
Hello Erik,
I guess we still need to have some idea how many bits would be required up
front (24, 32, more?) and whether we think this field needs to be
extensible.
I would go with a VNI of 24 or 32bit as this seems reasonable. I still have
to understand why the data plane processing would
On 10/23/14 8:35 AM, Tom Herbert wrote:
Meta-Data: I probably missed some discussions (sorry!) but what data would
this be?
Security option to validate VNID/encapsulation headers, congestion
control data at encapsulation layer if we develop a method that uses
inband signaling, data
On 10/22/14 5:20 PM, Marc Binderberger wrote:
To pick up some of the points:
VNI: we live with flat IP addresses and yet they support the rich structure
in the name space. I don't see why this should be different with overlay
headers: the control plane (or the configuration) will know about
On 10/24/14 2:24 PM, Tom Herbert wrote:
Tom,
Those are useful features to consider. However, I wouldn't view
them as being part of the meta-data discussion. The meta-data
discussion was triggered by the Geneve draft which proposed ways
to encode vendor-specific data e.g. for
Just one comment...
On Oct 23, 2014, at 8:35 AM, Tom Herbert therb...@google.com wrote:
Security: could we re-use IPSEC ESP/AH ? In tunnel mode as we would add
already an underlay IPv4/IPv6 header?
(I'm no expert in this area but why not re-using other peoples work)
Interoperability
Hello Eric and Tom,
from Eric's signature:
Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away.
I think this is what Eric tries to achieve :-) Reading the document there is
some good background/motivation but sometimes many options
I expressed this on the phone at the interim meeting and was asked to
post with a bit more detail.
According to the call the intended purpose of the requirements document
is to help the WG choose between different proposed dataplane
encapsulation protocols. However, I get the impression
Hi Eric,
Thank you for sending this. Some comments in line.
On Tue, Oct 21, 2014 at 8:37 AM, Erik Nordmark nordm...@acm.org wrote:
I expressed this on the phone at the interim meeting and was asked to post
with a bit more detail.
According to the call the intended purpose of the
On 10/21/14 12:33 PM, Tom Herbert wrote:
Agreed, but I think there are a few more probably.
Tom,
I think so too - just need to get the specific requirements written down
and get some consensus.
- MUST contain an VNID field. This field MUST be large enough to scale to
100's of thousands
20 matches
Mail list logo
