On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci <farina...@gmail.com> wrote: >> 2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and >> requires the assignment of a new UDP port. The fact that the VXLAN-GPE >> header closely resembles VXLAN may be convenient for implementers, but this >> protocol by definition is not backward compatible with VXLAN. > > If you do that then it will be harder for VXLAN-GPE systems to interoperate > with a VXLAN systems. Because a VXLAN-GPE system will need to open and > maintain 2 UDP sockets. And an implementaiton will have to be careful to not > set the P-bit for the VXLAN socket or clear the P-bit for VXLAN-GPE socket. > This is all completely unnecessary and one way or the other should be used. > I am not sure what you are suggesting. AFAICT there is no backwards compatible means to to add the protocol field to VXLAN which is the motivation for the new UDP port, which in turn implies a new protocol (which also implies an opportunity to add a more general set of protocol features like version number and options extensions which are also not backwards compatible). Maybe it's possible to break compatibility within the protocol and assume that out of band mechanisms could negotiate use of P-bit to compensate, but I assume there's already quite a bit of VXLAN deployment so that seems pretty shaky robustness-wise to me.
It's not just adding the protocol field that would be an issue, even adding the OAM bit to VXLAN would be problematic. Per VXLAN spec unspecified flag bits are ignored on receive, so if the OAM bit were subsequently defined in VXLAN it will be ignored by existing implementations and these packets will be processed normally-- this seems to be incompatible with the proposed VXLAN-gpe requirement that "When the O bit is set to 1, the packet is an OAM packet and OAM processing MUST occur." (btw 'OAM processing' is awfully ambiguous to be a MUST here IMO). Allowing the reserved bits in the header to be ignored on receive limits the usefulness in that new bits that are defined can only be advisory and not fundamentally change interpretation of the packet. Had the requirement in VXLAN been that packets with unknown bits set be dropped, then adding P-bit and O-bit could have been done with backwards compatibility. This might be a reasonable requirement to consider if new protocol (i.e. new port number) is undertaken. Thanks, Tom > And if *it was agreed* on to use different UDP port numbers (like the way > LISP did it for L2 versus L3 packet encapsulation), we wouldn't need the > P-bit at all. But there was push back (by somebody) to not allocate another > port for VXLAN, so the demux was forced to be in the VXLAN header. > > And is also the reason this baggage is being carried over the LISP when it > really isn't needed. > >> 3. True, the ‘P’ bit is not needed for backward compatibility, but I’m not >> against it if there is value to make it consistent with the LISP-GPE header. > > There is no incremental benefit to use the P-bit for LISP. We had a solution > but because of the requirement to have no new port for VXLAN, LISP is > affected. > > Just another example how the working group is putting effort into things that > creates more work but no benefit. Don't get me wrong, the cisco guys did this > (the VXLAN and LISP same position for P-bit) for consistency, and they should > be applauded for that. But if VXLAN could have another port number assigned > for "other protocols", maybe the VXLAN-GPE would look so much different. > > Something to think about as the working group now has new productivity > mentality. > > Dino > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
