Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
I'm assuming that routers and switches will be multipathing based on
the UDP port numbers, so I would expect different destination UDP
ports to take different equal cost paths.
Well if OAM is going
] On Behalf Of Dino Farinacci
Sent: Wednesday, July 30, 2014 9:13 PM
To: Larry Kreeger
Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list list;
nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
I'm assuming that routers
For encapsulation there is good news and bad news. When we're
encapsulating over UDP we can affect the path simply by twiddling the
source port a little, so having application reopen connection might
not be necessary response to bad path. Bad news is that it may be
infeasible to get the
Melman; LISP mailing list list;
nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
Importance: High
Hello Dino,
always interesting, different people interpret differently.
You seem to talk about controlling where the OAM data flows. I don't think
Farinacci [mailto:farina...@gmail.com]
Sent: Thursday, July 31, 2014 7:17 PM
To: Eric Gray
Cc: Larry Kreeger; Tom Herbert; David Melman; Marc Binderberger; LISP mailing
list list; nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
Importance: High
]
Sent: Thursday, July 31, 2014 7:17 PM
To: Eric Gray
Cc: Larry Kreeger; Tom Herbert; David Melman; Marc Binderberger; LISP mailing
list list; nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
Importance: High
Dino,
Would you re-phrase
[mailto:farina...@gmail.com]
Sent: Friday, August 01, 2014 2:26 PM
To: Eric Gray
Cc: LISP mailing list list (l...@ietf.org); nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
Importance: High
Yes Eric, you make a lot of good points. Therefore the promise of OAM
removed LISP list
On Jul 30, 2014, at 8:16 PM, Tom Herbert therb...@google.com wrote:
On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger)
kree...@cisco.com wrote:
Hi Tom,
First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 for
NSH (as specified in
On Thu, Jul 31, 2014 at 5:56 AM, Paul Quinn (paulq) pa...@cisco.com wrote:
removed LISP list
On Jul 30, 2014, at 8:16 PM, Tom Herbert therb...@google.com wrote:
On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger)
kree...@cisco.com wrote:
Hi Tom,
First, the VXLAN-GPE Next Protocol
Melman; Marc Binderberger; LISP mailing list list;
nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
I'm assuming that routers and switches will be multipathing based on
the UDP port numbers, so I would expect different destination UDP
ports
[mailto:nvo3-boun...@ietf.org] On Behalf Of Dino Farinacci
Sent: Wednesday, July 30, 2014 9:13 PM
To: Larry Kreeger
Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list list;
nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
I'm
Hi Dino,
On 7/29/14 1:08 AM, Dino Farinacci farina...@gmail.com wrote:
On Jul 28, 2014, at 9:52 PM, Marc Binderberger m...@sniff.de wrote:
Hello Dino,
thanks for this comment - that's an interesting point of view.
Hmm, how do the O (or RA in another draft) and the P bit fit into this
On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger)
kree...@cisco.com wrote:
Hi Tom,
First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 for
NSH (as specified in draft-quinn-vxlan-gpe-03). Then, directly following
the VXLAN-GPE header would be an NSH header. One would
I can see the O-bit being useful when you want to use port 4341 to help
ensure that OAM packets use the same path through the network as the user
data packets.
Well there is no reason they wouldn't go the same as the user packets if the
destination IP address was the same. Also, the OAM
And NSH is a service protocol and should run above the transport layer
so should have its own port and can address packets anywhere.
I think the intent of NSH is to be generic enough to work at different layers.
The recent addition of the Metadata Type field in the NSH header allows for
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
发件人: Dino Farinacci [farina...@gmail.com]
发送时间: 2014年7月28日 21:15
收件人: Haoweiguo
抄送: Tom Herbert; David Melman; nvo3@ietf.org; LISP mailing list list
主题: Re: 答复: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
On Jul 28, 2014, at 7:24 AM
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
Following this thread, I have a few comments:
1. To avoid confusion, drop the text about backward compatibility with VXLAN.
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
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
On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci farina...@gmail.com 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
I am going to let other people explain. I think my email was clear.
Dino
On Jul 27, 2014, at 8:28 PM, Tom Herbert therb...@google.com wrote:
On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci farina...@gmail.com wrote:
2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and
Farinacci
Cc: nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
If GPE is the VXLAN evolution, why it request a new UDP port? If GPE is
a new protocol, why it has to align with VXLAN format?
Lucy
-Original Message-
From: nvo3 [mailto:nvo3
-Ree)
C: (949)-378-7568
-Original Message-
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Lucy yong
Sent: Wednesday, July 16, 2014 4:00 PM
To: Fabio Maino; Dino Farinacci
Cc: nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
If GPE
Of Lucy yong
Sent: Wednesday, July 16, 2014 4:00 PM
To: Fabio Maino; Dino Farinacci
Cc: nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
If GPE is the VXLAN evolution, why it request a new UDP port? If GPE is a
new protocol, why it has to align
: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
If GPE is the VXLAN evolution, why it request a new UDP port? If GPE
is a
new protocol, why it has to align with VXLAN format?
Lucy
-Original Message-
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Fabio
Hello Tom,
I also noticed the ambiguity if the P and O bit are simultaneously
set. This ambiguity arises from the fact that the O bit is more a
1-bit type field than a flag.
well, you may have a different OAM behaviour per protocol. It's hard to say
as the details of OAM are out of scope for
Well, if you want to really care about customers, creating all these variations
is not doing justice to them. If you want less combinations, you keep VXLAN the
way it is right now, with no changes. You keep LISP the way it is right now
with no changes. You get L2 and L3 overlays with a unified
on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
Well, if you want to really care about customers, creating all these variations
is not doing justice to them. If you want less combinations, you keep VXLAN the
way it is right now, with no changes. You keep LISP the way it is right now
Dino,
GPE is not changing VXLAN nor LISP, as today's implementations cannot be
changed. GPE is proposing a converged extension of both protocols that
add some new features that, I believe, are needed.
All of VXLAN features are supported in GPE.
In the case of LISP, unfortunately, two
) header the same.
Fabio
Linda
-Original Message-
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Dino Farinacci
Sent: Wednesday, July 16, 2014 3:05 PM
To: Fabio Maino
Cc: nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
Well
Farinacci
Cc: nvo3@ietf.org
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
Dino,
GPE is not changing VXLAN nor LISP, as today's implementations cannot be
changed. GPE is proposing a converged extension of both protocols that add
some new features that, I
This is where we disagree Dino: we keep seeing proposals to extend the
capability of network virtualization protocols. Security, as an example,
is one area where even you are proposing extensions. I hope this can
become an opportunity to add to the capabilities of the existing
protocols while
On Jul 16, 2014, at 6:16 PM, Fabio Maino fma...@cisco.com wrote:
But since we're respinning HW and SW to add one feature, in 2 different
implementations, why don't we use this chance to converge to a single encap
that can be extended to do that (and more)?
Because users have older
On 7/16/14, 6:27 PM, Dino Farinacci wrote:
On Jul 16, 2014, at 6:16 PM, Fabio Maino fma...@cisco.com wrote:
But since we're respinning HW and SW to add one feature, in 2 different
implementations, why don't we use this chance to converge to a single encap
that can be extended to do that
Hello Tom, Paul et al.,
Abstract: technically this is not extending a VXLAN but defines a new
protocol that looks similar to VXLAN (demonstrated by need for new UDP
port assignment).
(?) ... (!) interesting, the abstract was not mentioning it although it's a
relevant change IMHO when you
Hi Tom,
Thanks for the questions and comments! Please see inline.
On Jul 14, 2014, at 3:43 PM, Tom Herbert therb...@google.com wrote:
Hi VXLAN-gpe authors,
Abstract: technically this is not extending a VXLAN but defines a new
protocol that looks similar to VXLAN (demonstrated by need for
Hi VXLAN-gpe authors,
Abstract: technically this is not extending a VXLAN but defines a new
protocol that looks similar to VXLAN (demonstrated by need for new UDP
port assignment).
We are trying to balance re-use of the VXLAN format and the need to support
existing non-GPE hardware
On Tue, Jul 15, 2014 at 4:32 PM, Paul Quinn (paulq) pa...@cisco.com wrote:
Hi Tom,
Thanks for the questions and comments! Please see inline.
On Jul 14, 2014, at 3:43 PM, Tom Herbert therb...@google.com wrote:
Hi VXLAN-gpe authors,
Abstract: technically this is not extending a VXLAN but
Tom,
one of the design goals of GPE is to be cost effective when implemented
together with VXLAN and LISP. We do know that those are the two most
deployed protocols out there, and will be out there for quite some time
while any other network virtualization protocol gets deployed. I
believe
Dino,
I believe that using a format that can share as much as possible with
the two protocols deployed today will give a better chance to GPE to be
implemented, as vendors may want a cost effective way to migrate to the
new protocol while preserving compatibility with legacy implementations.
47 matches
Mail list logo
