Hi Tom, I agree your statement/concern on VXLAN. NVGRE (GRE) has version field, it does not have such backward compatibility issue when enhancing it.
Cheers, Lucy -----Original Message----- From: nvo3 [mailto:[email protected]] On Behalf Of Tom Herbert Sent: Tuesday, March 25, 2014 10:10 AM To: Fabio Maino Cc: [email protected] Subject: Re: [nvo3] draft-quinn-vxlan-gpe-00 backwards compatibility > Tom, > please note that the VXLAN-GPE draft says that a GPE device must not > send non-ethernet frames to a VXLAN device (Section 4.2), exactly to > avoid the problem you describe. > Unfortunately, that requirement conflicts with the robustness principle. In a full scale deployment, it might be potentially feasible with a whole bunch of control plane logic to enforce the rule between communicating end hosts, but that still wouldn't account for middleboxes somewhere in the path that have implemented VXLAN functionality. Note, this is not the only potential incompatibility issue with VXLAN. Every new flag defining a new field would create another instance of incompatibility. This is not just hypothetical, we have already demonstrated that adding a new field to GRE breaks hashing in switches. This problem also exists with nvgre. > Also note that the draft is focusing on deployments where VXLAN is > already in use, and GPE is introduced incrementally. Hence the use of > the same UDP port for VXLAN and GPE. > > I suspect that in the deployment you describe, one could disambiguate > GPE from VXLAN by using two different destination UDP ports. if you > still want to have backward compatibility the sending GPE device will > have to know the receiver's capability (VXLAN or GPE), and pick the > appropriate destination UDP port. > At that point it becomes a different protocol. I believe a generic and extensible encapsulation protocol needs three fundamental elements: 1) Type-version-- so that new (incompatible) formats can be safely defined 2) Protocol type-- type of encapsulated packets 3) Header length-- offset of next header can be determined independently of any other elements in the encapsulation. The semantics of these elements should be invariant (just like in IP). Protocol type always defines the type encapsulated packet, header length is always offset of it. If an alternate interpretation of the payload is needed which does not correspond to a protocol type (like an OAM message) this should be in a separate type. Please look http://tools.ietf.org/html/draft-herbert-gue-01 for reference. Thanks, Tom > Regards, > Fabio > > > >> >>> A. >>> _______________________________________________ >>> nvo3 mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
