On 7/28/14, 8:08 AM, 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."
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).
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
