irtually impossible to add a new field to GRE for instance).
Thanks,
Tom
> Regards
> Lizhong
>
>> -Original Message-
>> From: Tom Herbert [mailto:therb...@google.com]
>> Sent: 2014年2月12日 0:03
>> To: nvo3@ietf.org
>> Subject: [nvo3] Fwd: New Version Notif
I have a general question on vsid, vnid's.
nvgre, vxlan, and now Geneve all define a 24 bit virtual network
identifier in their packet formats. What is so magical about this
size? I can understand that nvgre needs to not use full 32 bits in
keyid and wants some bits for flow hash, but UDP based en
tion between virtual
networks is super critical, in the case of third party vms we can't
assume the monitoring and detection which is already deployed in the
native infrastructure.
Thanks,
Tom
> Pankaj
>
> From: Tom Herbert
> Sent: S
case, whether or not IPsec is used, the encap header really needs to
>> be secured somehow. Maintaining isolation between virtual networks is
>> super critical, in the case of third party vms we can't assume the monitoring
>> and detection which is already deployed in the native infrastr
On Fri, Feb 28, 2014 at 3:24 PM, Sam Aldrin wrote:
> Hi all,
>
> Read the draft but have few questions on the same line others have asked.
>
> - Is this draft intended for standardizing within NVo3 WG? The status
> indicates it as informational. Also it is good to have it as draft-nvo3,
> if i
Hi Anton,
What you are describing is header data split which is where a device
splits header and data portions of packet into two buffers so that
data can be page aligned (or as least in a different cache line as you
pointed out). Several NICs have already implemented this with TCP to
split out TC
On Mon, Mar 3, 2014 at 12:05 AM, Anton Ivanov (antivano)
wrote:
> Hi all,
>
> I would like to address one more issue which has been omitted so far from
> the background to the discussion.
>
> If we restrict the use cases to virtualization (which is the remit of NVO3),
> the assumption that variabl
to
add new fields, although it would be verbose (many fields, like ports,
are probably unnecessary).
4) So congestion control probably warrants an additional field. I
suspect it should be variable length field like SEC to allow pluggable
CC.
Thanks,
Tom
> Regards
> Lizhong
>
>> -
On Thu, Mar 6, 2014 at 7:24 PM, Lizhong Jin wrote:
> Hi Tom, see inline below.
>
> Regards
> Lizhong
>
>> -Original Message-
>> From: Tom Herbert [mailto:therb...@google.com]
>> Sent: 2014年3月7日 0:42
>> To: Lizhong Jin
>> Cc: nvo3@ietf.org;
On Mon, Mar 10, 2014 at 11:48 AM, Lucy yong wrote:
> Hi Authors,
>
>
>
>“Transit device. A forwarding element along the path of the tunnel.
>
>A transit device MAY be capable of understanding the Geneve frame
>
>format but does not originate or terminate Geneve packets.”
>
>
>
> Could
> I suspect the answer is not as cut-and-dried as some may
> think it is.
>
>
>
> If – as your mail suggests – there really is a willingness
> among those
>
> who have currently deployed solutions, to switch to a common encapsulation,
>
> it would be very useful if e
On Mon, Mar 10, 2014 at 12:49 PM, Lucy yong wrote:
>
>
> -Original Message-
> From: Tom Herbert [mailto:therb...@google.com]
> Sent: Monday, March 10, 2014 2:29 PM
> To: Lucy yong
> Cc: draft-gross-gen...@tools.ietf.org; nvo3@ietf.org
> Subject: Re: [nvo3] quest
On Mon, Mar 10, 2014 at 1:29 PM, Lucy yong wrote:
> Please see in-line below w/ [Lucy1]
>
> -Original Message-
> From: Tom Herbert [mailto:therb...@google.com]
> Sent: Monday, March 10, 2014 3:23 PM
> To: Lucy yong
> Cc: draft-gross-gen...@tools.ietf.org; nvo3@i
Hi Lucy, thanks for the comments!
On Mon, Mar 10, 2014 at 2:51 PM, Lucy yong wrote:
> Hi Tom,
>
>
>
> I read this draft. It is interesting proposal. It is indeed another
> tunneling encapsulation proposal and aims in applying to NVO as well (not
> limited to).
>
>
>
> Regarding the semantics, it
On Tue, Mar 11, 2014 at 9:49 AM, Lucy yong wrote:
> Hi Tom,
>
> Please see in-line below.
>
> -Original Message-----
> From: Tom Herbert [mailto:therb...@google.com]
> Sent: Monday, March 10, 2014 7:14 PM
> To: Lucy yong
> Cc: nvo3@ietf.org
> Subject: Re: comment
On Thu, Mar 13, 2014 at 7:25 PM, Zhou, Han wrote:
> Hi folks,
>
> We posted a draft as an extension to VXLAN. Please take a look.
>
> The motivation came from our experiments on VXLAN optimization. It seems lots
> of discussions ongoing about the necessity of adding metadata to transport
> header
>> - I believe this would conflict with the proposal to add a protocol
>> field to the VXLAN header. Overloading one field in a fixed header is
>> not an adequate substitute for a truly extensible header. In the best
>> case we could only use one or the other functionality in a given
>> packet. In
On Thu, Mar 20, 2014 at 7:20 PM, Pankaj Garg wrote:
> I agree with you in spirit that carrying 1K of metadata to transport 64B
> payload won’t make sense. The question is, how do we need the right size of
> metadata ahead of time such as 16-bytes or 4-bytes or 64-bytes? Hence the
> argument for fl
On Mon, Mar 24, 2014 at 10:34 AM, Erik Nordmark wrote:
> On 3/14/14 8:52 PM, Zhou, Han wrote:
>>
>>
>> Tom, the point of this draft is that the "last possible point in the
>> stack" can
>> be pushed to the remote end-point of the VXLAN tunnel. If the remote
>> is an hypervisor, this GSO is termina
> This is a larger topic, and certainly there have been many Foo-over-UDP
> and generic-UDP-tunnel/encap proposals out there.
>
Yes, I'm aware of those. But I think that the fact that many
Foo-over-UDP seem to require more than just encapsulating the basic
format might be problematic and is requiri
> You do not need to specify anything here. You can just offset yourself and
> stick the extra fields between a _STANDARD_ L2TPv3 header and the payload.
> Due to L2TPv3 not specifying an Ethertype in the header you can offset the
> data by as much as you wish and stick in there whatever you wish.
On Tue, Jul 15, 2014 at 4:32 PM, Paul Quinn (paulq) wrote:
> Hi Tom,
>
> Thanks for the questions and comments! Please see inline.
>
> On Jul 14, 2014, at 3:43 PM, Tom Herbert wrote:
>
>> Hi VXLAN-gpe authors,
>>
>> Abstract: technically this is not
On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci wrote:
>> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and
>> requires the assignment of a new UDP port. The fact that the VXLAN-GPE
>> header closely resembles VXLAN may be convenient for implementers, but this
>> protocol b
scope of this draft."
Thanks,
Tom
>
> Regards, Marc
>
>
>
> On Sun, 27 Jul 2014 17:28:01 -0700, Tom Herbert wrote:
>> On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci wrote:
>>>> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and
>>>&
of that-- the behavior is non-deterministic. Maintaining compatibility
with such devices is a hard problem and might imply constraints on new
options that could fundamental change parsing or interpretation of the
packet (adding protocol type is a good example case).
Thanks,
Tom
> Thanks,
vides 20 bytes of data we can use for
optional data and still be "HW friendly"?
Thanks,
Tom
> - Larry
>
> On 7/30/14 2:46 PM, "Tom Herbert" wrote:
>
>>> I think the intent of NSH is to be generic enough to work at different
>>> layers. The rec
On Thu, Jul 31, 2014 at 5:56 AM, Paul Quinn (paulq) wrote:
>
>
>
> On Jul 30, 2014, at 8:16 PM, Tom Herbert wrote:
>
>> On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger)
>> wrote:
>>> Hi Tom,
>>>
>>> First, the VXLAN-GPE Next Proto
er of gates, while OAM does not, the successful delivery of
>>>> OAM is only an approximate indication of the data-path integrity. Any H/W
>>>> that data has to go through, and OAM does not go through, could fail and we
>>>> would see an OAM indication of a valid path through which da
On Sun, Aug 3, 2014 at 10:16 PM, Pankaj Garg wrote:
> Hi All,
>
>
>
> As discussed in the NVO3 forum in the past, we intend to take NVGRE to
> informational RFC status. This would ensure that there is a stable way to
> build compliant and interoperable NVGRE implementation. It would also allow
> e
ssage --
From:
Date: Tue, Aug 26, 2014 at 1:39 PM
Subject: New Version Notification for draft-herbert-remotecsumoffload-00.txt
To: Tom Herbert
A new version of I-D, draft-herbert-remotecsumoffload-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.
>> I'm not sure how practical this is. There's already deployment to use
>> the flow label as representative of inner flow (like for ECMP hashing,
>> etc.).
>
> Is this use in the flow label fields of the outer IPv6 packets when they're
> the encapsulation protocol between NVEs in the underlay net
cribed without reference to
VMs unless there really is something VM specific about that.
Tom
> Anyone has better suggestions?
>
>
> Thank, Linda
>
> -Original Message-
> From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Black, David
> Sent: Friday, October 03, 201
is for
address mobility in realm DC network virtualization (i.e. this should
not be reinventing mobile IP for instance)
Tom
>
>
> Linda
>
>
>
> From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: Monday, October 06, 2014 2:16 PM
>
> While it&#
On Mon, Oct 6, 2014 at 1:43 PM, Behcet Sarikaya wrote:
> On Mon, Oct 6, 2014 at 3:00 PM, Tom Herbert wrote:
>> On Mon, Oct 6, 2014 at 12:41 PM, Linda Dunbar
>> wrote:
>>> Tom,
>>>
>>> Are you saying that the term “VM” should only be described in mot
On Tue, Oct 7, 2014 at 7:33 PM, Sri Gundavelli (sgundave)
wrote:
>
> Hi Thomas,
>
>
> > No. Let's please not go here.
>
> No .. no. My comment is not intended to argue against inventing a new
> approach; I'm not in the way. But, if we do not discuss and show a
> reasonable technical argument as wh
Hi Linda,
Thank you for adding this section to the draft. Some comments in line...
>
> L3 Address Migration
>
> When the attachment to NVE is L3 based, TS migration can cause one
> subnetwork to be scatted among many NVEs, or fragmented addresses.
>
> The outbound traffic of fragmented L3 address
On Wed, Oct 15, 2014 at 2:02 PM, Linda Dunbar wrote:
> Tom,
>
> I am a bit confused of your comments. See questions inserted below:
>
>
> -Original Message-
> From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Tom Herbert
>
> Security should be consid
uldn't move their
VM behind an NVE that doesn't provide encryption. I would view this as
a scheduling constraint more than anything.
Tom
>
> Thank you. Linda
>
> -Original Message-
> From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: W
Hi Eric,
Thank you for sending this. Some comments in line.
On Tue, Oct 21, 2014 at 8:37 AM, Erik Nordmark 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 requirements document
uot;From an NVO3 perspective, it should be assumed that where the
document uses the term "VM" and "hypervisor", the intention is that
the discussion also applies to other systems"
> - Larry
>
> On 10/30/14 2:52 PM, "Tom Herbert" wrote:
>
>>On Thu
On Tue, Nov 11, 2014 at 12:33 PM, Larry Kreeger (kreeger)
wrote:
> Hi Weiguo,
>
> What do you envision this marking looking like? e.g. is it just a single
> flag bit, or large field with a counter or sequence number, or some kind of
> flow ID? If not a single flag, how large do you see the field
would get a time stamp from just a single mark on a packet?
> Regards,
> Greg
>
> On Tue, Nov 11, 2014 at 1:42 PM, Tom Herbert wrote:
>>
>> On Tue, Nov 11, 2014 at 12:33 PM, Larry Kreeger (kreeger)
>> wrote:
>> > Hi Weiguo,
>> >
>> > What d
On Tue, Nov 11, 2014 at 7:04 PM, Haoweiguo wrote:
> Hi Tom,
> Pls see inline with [weiguo].
> Thanks
> weiguo
>
> ________
> 发件人: Tom Herbert [therb...@google.com]
> 发送时间: 2014年11月12日 8:22
> 收件人: Greg Mirsky
> 抄送: Larry Kreeger (kree
On Wed, Nov 12, 2014 at 12:55 AM, Mach Chen wrote:
> Hi Greg and all,
>
>
>
> Single bit is not sufficient if someone wants to perform loss and delay
> measurement simultaneously, then two bits needed.
>
Is that necessary? Can they share the same time quantum (as well as
other metrics maybe to be
rds,
> Marc
>
>
>
> On Wed, 12 Nov 2014 09:34:52 +, Mach Chen wrote:
>> Hi Tom,
>>
>>> -Original Message-
>>> From: Tom Herbert [mailto:therb...@google.com]
>>> Sent: Wednesday, November 12, 2014 5:06 PM
>>> To: Mach Chen
>
On Wed, Nov 12, 2014 at 5:13 PM, Mach Chen wrote:
> Hi Tom,
>
>> -Original Message-----
>> From: Tom Herbert [mailto:therb...@google.com]
>> Sent: Thursday, November 13, 2014 3:11 AM
>> To: Marc Binderberger
>> Cc: Mach Chen; Greg Mirsky; Haoweiguo; nvo3@ie
;
>>>
>>> One comment in line
>>>
>>>> On Nov 13, 2014, at 11:47 PM, Vero Zheng wrote:
>>>>
>>>> Hi Tom,
>>>>
>>>> Please see in-line.
>>>>
>>>> BR, Vero
>>>>
>>>>> --
-- Forwarded message --
From:
Date: Thu, Nov 13, 2014 at 12:19 AM
Subject: New Version Notification for draft-herbert-remotecsumoffload-01.txt
To: Tom Herbert
A new version of I-D, draft-herbert-remotecsumoffload-01.txt
has been successfully submitted by Tom Herbert and posted to the
IETF
gt;addressed to the local MEP/MP.
>>>
>>>Not other way around. Why? Because we want OAM to be as closely as
>>>possible follow the Data path.
>>>
>>>If we need to have performance and delay measurements, we SHOULD NOT
>>>mutate the packet hea
Sent: Wednesday, November 19, 2014 8:45 PM
>> To: Haoweiguo; Tom Herbert
>> Cc: Greg Mirsky; Tapraj Singh; Deepak Kumar (dekumar); nvo3@ietf.org
>> Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM
>>
>> Hi Weiguo, Mach et,al
>>
>> T
timestamps.
>
> >
> > For loss measurement, why we have to count traffic for marked packets only
> > and
> > not maintain counters per flow?
>
> I'm not sure what's your question here.
>
> To calculate the packet loss, counters maintenance (no
.
Comments are appreciated.
Thanks,
Tom
-- Forwarded message --
From:
Date: Wed, Nov 26, 2014 at 2:42 PM
Subject: New Version Notification for draft-herbert-guecsum-00.txt
To: Tom Herbert
A new version of I-D, draft-herbert-guecsum-00.txt
has been successfully submitted by Tom
draft-herbert-vxlan-rco-00.txt
To: Tom Herbert
A new version of I-D, draft-herbert-vxlan-rco-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.
Name: draft-herbert-vxlan-rco
Revision: 00
Title: Remote checksum offload for VXLAN
On Thu, Jan 29, 2015 at 1:53 PM, Linda Dunbar wrote:
> When a NVE is initialized or re-started, it uses Virtual Network scoped
> instances of the IS-IS to announce all the Virtual Networks in which it is
> participating.
>
>
>
> The current draft-dunbar-nvo3-nva-mapping-distribution-01 suggests u
https://www.cs.purdue.edu/homes/kompella/publications/infocom13.pdf
On Wed, Mar 4, 2015 at 2:55 PM, Larry Kreeger (kreeger)
wrote:
> Hi Sunil,
>
> It seems like your question would be more appropriate for the NVO3 mailer
> than the SFC one (so I added NVO3).
>
> Note that the ideas covered in dra
2:11 PM
Subject: New Version Notification for draft-herbert-gue-03.txt
To: Tom Herbert , Osama Zia
A new version of I-D, draft-herbert-gue-03.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.
Name: draft-herbert-gue
Revision: 03
Title
On Fri, Mar 13, 2015 at 9:01 AM, Elzur, Uri wrote:
> in the first few presentations of the virtual FtF we heard of some
> guidelines and some implementation ideas
>
> I was wondering what are the group's guidelines as to what minimal content
> needed to be carried in the header. Clearly there i
Hello,
I believe (perhaps with some bias!) that the encaps design team did a
fairly thorough job in enumerating the key common issues of
encapsulation. I think this work is useful to apply to selecting a
data plane protocol for NVO3.
I would like suggest that a way forward with the NVO3 data plan
On Thu, Mar 19, 2015 at 11:31 AM, Benson Schliesser
wrote:
> This message starts a 2-week Call for Adoption of draft-herbert-gue-03 as a
> NVO3 WG item.
>
Benson asked me to query the list on this...
There is a subtlety for GUE.
draft-herbert-gue-03 specifies GUE as a generic encapsulation
proto
I am not aware of any relevant IPR for GUE.
Thanks,
Tom
On Fri, Mar 20, 2015 at 1:55 PM, Bocci, Matthew (Matthew)
wrote:
> This mail starts an IPR poll on
> draft-herbert-gue-03.
>
> Authors, are you aware of any IPR that applies to
> draft-herbert-gue-03?
>
> If so, has this IPR been disclosed
Support as co-author.
Tom
On Thu, Mar 19, 2015 at 11:31 AM, Benson Schliesser
wrote:
> This message starts a 2-week Call for Adoption of draft-herbert-gue-03 as a
> NVO3 WG item.
>
> The chairs believe that WG consensus is in favor of adoption of this draft.
> Please reply to this email thread,
GUE.
It does cover the the semantics of use such as how to determine tunnel
Path MTU, when to fragment.
Thanks,
Tom
-- Forwarded message --
From:
Date: Wed, Mar 25, 2015 at 9:09 PM
Subject: New Version Notification for draft-herbert-gue-fragmentation-00.txt
To: Tom Herbert ,
ed message --
From:
Date: Thu, Mar 26, 2015 at 7:57 AM
Subject: New Version Notification for
draft-herbert-gue-encap-considerations-01.txt
To: Tom Herbert , Osama Zia
A new version of I-D, draft-herbert-gue-encap-considerations-01.txt
has been successfully submitted by Tom Herbert and
On Wed, Apr 1, 2015 at 12:55 PM, Joe Touch wrote:
>
>
> On 3/25/2015 9:58 PM, Tom Herbert wrote:
>> This draft describes a fragmentation option for GUE. The option is
>> intended for use cases where GUE is used over a network where we might
>> not be able to control or
On Tue, Apr 7, 2015 at 12:02 AM, Lizhong Jin wrote:
> Hi Erik,
> Thanks for the draft. I suggest to add one consideration: the generation of
> entropy value.
> 1. When the node receive an UDP/TCP packet from the tenant, then entropy
> value could be a hash value of 5-tuple.
> 2. When the node rece
On Thu, Apr 9, 2015 at 10:46 AM, Erik Nordmark wrote:
> On 4/8/15 8:11 PM, Lizhong Jin wrote:
>>
>> [Lizhong] If the NVE and tenant is integrated into one device, then the
>> issue could
>> be solved by implementation. Because tenant know the entropy value of the
>> first
>> segment, and use the s
On Wed, Apr 15, 2015 at 5:42 PM, Erik Nordmark wrote:
> On 4/9/15 10:56 AM, Tom Herbert wrote:
>>
>> On Thu, Apr 9, 2015 at 10:46 AM, Erik Nordmark wrote:
>>>
>>> I thought the purpose of RFS was to send the packet (and associated
>>> interrupt) t
On Tue, May 5, 2015 at 10:53 AM, Joe Touch wrote:
>
>
> On 5/5/2015 9:39 AM, Templin, Fred L wrote:
>> Hi Joe,
> ..
>>> IP in UDP adds only port numbers and an Internet checksum.
>>>
>>> That doesn't address fragmentation; if outer fragmentation is assumed,
>>> IPv4 needs to be rate-limited to avo
d ID collisions and the Internet
>>>>> checksum is insufficient to correct those collisions.
>>>>
>>>> Right - that is why we have GUE. But, when these functions are not
>>>> needed GUE can perform header compression and the result looks
>>>>
t;
>> >>>> That doesn't address fragmentation; if outer fragmentation is assumed,
>> >>>> IPv4 needs to be rate-limited to avoid ID collisions and the Internet
>> >>>> checksum is insufficient to correct those collisions.
>> >>
On Tue, May 5, 2015 at 10:48 AM, Joe Touch wrote:
>
>
> On 5/5/2015 10:23 AM, Larry Kreeger (kreeger) wrote:
> ...
>>> IP is a protocol. v4 and v6 are versions.
>>
>> While I completely agree architecturally, when it comes down to
>> implementations, the only downside I see are that it uses multip
On Tue, Jun 2, 2015 at 11:51 AM, Michael Shieh wrote:
> How about using IPsec with transparent mode? the security model has been
> proven in the field.
>
Do you mean transport mode?
> - Michael
>
>
> On Tue, Jun 2, 2015 at 8:33 AM, David Mozes wrote:
>>
>> Agree
>>
>>
>>
>> From: nvo3 [mailto:n
On Tue, Jun 2, 2015 at 6:57 PM, Dacheng Zhang
wrote:
> I think both ipsec and dtls would work.
>
> The middle network is not controlled by customer and the service
> provider, it’s provided by 3nd company, so the environment is not trusted,
> we need to encrypt the VxLAN packets or VxLAN payl
d this is also is the problem with the security
option proposal). So this would mean a new port number which
essentially implies a new protocol anyway.
Maybe it's possible to do this in VXLAN-GPE with some NSH header?
Tom
>
> Best Regards
> Liu Yuanjiao
>
> -邮件原
On Sat, Jun 20, 2015 at 1:04 PM, Dapeng Liu wrote:
> Hello all,
>
> We have submitted a draft for path detection in VXLAN overlay network.
> http://datatracker.ietf.org/doc/draft-pang-nvo3-vxlan-path-detection/
>
> The draft proposes a method for path detection in VXLAN network and it
> defines t
lem from the get-go.
In any case, this problem should at least be mentioned in the draft
and what steps need to be taken to avoid issues in practice.
Tom
>
> Thank,
> Yizhou
>
> -Original Message-
> From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Tom Herbert
> S
On Mon, Jun 29, 2015 at 6:48 AM, Deepak Kumar (dekumar)
wrote:
> Hi Dapeng Liu,
>
> I support idea of hardware and controller based Path detection and tracking
> where whole network is OAM capable and packet keeps forwarding in hardware.
> I believe you guys presented this solution in ONS summit a
"The Extendable TLV field contains two TLVs. Both of them are set by
the network devices along the transport path."-- this might be
problematic. From draft-ietf-tsvwg-port-use-11.txt: "Ultimately, port
numbers numbers indicate services only to the endpoints, and any
intermediate device that assign
't understand. You're assuming that *all* traffic generated by
hosts in a network is in VXLAN?
Tom
> --
> Dapeng Liu
>
> 在 2015年7月4日 星期六，上午8:06，Tom Herbert 写道：
>
> "The Extendable TLV field contains two TLVs. Both of them are set by
> the network devices along the t
Larry,
Have you thought about adding maybe VXLAN-GPE capable bit that an
endpoint could use to indicate it's capable of receiving VXLAN-GPE on
a VXLAN port?
Tom
On Wed, Sep 23, 2015 at 4:21 PM, Larry Kreeger (kreeger)
wrote:
> Hi Shahram,
>
> Yes, most VXLAN implementations allow the destinatio
> What we may want to say, then, is that if a P bit of 0 is used then none of
> the other flags must be set. This would prevent someone from generating a
> packet with a P bit of 0 and trying to use new GPE features.
>
> [Lucy] The P bit is used for version purpose too. The rule is if the GPE
> n
Hi Pankaj,
Do you think there is any value, intent, or issue for doing NVGRE/UDP
(via https://tools.ietf.org/html/draft-ietf-tsvwg-gre-in-udp-encap-07)
Tom
On Thu, Sep 24, 2015 at 1:43 PM, Pankaj Garg wrote:
> FYI, NVGRE is published as an information RFC 7637. Your documents that
> reference
port number? AFAIK there is no way
to distinguish NVGRE from other uses of GRE, a different UDP port
number could allow that.
Tom
> Lucy
>
> -Original Message-
> From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Manish Kumar (manishkr)
> Sent: Tuesday, October 06, 201
appendix
- Update email address
Posted to v6ops also.
Thanks,
Tom
-- Forwarded message --
From:
Date: Mon, Oct 12, 2015 at 10:06 AM
Subject: New Version Notification for draft-herbert-nvo3-ila-01.txt
To: Tom Herbert
A new version of I-D, draft-herbert-nvo3-ila-01.txt
has been
On Sun, Oct 18, 2015 at 6:17 PM, Naoki Matsuhira
wrote:
> This is new proposal for nvo3.
>
This looks like it is potentially a subset of ILA functionality.
Please look at https://www.ietf.org/id/draft-herbert-nvo3-ila-01.txt.
We could encode a VLAN and Ethernet address into an identifier with a
ne
te the VNID. This is why invented GUE which is more or
less just and extensible form of GRE.
Tom
> Thanks,
> Manish
>
> On 06/10/15 10:15 pm, "Tom Herbert" wrote:
>
>>On Tue, Oct 6, 2015 at 9:31 AM, Lucy yong wrote:
>>> Hi Manish,
>>>
>>> I
> A key limitation that prevents software from using extensions is NIC
> offloads. Both Geneve and VXLAN-GPE+NSH allows extension of these protocols
> without breaking NIC offloads.
Can you describe why you think this is? Both Geneve and VXLAN-GPE+NSH
are not usable with most implementations of
On Thu, Oct 29, 2015 at 12:41 PM, Pankaj Garg wrote:
> Inline.
>
>> -Original Message-----
>> From: Tom Herbert [mailto:t...@herbertland.com]
>> Sent: Thursday, October 29, 2015 12:25 PM
>> To: Pankaj Garg
>> Cc: Dino Farinacci ; Manish Kumar (manishk
On Thu, Oct 29, 2015 at 1:19 PM, Pankaj Garg wrote:
> Inline.
>
>> -Original Message-----
>> From: Tom Herbert [mailto:t...@herbertland.com]
>> Sent: Thursday, October 29, 2015 12:55 PM
>> To: Pankaj Garg
>> Cc: Dino Farinacci ; Manish Kumar (manishk
ucy
>>
>> -Original Message-
>> From: Pankaj Garg [mailto:pank...@microsoft.com]
>> Sent: Thursday, October 29, 2015 2:10 PM
>> To: Dino Farinacci; Manish Kumar (manishkr)
>> Cc: Tom Herbert; Lucy yong; nvo3@ietf.org
>> Subject: RE: [nvo3] RFC 7637 on NV
>> As for "safely extend using TLVs" have you actually verified that works with
>> HW, performance is unaffected, and this does not create new vectors of DOS
>> attacks? (Given the unmitigated disappointment with IP options I'm very
>> skeptical of and deployment of TLVs at L3 or below in the data
> [PG] I don't think GUE provides flexibility that is needed for future
> encapsulation. Network virtualization is mostly used with-in datacenters and
> in such environments, flexibility is needed to change and innovate rapidly.
> We need an encapsulation format that provides such flexibility an
On Fri, Oct 30, 2015 at 1:38 PM, Pankaj Garg wrote:
> Inline.
>
>> -Original Message-----
>> From: Tom Herbert [mailto:t...@herbertland.com]
>> Sent: Friday, October 30, 2015 11:57 AM
>> To: Pankaj Garg
>> Cc: Dino Farinacci ; Manish Kumar (manishk
> [PG] Yes, which is what TLVs in NSH/Geneve do but these are part of the
> format and not something we have to define on the side. Two independent
> entities can attach their metadata on the same packet without conflicts etc.
> Eventually, one can take either of these encap protocols and twist/
> To follow up on Pankaj’s mention of ecosystem support, one comment about the
> viability of TLVs is that whether they are a useful extension mechanism is
> mostly based on the implementer’s perception. If they are seen as an add-on
> that is not really core functionality (as in IPv4 and IPv6), th
On Fri, Oct 30, 2015 at 6:42 PM, Anoop Ghanwani wrote:
>
>
> On Fri, Oct 30, 2015 at 6:40 PM, Tom Herbert wrote:
>>
>>
>>
>> Put the VNID into a TLV then you are guaranteed that people will implement
>> them!
>>
> And don't forget to m
On Sun, Nov 1, 2015 at 1:12 PM, Jesse Gross wrote:
> Sure, probably all of the hardware implementations have some limits on their
> ability to handle the full breadth of Geneve options. Geneve was
> intentionally designed to be very future proof and support limits beyond
> what I would realistical
On Wed, Nov 4, 2015 at 9:31 PM, Haoweiguo wrote:
> Hi Sam,
>
> The extra bit in VXLAN reserved field has no side effect on regular VXLAN
> forwarding process. The hardware requirements for intermediate nodes is also
> low, the intermediate nodes only need to grab the data packets with the OAM
> fl
On Mon, Nov 16, 2015 at 1:45 PM, Surendra Kumar (smkumar)
wrote:
>
> Agree. I was just implying that the cost equivalent of discriminating v6/v4
> via the IP.ver field may already be paid even today.
>
Yes, a stack must verify that the version number matches the protocol
number.The number of cond
On Thu, Jan 14, 2016 at 12:27 PM, wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Network Virtualization Overlays Working
> Group of the IETF.
>
> Title : Geneve: Generic Network Virtualization En
1 - 100 of 223 matches
Mail list logo
