Hi Pat,

Technology evolution does not stop because of many technologies existence. It 
continues because existing technologies let people see the better technologies.

The NVGRE/VXLAN overlay technology principle is about the separation of virtual 
networks from the physical transport network, i.e. virtual network traffic 
encapsulated in IP data grams and just likes another IP application. Using UDP 
src port for flow entropy is clear way to support underlying ECMP without 
breaking this principle and requests no change to underlying network (ECMP 
becomes the common underlying network capability). Yes, VXLAN encapsulation 
adopts this mechanism at first. IMO: current NVGRE encapsulation does not align 
with this principle well. It is a particular IP application (GRE), not like 
another IP application (TCP/UDP); it requests the underlying ECMP LB to use GRE 
header, which ties overlay network and underlying network together in some 
degree. This is why we propose gre-in-udp encapsulation to improve gre as of a 
generic encapsulation for an overlay technology. The semantics has the key 
components for an overlay technology.  NVGRE is designed for virtual network 
overlay and uses gre header. Thus, IMO, it is merit for NVGRE to use gre-in-udp 
format.

Although VXLAN is good to specify the use of UDP initially, but VXLAN header 
does not have protocol type field and only allow carrying Ethernet payload. It 
is designed for one purpose only as its name. So it can't apply to other 
overlay application without enhancement. NVGRE uses GRE header that has a 
protocol type field so it can easily extend for other overlay applications.  If 
you think that gre-in-udp for NVGRE or adding a protocol type field in VXLAN is 
new format and strongly against them. You soon will see a new encapsulation 
proposal to enable other overlay application such as service function chaining. 
 I don't see you have a way to get around that.

We should be able to specify one generic overlay encapsulation format that can 
support an overlay application.  The nvgre and vxlan enhancements we proposed 
makes them to be equally good to serve this purpose because both will contain 
the key components required for an overlay application and align with the 
overlay principle .  It would be great if IETF can standardize just one, but 
given existing deployment situation, this may not be practical. We leave the 
choice to the community.

Regards,
Lucy



From: Pat Thaler [mailto:[email protected]]
Sent: Wednesday, September 18, 2013 6:42 PM
To: Lucy yong; Pankaj Garg; 
[email protected]<mailto:[email protected]>
Cc: 
[email protected]<mailto:[email protected]>;
 [email protected]<mailto:[email protected]>
Subject: RE: comments on draft-sridharan-virtualization-nvgre-03

Dear Lucy,

I'm responding to your question to chip vendors about using NVGRE with your UDP 
encap draft.

It isn't that supporting any one packet format in hardware is a problem. The 
issue is the number of formats that need to be supported by a chip - each may 
be small but the number adds up. Adding another packet format variant isn't 
justified and would be burdensome for the chips.
[Lucy] My suggestion is not about adding a new format. It is to enhance 
existing NVGRE protocol.
>From the point of view of hardware handling of the frames, putting the UDP 
>header in between the IP and NVGRE headers makes it a new format for us.

The VXLAN packet format already provides for use cases where a flow field in 
the UDP header is desired. There is no need to duplicate that capability by 
adding an NVGRE in UDP format. We would be strongly against udp encapsulation 
of NVGRE.
[Lucy] This is not about duplicate that capability, it is about use of a common 
way in supporting underlying ECMP. Do you support both NVGRE and VXLAN 
encapsulation, or only VXLAN encapsulation?
There are Broadcom authors on both the VXLAN and NVGRE I-Ds. We support both 
formats going forward.

Regards,
Lucy

Regards,
Pat


[Lucy] If NIC hardware support VxLAN which use UDP port for the flow entropy, 
it should be easy to support gre-in-udp encaps as well. Will be great  to see 
chip vendor comment on this. Please take a look at the gre-in-udp encapsulation 
proposal (below), welcome comment on it.

Regards,
Lucy

Here is the draft. The TSVWG will adopt it as WG draft soon.

http://datatracker.ietf.org/doc/draft-yong-tsvwg-gre-in-udp-encap/

Regards,
Lucy

_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to