Hi Tom, Thanks for the questions and comments! Please see inline.
On Jul 14, 2014, at 3:43 PM, Tom Herbert <[email protected]> wrote: > Hi VXLAN-gpe authors, > > 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). We are trying to balance re-use of the VXLAN format and the need to support existing non-GPE hardware that might already be deployed. We looked at using the same port, and the new one, and decided, at this point that a new port is easier for migration but since the packet format is essentially VXLAN to keep the VXLAN name. > > Section 3.1: yet another protocol numbering scheme is defined. Why not > use IP protocol numbering space. e.g. 41 for IPv6, 94 for IPv4, 97 for > Ethernet. NSH would need an protocol number allocation (maybe that is > the intent so these can be used at L3? ). We can certainly use the IP protocol numbers for the protocols that have one. However, there are protocols that might be encapsulated that don’t have an IP protocol number (not just NSH) so we still need a registry for those. > > Section 3.1: P-bit seems unnecessary to me, is more complex to > process, and there is no reason to be compatible with VXLAN. Without > P-bit we can always do simple indirect look-up to get protocol handler > (e.g. handler = proto_handlers[protocol]), but with the P-bit we need > to do an additional conditional. The P bit ensures that we have forwarding logic consistent with LISP (https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/). Also, in the case if/when gpe uses the same port as VXLAN, the p-bit helps with parsing on the receiving end. > > 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. > The length of the gpe header is fixed, so adding length wouldn’t buy us much? _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
