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. (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? ;-) (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. Regards, Marc _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
