Hello Tom, my point is your "limits the usefulness". There is some negative vibe and I do not agree with that :-)
As mentioned, I agree with the statement that ignore-on-receive flags mean you can add new functionality on top of existing ones but not fundamentally change things. From practical experience with LISP control plane - which has ignore-on-receive reserved fields - this works quite well as it allows to add-on features without breaking the fundamental interop with older implementations; you have to do it "right" to ensure a system not understanding the new feature behaves safe or at least reasonable but it's do-able. Thus my reference to LISP, sorry this was probably confusing. For your LISP-gpe comment Fabio answered already how it could work. Generally speaking about flags, having both, ignore-when-unknown flags and drop-when-unknown flags would be nice IMHO. Problem is our limited space of 64bit shim header though. Regards, Marc On Mon, 28 Jul 2014 08:08:31 -0700, Tom Herbert wrote: >>> 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
