> Tom, > with the LISP control plane (as with many other control planes) it's trivial > to encode the capability of the receiving end of a tunnel (ETR) in the > mapping itself. When the sender (ITR) encapsulates the packet it can then > "choose" the appropriate data path encoding. > > The P bit helps taking advantage of similarities between LISP-GPE and LISP, > and would allow an implementation to send LISP-GPE packets (P=1) containing > IPv4/v6 encapsulated packets to a legacy LISP router, on the UDP port 4341 > (LISP). The legacy LISP router, per LISP specification, will ignore the P > bit and the next protocol field (as long as N,E,V = 0). This allows to > transition LISP fabrics to LISP-GPE without the need for a new UDP port. > Given we have quite a large installed base of LISP devices, this is one of > the design goals of the LISP-GPE protocol. > > The same applies to VXLAN-GPE, when you use a control plane with the > characteristics above (e.g. LISP). Note that both LISP and VXLAN define > reserved bits as set to 0 in tx, ignore in rx. > > Since the GPE drafts are about data plane, the method for determining the > capabilities of the receiving end (GPE or "legacy") is out of the scope of > those drafts (will certainly be in scope of control plane drafts, though).
If negotiation is available then the precise set of flags can be negotiated, so if an unexpected or unknown flag is received it's obviously invalid and a reasonable recourse is to drop the packet. If negotiation is essential before communication (which so far seems to be true for network virtualization), the set of possible flags (or options) can be constrained a priori so that need to ignore unknown flags would be moot, by design an end host should never receive an unknown flag. By this same rationale, I tend to think the "Critical options" bit is unnecessary in geneve. IMO if a sender took the time to set a flag or an option it must have done that with the intent that the receiver (or someone in the network) will consume it. The caveat to this is that intermediate devices may also need to parse packets but not necessarily participate in the protocol control plane. Consider a stateless firewall that parses LISP packets to filter on encapsulated IP destination address. If the P-bit is implemented in the end hosts, but we've neglected to update all the firewalls in the path-- the packet will be misinterpreted if say the firewall sees a LISP packet with an encapsulated Ethernet frame. In this case, hopefully the firewall will drop the packet, but there's no guarantee of that-- the behavior is non-deterministic. Maintaining compatibility with such devices is a hard problem and might imply constraints on new options that could fundamental change parsing or interpretation of the packet (adding protocol type is a good example case). Thanks, Tom > Thanks, > Fabio > >> 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 >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
