On Tue, Jul 15, 2014 at 4:32 PM, Paul Quinn (paulq) <pa...@cisco.com> wrote: > Hi Tom, > > Thanks for the questions and comments! Please see inline. > > On Jul 14, 2014, at 3:43 PM, Tom Herbert <therb...@google.com> 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. > NSH looks an awful lot like an IP extension header to me, have you considered requesting a protocol number for this?
You can always use proto=47 (GRE) as an secondary encapsulation header to encapsulate the full ETHER_TYPE range. This technique is described in GUE draft (cost is 4 bytes and a little bit of processing for these other protocols not represented by an IP protocol number). > >> >> 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. > I think there's more logic in being consistent with Ethernet, IP, GRE protocol standards where the next protocol field is always valid as an invariant. > > >> >> 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? Fixed length gpe (or in VXLAN for that matter) implies no protocol eXtensibility :-). Thanks, Tom _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
