Hello Tom, > 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.
well, you may have a different OAM behaviour per protocol. It's hard to say as the details of OAM are out of scope for the document, I guess. Even a simple "punt to control plane" is still punting to different receivers depending on layer-2, IPv4, IPv6 etc. > 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. well, that's where the version field comes into play. > The ability > to program HW with a small number of combinations of the protocol to > parse would be awesome! :-) Agree. Assuming it's really a small number :-) Regards, Marc On Tue, 15 Jul 2014 16:03:04 -0700, 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
