Tom,
one of the design goals of GPE is to be cost effective when implemented
together with VXLAN and LISP. We do know that those are the two most
deployed protocols out there, and will be out there for quite some time
while any other network virtualization protocol gets deployed. I
believe that sharing the parsing logic across the new and legacy
protocols, is a significant reduction in complexity that eventually will
help adoption of GPE.
At the same time we want to facilitate convergence to a protocol that
can be extended with new features. Multiprotocol support and explicit
service tagging being the two most notable.
GPE with the next protocol and version fields provides a trade off
between those two contrasting requirements.
When you consider the flexibility of GPE, you shoud look at the
combination of gpe with a shim header a-la nsh, that I believe provides
the flexibility needed to carry additional metadata. It's also my
understanding that gpe+nsh would satisfy the requirements for NIC
processing that you describe in the GUE draft.
Finally the P bit. It simply leaves open the opportunity to deploy GPE
on the same port of VXLAN (or LISP). I believe that in some deployments
this may become an advantage, that is worth the use of one bit
(especially considering that with the compact next protocol field we
make available further bits in the GPE header to future versions).
Thanks,
Fabio
On 7/15/14, 4:03 PM, Tom Herbert wrote:
On Tue, Jul 15, 2014 at 1:42 PM, Marc Binderberger <[email protected]> wrote:
Hello Tom, Paul et al.,
Abstract: technically this is not extending a VXLAN but defines a new
protocol that looks similar to VXLAN (demonstrated by need for new UDP
port assignment).
(?) ... (!) interesting, the abstract was not mentioning it although it's a
relevant change IMHO when you refer to "VxLAN".
Paul, few comments/questions:
(1) I think the abstract should mention the requirement for a new UDP port.
Especially as this suddenly showed up (it wasn't there in -02)
(2) maybe a motivation why a new UDP port is needed?
(3) propose to remove figure 3 and use figure 4 throughout the document as
the new proposed header
(4) does the whole P bit and "backward compatibility" makes sense? E.g. in
4.2 what you are doing is simply sending out a VxLAN packet according to
draft-mahalingam-dutt-dcops-vxlan. Not sure there is any gain explaining how
to set P, O and protocol field. And I don't see the point in 4.1, VxLAN will
send to it's own port, not the new one.
Right, once the protocol is using a different UDP port, there is no
need to maintain backwards compatibility so all the deficiencies of
VXLAN could be addressed in the "new" protocol (like the location of
the first used flag bit, or the shift/size of the VNID).
I also noticed the ambiguity if the P and O bit are simultaneously
set. This ambiguity arises from the fact that the O bit is more a
1-bit type field than a flag. I would suggest donating the the O bit
to the version field space to allow eight version/types. So val==0
indicates normal data packet (protocol field is present), val==1
indicates OAM packet. All the other fields (even flags) can be
interpreted based on the version/type.
(5) could you provide a short motivation why you extend your flags, version
field to the right side of the "I" flag when there is so much room on the
left? Sure, there is LISP - is there any problem mentioning this? Elephant
in the room? ;-)
It's seems pretty standard to put version first in the header since
the rest of the fields are interpreted based on that (e.g. IP).
(6) Maybe the authors of draft-quinn-vxlan-gpe had just the same idea,
independently but I have seen the OAM flag before:
draft-singh-nvo3-vxlan-router-alert. If you borrowed a good idea, why not
referencing?
Re Tom:
Without P-bit we can always do simple indirect look-up to get protocol
handler
(e.g. handler = proto_handlers[protocol])
agree. As this will go to a new UDP port one could define the packet with a
protocol field, always. No confusion. One precious flag saved in a fixed
header.
Also, since this now has a protocol and version in the header, the
only thing fundamentally missing is a header length field. Please
consider adding that. See GUE
(http://tools.ietf.org/html/draft-herbert-gue-01) or geneve for the
justification of why this is critical.
Well, ASIC/FPGA/NP people like fixed field headers, I think. I also see an
advantage to have an fixed 8 byte shim with similarities between VxLAN,
VxLAN-gpe and LISP (or LISP-gpe) from an implementation point of view. The
hardware just needs to add 64bit from pre-programmed memory, the details how
to fill the memory is done by the control plane. Parsing in hardware when
receiving a packet can also be easier (with the right layout) and be shared.
Yes, it seems that fixed headers have become an implicit requirement
in protocol design, however this conflicts with the requirement that
protocols that are extensible. I think the answer is to define
extensible protocols (use VLH) but assume implementations may
optimized only a fix set of combinations (conceptually how routers
optimize for zero length IP options, but allow packets with IP options
in slow path). In practice, an encapsulation protocol like VXLAN is
likely deployed in a closed network so that the encapsulation is
uniform (only a small number of variants in encapsulation would be
used). Introducing new fields would be a rare event, but we do need
this capability and an preferably it should not require a new protocol
(UDP port number) and definitely shouldn't require new HW. The ability
to program HW with a small number of combinations of the protocol to
parse would be awesome! :-)
Regards, Marc
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
