Hello Tom,
I'm all for precise wording - but one shouldn't get lost in the wording :-)
The intention of the compatibility described in the draft should be clear,
although the word is confusing: you can re-use your gpe send/receive logic
to send/receive the existing VxLAN encaps. All you need
The point Dino makes is (I think): is there really a gain to re-invent
VxLAN and LISP data encapsulation? And it might be actually easier to
implement and test separate encodings instead of the more complex combined
header in VxLAN-gpe.
Exactly.
Dino
About backward compatibility, i also agree with Dino. VXLAN-GPE should focus on
the VXLAN-GPE header and requires the assignment of a new UDP port, the data
format don't need consider backward compatibility with VXLAN header. If NVE1
support VXLAN-GPE, another NVE2 support VXLAN, the two NVE
On Jul 28, 2014, at 7:24 AM, Haoweiguo haowei...@huawei.com wrote:
About backward compatibility, i also agree with Dino. VXLAN-GPE should focus
on the VXLAN-GPE header and requires the assignment of a new UDP port, the
data format don't need consider backward compatibility with VXLAN
Hi Dino,
Sorry, i misunderstood you. I think VXLAN-GPE can define a new UDP port and a
new data format, P bit in VXLAN-GPE seems to have no any value. As for basic
inter-subnet layer 3 communication and intra-subnet layer 2 communication
between NVEs, current NVGRE, VXLAN and LISP have already
Hi Dino,
Sorry, i misunderstood you. I think VXLAN-GPE can define a new UDP port and a
new data format, P bit
No worries.
in VXLAN-GPE seems to have no any value. As for basic inter-subnet layer 3
communication and intra-subnet layer 2 communication between NVEs, current
NVGRE, VXLAN
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.
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
On Jul 28, 2014, at 11:09 AM, Fabio Maino fma...@cisco.com wrote:
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
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,
If the choices to extend an existing protocol are between adding P-bit
and assigning a UDP port per each protocol, I still think the P-bit
would be better since it is the more generic solution, but is going to
be more work to ensure backwards compatibility if flags can be ignored
on RX.
But
On Jul 28, 2014, at 1:12 PM, Tom Herbert therb...@google.com wrote:
If the choices to extend an existing protocol are between adding P-bit
and assigning a UDP port per each protocol, I still think the P-bit
would be better since it is the more generic solution, but is going to
be more work
12 matches
Mail list logo
