I am going to let other people explain. I think my email was clear. Dino
> On Jul 27, 2014, at 8:28 PM, Tom Herbert <[email protected]> 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
