Hello Tom, I'm all for precise wording - but one shouldn't get lost in the wording :-)
The intention of the "compatibility" described in the draft should be clear, although the word is confusing: you can re-use your "gpe" send/receive logic to send/receive the existing VxLAN encaps. All you need is to send/receive on 4789/udp instead of the to-be-defined gpe port and set the flags/fields accordingly. The point Dino makes is (I think): is there really a gain to "re-invent" VxLAN and LISP data encapsulation? And it might be actually easier to implement and test separate encodings instead of the more complex combined header in VxLAN-gpe. The cost of not combining is a potential additional nth header for SFC and whatever else may come. > 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. I agree with your statement in the 2nd half but not your opinion about the usefulness. Don't see a problem here, LISP is a good example how ignoring unknown flags works well. Regards, Marc On Sun, 27 Jul 2014 17:28:01 -0700, Tom Herbert wrote: > On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
