> 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. 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
