Brian,
On Aug 5, 2009, at 22:19 MDT, Brian E Carpenter wrote:
On 2009-08-06 05:34, Christopher Morrow wrote:
...
2) Removing other gems (or clarifying them) like the second
sentence in
the following:
---cut here---
IPv6 nodes MUST NOT assume any mathematical or other properties of
the
Hi Joel,
I think I understand both sides of the UDP checksum issue now...
We (or at least some of us) believe that it is a hard requirement to
support ECMP through legacy routing equipment. This equipment will
only identify flows using the 5-tuple described in the draft. These
devices
I must be slow this morning.
I am not sure which of two possible (similar) problems this checksum is
supposed to help.
1) Due to in-network corruption, the LISP packet arrives at some
non-LISP entity which has something listening at whatever UDP port the
packet now ha as a destination.
On Aug 6, 2009, at 16:11 , Margaret Wasserman wrote:
Hi Joel,
I think I understand both sides of the UDP checksum issue now...
We (or at least some of us) believe that it is a hard requirement to
support ECMP through legacy routing equipment. This equipment will
only identify flows
I told myself I would stay out of this, but I can't help
but point out that if the SEAL-FS header were used instead
of the UDP/LISP headers there would only be 4 bytes exposed
to corruption instead of 16. And, if one of the SEAL-FS
header fields is corrupted there is no danger of causing
Hi Fred,
There are three things we are trying to address here:
- We want to support load balancing through legacy systems that only
support load balancing based on the 5-tuple of IP src/dest address,
protocol/next header and UDP or TCP src/dest ports. To meet this goal,
we need a UDP (or
From: Brian E Carpenter brian.e.carpen...@gmail.com
I see no particular issue with a network where some LAG-aware routers
do include the flow label in the hash and others don't.
Any time you have a network which is using hop-by-hop path selection (i.e.
each node makes an
From: Margaret Wasserman m...@sandstorm.net
In addition ... this checksum would protect the LISP header, which
contains some one- bit fields and a nonce that would be sensitive to
corruption.
This is an issue I had identified a while back, and looked then to see if
undetected
Margaret,
-Original Message-
From: Margaret Wasserman [mailto:m...@sandstorm.net]
Sent: Thursday, August 06, 2009 9:15 AM
To: Templin, Fred L
Cc: ipv6@ietf.org; l...@ietf.org
Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue]
Hi Fred,
There are three things
From: Brian E Carpenter brian.e.carpen...@gmail.com
I see no particular issue with a network where some LAG-aware routers
do include the flow label in the hash and others don't.
Any time you have a network which is using hop-by-hop path
selection (i.e. each node makes an
Hi Fred,
On Aug 6, 2009, at 1:42 PM, Templin, Fred L wrote:
How are non-TCP/UDP flows handled by these legacy systems
today? For example, 6to4 uses ip-proto-41.
My understanding is that these flows will not be handled well...
Since ECMP load balancers will have limited information
Shane,
On 2009-08-07 01:40, Shane Amante wrote:
Brian,
On Aug 5, 2009, at 22:19 MDT, Brian E Carpenter wrote:
On 2009-08-06 05:34, Christopher Morrow wrote:
...
2) Removing other gems (or clarifying them) like the second
sentence in
the following:
---cut here---
IPv6 nodes MUST NOT
From: Havard Eidnes h...@uninett.no
in this specific example which is talking about a Link Aggregation
Group (LAG).
I did indeed miss that detail. The conversation had been about a collection
of similar things, including ECMP, and I was thinking of that broader class
of things in
Margaret,
-Original Message-
From: Margaret Wasserman [mailto:m...@sandstorm.net]
Sent: Thursday, August 06, 2009 1:10 PM
To: Templin, Fred L
Cc: ipv6@ietf.org; l...@ietf.org
Subject: Re: [lisp] Flow label redux [Re: IPv6 UDP checksum issue]
Hi Fred,
On Aug 6, 2009, at 1:42
14 matches
Mail list logo
