Re: [nvo3] Questions to your draft-herbert-nvo3-ila-02

On Fri, Apr 15, 2016 at 3:15 PM, Linda Dunbar wrote: > Tom, > > > > Your draft 3.1 suggests that the “locator” is encoded in the address. Does > it mean if the application is moved to a different “container”, the > application will have a different address (as the locator

[nvo3] Fwd: New Version Notification for draft-herbert-vxlan-rco-01.txt

43 AM Subject: New Version Notification for draft-herbert-vxlan-rco-01.txt To: Tom Herbert <t...@herbertland.com> A new version of I-D, draft-herbert-vxlan-rco-01.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-vx

Re: [nvo3] I-D Action: draft-ietf-nvo3-geneve-01.txt

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:

Re: [nvo3] Requesting Next Protocol = 0 for Ethernet [ draft-ietf-nvo3-vxlan-gpe-01.txt ]

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

Re: [nvo3] draft-­-pang-­-nvo3-­-vxlan-­-path-­-detection-­-01

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

Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

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

Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

On Fri, Oct 30, 2015 at 1:38 PM, Pankaj Garg <pank...@microsoft.com> wrote: > Inline. > >> -Original Message- >> From: Tom Herbert [mailto:t...@herbertland.com] >> Sent: Friday, October 30, 2015 11:57 AM >> To: Pankaj Garg <pank...@microsoft.com>

Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

> [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

Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

> 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),

Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

> 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

Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

On Thu, Oct 29, 2015 at 1:19 PM, Pankaj Garg <pank...@microsoft.com> wrote: > Inline. > >> -Original Message- >> From: Tom Herbert [mailto:t...@herbertland.com] >> Sent: Thursday, October 29, 2015 12:55 PM >> To: Pankaj Garg <pank...@micro

Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

> >> >> Lucy >> >> -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 >> Subjec

Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

>> 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

Re: [nvo3] Fwd: New Version Notification for draft-matsuhira-me6e-pr-00.txt

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

[nvo3] Fwd: New Version Notification for draft-herbert-nvo3-ila-01.txt

to the appendix - Update email address Posted to v6ops also. Thanks, Tom -- Forwarded message -- From: <internet-dra...@ietf.org> Date: Mon, Oct 12, 2015 at 10:06 AM Subject: New Version Notification for draft-herbert-nvo3-ila-01.txt To: Tom Herbert <t...@herbertland.com> A

Re: [nvo3] RFC 7637 on NVGRE: Network Virtualization Using Generic Routing Encapsulation

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

Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

> 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 >

Re: [nvo3] 回复： Application of a time slot in this ietf meeting//Re: New draft: Path Detection in VXLAN Overlay Network

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 assigns

Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

On Mon, Jun 29, 2015 at 6:48 AM, Deepak Kumar (dekumar) deku...@cisco.com 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

Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

On Sat, Jun 20, 2015 at 1:04 PM, Dapeng Liu maxpass...@gmail.com 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

Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

. 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 Sent: Tuesday, June 23, 2015 10:21 PM To: Dapeng

Re: [nvo3] 答复: VxLAN Security Consideration

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 -邮件原件- 发件人: Tom Herbert [mailto:t

Re: [nvo3] VxLAN Security Consideration

On Tue, Jun 2, 2015 at 6:57 PM, Dacheng Zhang dacheng@alibaba-inc.com 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

Re: [nvo3] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip

On Tue, May 5, 2015 at 10:53 AM, Joe Touch to...@isi.edu 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 avoid

Re: [nvo3] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip

and the result looks exactly like IP in UDP. That seems impossible. Not impossible - Tom Herbert provided the solution: http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html That is allocating bits (or bit patterns) from the IP header. The solution provided - to check for 0x01

Re: [nvo3] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip

. That seems impossible. Not impossible - Tom Herbert provided the solution: http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html That is allocating bits (or bit patterns) from the IP header. The solution provided - to check for 0x01 - is incorrect. IP can have versions that include

Re: [nvo3] Encapsulation considerations

On Wed, Apr 15, 2015 at 5:42 PM, Erik Nordmark nordm...@acm.org wrote: On 4/9/15 10:56 AM, Tom Herbert wrote: On Thu, Apr 9, 2015 at 10:46 AM, Erik Nordmark nordm...@acm.org wrote: I thought the purpose of RFS was to send the packet (and associated interrupt) to the CPU where the application

Re: [nvo3] Encapsulation considerations

On Thu, Apr 9, 2015 at 10:46 AM, Erik Nordmark nordm...@acm.org 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

Re: [nvo3] Encapsulation considerations

On Tue, Apr 7, 2015 at 12:02 AM, Lizhong Jin lizho@gmail.com 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

Re: [nvo3] Fwd: New Version Notification for draft-herbert-gue-fragmentation-00.txt

On Wed, Apr 1, 2015 at 12:55 PM, Joe Touch to...@isi.edu 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 know what the link MTUs

[nvo3] Fwd: New Version Notification for draft-herbert-gue-encap-considerations-01.txt

-- From: internet-dra...@ietf.org Date: Thu, Mar 26, 2015 at 7:57 AM Subject: New Version Notification for draft-herbert-gue-encap-considerations-01.txt To: Tom Herbert t...@herbertland.com, Osama Zia osa...@microsoft.com A new version of I-D, draft-herbert-gue-encap-considerations-01.txt

[nvo3] Fwd: New Version Notification for draft-herbert-gue-fragmentation-00.txt

Herbert t...@herbertland.com, Fred L. Templin fltemp...@acm.org A new version of I-D, draft-herbert-gue-fragmentation-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-gue-fragmentation Revision: 00 Title

Re: [nvo3] IPR poll for draft-herbert-gue-03

I am not aware of any relevant IPR for GUE. Thanks, Tom On Fri, Mar 20, 2015 at 1:55 PM, Bocci, Matthew (Matthew) matthew.bo...@alcatel-lucent.com 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,

[nvo3] Suggestion to apply encaps DT work to NVO3

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

[nvo3] Fwd: New Version Notification for draft-herbert-gue-03.txt

Date: Fri, Mar 6, 2015 at 2:11 PM Subject: New Version Notification for draft-herbert-gue-03.txt To: Tom Herbert t...@herbertland.com, Osama Zia osa...@microsoft.com A new version of I-D, draft-herbert-gue-03.txt has been successfully submitted by Tom Herbert and posted to the IETF repository

Re: [nvo3] [sfc] VxLAN-gpe vs nvo3

https://www.cs.purdue.edu/homes/kompella/publications/infocom13.pdf On Wed, Mar 4, 2015 at 2:55 PM, Larry Kreeger (kreeger) kree...@cisco.com 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

Re: [nvo3] is it resonsable that draft-dunbar-nvo3-nva-mapping-distribution-01 suggests NVE using bit-map to represent its supported VNs?

On Thu, Jan 29, 2015 at 1:53 PM, Linda Dunbar linda.dun...@huawei.com 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

Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM

implementation. Best regards, Mach -Original Message- From: Deepak Kumar (dekumar) [mailto:deku...@cisco.com] Sent: Friday, November 21, 2014 2:34 PM To: Mach Chen; Tom Herbert Cc: nvo3@ietf.org Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM Hi Mach

Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM

- From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Tom Herbert Sent: Monday, November 17, 2014 8:02 AM To: Marc Binderberger Cc: Greg Mirsky; Mach Chen; Deepak Kumar (dekumar); nvo3@ietf.org; Haoweiguo; Larry Kreeger (kreeger); Vero Zheng; Jon Hudson Subject: Re: [nvo3] 答复: Comments on NVO3

Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM

Message- From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Tom Herbert Sent: Friday, November 14, 2014 4:27 PM To: Mach Chen Cc: Greg Mirsky; Haoweiguo; Marc Binderberger; Larry Kreeger; nvo3@ietf.org Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM On Wed

[nvo3] Fwd: New Version Notification for draft-herbert-remotecsumoffload-01.txt

-- Forwarded message -- From: internet-dra...@ietf.org Date: Thu, Nov 13, 2014 at 12:19 AM Subject: New Version Notification for draft-herbert-remotecsumoffload-01.txt To: Tom Herbert therb...@google.com A new version of I-D, draft-herbert-remotecsumoffload-01.txt has been successfully

Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM

On Wed, Nov 12, 2014 at 5:13 PM, Mach Chen mach.c...@huawei.com 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@ietf.org; Larry Kreeger

Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM

On Wed, Nov 12, 2014 at 12:55 AM, Mach Chen mach.c...@huawei.com 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

Re: [nvo3] Comments on NVO3 data plane requirements for OAM

On Tue, Nov 11, 2014 at 12:33 PM, Larry Kreeger (kreeger) kree...@cisco.com 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

Re: [nvo3] Comments on NVO3 data plane requirements for OAM

from just a single mark on a packet? Regards, Greg On Tue, Nov 11, 2014 at 1:42 PM, Tom Herbert therb...@google.com wrote: On Tue, Nov 11, 2014 at 12:33 PM, Larry Kreeger (kreeger) kree...@cisco.com wrote: Hi Weiguo, What do you envision this marking looking like? e.g. is it just

Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM

On Tue, Nov 11, 2014 at 7:04 PM, Haoweiguo haowei...@huawei.com wrote: Hi Tom, Pls see inline with [weiguo]. Thanks weiguo 发件人: Tom Herbert [therb...@google.com] 发送时间: 2014年11月12日 8:22 收件人: Greg Mirsky 抄送: Larry Kreeger (kreeger); Haoweiguo; nvo3

Re: [nvo3] I-D Action: draft-ietf-nvo3-arch-02.txt

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 therb...@google.com wrote: On Thu, Oct 30, 2014 at 1:50 PM, Behcet Sarikaya sarikaya2...@gmail.com

Re: [nvo3] Concerns about NVO3 dataplane requirements document

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

Re: [nvo3] Security issue on L3 address migration ( was RE: L3 Address migration in NVO3 mobility draft (now with the new name : draft-merged-nvo3-ts-address-Migration)

On Wed, Oct 15, 2014 at 2:02 PM, Linda Dunbar linda.dun...@huawei.com 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 considered here also

Re: [nvo3] L3 Address migration in NVO3 mobility draft (now with the new name : draft-merged-nvo3-ts-address-Migration)

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 addresses

Re: [nvo3] Poll for a better name for draft-merged-nvo3-vm-mobility-scheme-00.txt

On Tue, Oct 7, 2014 at 7:33 PM, Sri Gundavelli (sgundave) sgund...@cisco.com 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

Re: [nvo3] Poll for a better name for draft-merged-nvo3-vm-mobility-scheme-00.txt

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, 2014 8:15 PM To: Tom Herbert Cc: nvo3@ietf.org Subject: Re

Re: [nvo3] Poll for a better name for draft-merged-nvo3-vm-mobility-scheme-00.txt

that this solution 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's a better title, I think my comment

Re: [nvo3] Enhancing Virtual Network Encapsulation with IPv6

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 network?

[nvo3] Fwd: New Version Notification for draft-herbert-remotecsumoffload-00.txt

-- From: internet-dra...@ietf.org Date: Tue, Aug 26, 2014 at 1:39 PM Subject: New Version Notification for draft-herbert-remotecsumoffload-00.txt To: Tom Herbert therb...@google.com A new version of I-D, draft-herbert-remotecsumoffload-00.txt has been successfully submitted by Tom Herbert

Re: [nvo3] Taking NVGRE draft to Informational RFC

On Sun, Aug 3, 2014 at 10:16 PM, Pankaj Garg garg.pan...@microsoft.com 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

Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03

] On Behalf Of Dino Farinacci Sent: Wednesday, July 30, 2014 9:13 PM To: Larry Kreeger Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list list; nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 I'm assuming that routers

Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03

On Thu, Jul 31, 2014 at 5:56 AM, Paul Quinn (paulq) pa...@cisco.com wrote: removed LISP list On Jul 30, 2014, at 8:16 PM, Tom Herbert therb...@google.com wrote: On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger) kree...@cisco.com wrote: Hi Tom, First, the VXLAN-GPE Next Protocol

Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03

friendly? Thanks, Tom - Larry On 7/30/14 2:46 PM, Tom Herbert therb...@google.com wrote: I think the intent of NSH is to be generic enough to work at different layers. The recent addition of the Metadata Type field in the NSH header allows for it to be used for purposes beyond SFC

Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03

17:28:01 -0700, Tom Herbert wrote: On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci farina...@gmail.com 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

Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03

On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci farina...@gmail.com 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

Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03

On Tue, Jul 15, 2014 at 4:32 PM, Paul Quinn (paulq) pa...@cisco.com wrote: Hi Tom, Thanks for the questions and comments! Please see inline. On Jul 14, 2014, at 3:43 PM, Tom Herbert therb...@google.com wrote: Hi VXLAN-gpe authors, Abstract: technically this is not extending a VXLAN

Re: [nvo3] needed data plane encap requirement in draft-ietf-nvo3-dataplane-requirements

On Thu, Mar 20, 2014 at 7:20 PM, Pankaj Garg garg.pan...@microsoft.com 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?

Re: [nvo3] FW: New Version Notification for draft-zhou-li-vxlan-soe-00.txt

On Thu, Mar 13, 2014 at 7:25 PM, Zhou, Han hzh...@ebay.com 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

Re: [nvo3] comment on herbert-gue-01

On Tue, Mar 11, 2014 at 9:49 AM, Lucy yong lucy.y...@huawei.com 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 herbert-gue-01

Re: [nvo3] question and comment on gross-geneve draft

On Mon, Mar 10, 2014 at 11:48 AM, Lucy yong lucy.y...@huawei.com 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.”

Re: [nvo3] question and comment on gross-geneve draft

On Mon, Mar 10, 2014 at 1:29 PM, Lucy yong lucy.y...@huawei.com 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@ietf.org

Re: [nvo3] comment on herbert-gue-01

Hi Lucy, thanks for the comments! On Mon, Mar 10, 2014 at 2:51 PM, Lucy yong lucy.y...@huawei.com 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

Re: [nvo3] Fwd: New Version Notification for draft-herbert-gue-01.txt

On Thu, Mar 6, 2014 at 7:24 PM, Lizhong Jin lizho@gmail.com 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; mls.i...@gmail.com Subject: Re: [nvo3] Fwd

Re: [nvo3] Comments on Draft Geneve

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

Re: [nvo3] Draft Geneve

On Fri, Feb 28, 2014 at 3:24 PM, Sam Aldrin aldrin.i...@gmail.com 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

Re: [nvo3] Fwd: New Version Notification for draft-herbert-gue-00.txt

: Tom Herbert [mailto:therb...@google.com] Sent: 2014年2月12日 0:03 To: nvo3@ietf.org Subject: [nvo3] Fwd: New Version Notification for draft-herbert-gue-00.txt Hello, I didn't originally forward this to the nv03 draft, but it was suggested I do. This is a proposal for generic UDP

<    1   2