>> 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. > How so? Adding protocol field to LISP-gpe has the same backwards compatibility problem as VXLAN-gpe, but is resolving it in a different way. The addition of the P-bit relies on some (presumably) out of band mechanism to ensure protocol compatibility. From the LISP-gpe draft:
"A LISP-gpe router MUST not encapsulate non-IP packets to a LISP router. A method for determining the capabilities of a LISP router (gpe or "legacy") is out of the scope of this draft." Thanks, Tom > > 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
