On 11 aug 2009, at 16:09, Sam Hartman wrote:
We have not reached a consensus that LISP needs to work through NATs.
I'll take your message as a statement in favor of that and a personal
opinion that they need to.
Please put me down in the "that's insane" column.
On Aug 13, 2009, at 16:56 , Francis Dupont wrote:
In your previous mail you wrote:
If you want LISP on a desktop OS you need to update that OS, hence
at
the same time you can patch it to handle the 0 UDP checksum
consequently.
=> I disagree, it is easy to implement LISP in user mode
In your previous mail you wrote:
If you want LISP on a desktop OS you need to update that OS, hence at
the same time you can patch it to handle the 0 UDP checksum
consequently.
=> I disagree, it is easy to implement LISP in user mode (using
the tun/tap interface/device driver for in
In your previous mail you wrote:
This is an interesting idea, and I think it is worth exploring.
=> this is a typical IPv6 idea (:-)...
However, there are a couple of issues to overcome...
Would you perform DAD on these addresses before you use them? Or
would you somehow d
In your previous mail you wrote:
I am still colelcting implementation data, so I may be misled by what I
have gotten. But it seems to me that we are unfortunately stuck with
UDP with 0 checksums if we want high capacity tunnels to be able to make
use of ECMP / LAG in the moderate
> "Noel" == Noel Chiappa writes:
>> From: Francis Dupont the O UDP
>> checksum proposal obsoletes all the today deployed nodes which
>> check them (so all hosts I know and perhaps a lot of routers
>> too)
Noel> OK, so what are the other options for encapsulating a packet
On Aug 11, 2009, at 14:23 , Margaret Wasserman wrote:
On Aug 11, 2009, at 3:58 AM, Luigi Iannone wrote:
If you want LISP on a desktop OS you need to update that OS, hence
at the same time you can patch it to handle the 0 UDP checksum
consequently. I do not see any real issue here.
So,
Hi Steinar,
On Aug 11, 2009, at 4:11 AM, sth...@nethelp.no wrote:
The dataset analyzed is not relevant to today's networking
connectivity or technologies. Looking very quickly at a small set
of
data I have access to (servers serving web content to the internet
users):
32,945,810,591 packet
On Aug 11, 2009, at 3:58 AM, Luigi Iannone wrote:
If you want LISP on a desktop OS you need to update that OS, hence
at the same time you can patch it to handle the 0 UDP checksum
consequently. I do not see any real issue here.
So, if I want LISP on a non-open-source desktop, you think I
> >> The dataset analyzed is not relevant to today's networking
> >> connectivity or technologies. Looking very quickly at a small set of
> >> data I have access to (servers serving web content to the internet
> >> users):
> >>
> >> 32,945,810,591 packets received, 0 dropped due to bad checksum (ip
On Aug 11, 2009, at 4:41 , Margaret Wasserman wrote:
On Aug 7, 2009, at 11:24 AM, Francis Dupont wrote:
=> in fact the IPv6 addresses don't need to be the same when xTRs are
attached to regular links with /64 prefixes. So IMHO most of this
discussion is insane:
- if we need to vary things bet
Hi Havard,
On Aug 7, 2009, at 8:22 PM, Havard Eidnes wrote:
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers
too)
OK, so what are the other options for encapsulating a packet in a
IPv6
packet?
Um, sur
Does UDP-Lite work through NAT
boxes? (LISP has a mobile-node mode, which we would like to see
work through
NAT boxes, so any proposed alternative solution has to work through
NAT boxes
too.)
For IPv6?
Sorry I didn't reply to this in the earlier message...
(1) There isn't enough NAT de
The dataset analyzed is not relevant to today's networking
connectivity or technologies. Looking very quickly at a small set of
data I have access to (servers serving web content to the internet
users):
32,945,810,591 packets received, 0 dropped due to bad checksum (ip
header checksum)
1,004,72
Hi Noel,
On Aug 7, 2009, at 3:31 PM, Noel Chiappa wrote:
From: Francis Dupont
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers
too)
OK, so what are the other options for encapsulating a packet in a IPv6
p
On Aug 7, 2009, at 11:24 AM, Francis Dupont wrote:
=> in fact the IPv6 addresses don't need to be the same when xTRs are
attached to regular links with /64 prefixes. So IMHO most of this
discussion is insane:
- if we need to vary things between a pair of IPv6 xTRs it should
be enough (and simpl
On Mon, Aug 10, 2009 at 2:20 PM, Ross Callon wrote:
> There isn't all that much IPv6 traffic right now (some please correct me if
> this is wrong), and the ramp-up speed seems relatively
'much global ipv6 traffic'. There are places with more ipv6 traffic,
where LAG/ECMP is important. These 'inte
idual contributor with my own personal opinion only).
-Original Message-
From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On Behalf Of Joel M.
Halpern
Sent: 10 August 2009 13:11
To: Havard Eidnes
Cc: ipv6@ietf.org; l...@ietf.org
Subject: Re: [lisp] Flow label redux
Actually, looki
Actually, looking at this as a LISP problem is probalby misleading.
This issue applies to any intermediate device based, high capacity,
tunnel mechanism.
1) High capacity tunnel mechanisms are going to be concerned to
implement in hardware, where the UDP checksum may be difficult
2) High capaci
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers
too)
OK, so what are the other options for encapsulating a packet in a
IPv6
packet?
Um, surely, routers are not specified to validate layer-4
checksums for
In your previous mail you wrote:
> the O UDP checksum proposal obsoletes all the today deployed nodes
> which check them (so all hosts I know and perhaps a lot of
> routers too)
OK, so what are the other options for encapsulating a packet in a IPv6
packet?
=> UD
On Sun, Aug 9, 2009 at 6:14 PM, Francis Dupont wrote:
> In your previous mail you wrote:
> PS: IMHO this is an example of IPv6 misunderstanding: the solution
> was developed for IPv4 and as it doesn't fit exactly into IPv6
> in place of adjusting the solution you propose to adjust IPv6.
ugh... T
In your previous mail you wrote:
> - if we need to vary things between a pair of IPv6 xTRs it should
> be enough (and simple/easy) to vary the addresses
The above was considered at the initial design stages of LISP, (I
think Dino may have considered this approach?); however, it
On Fri, Aug 07, 2009 at 04:06:16PM -0400, Christopher Morrow wrote:
> > 4,166,900,871 packets 0 dropped due to bad checksum
>
> neat! (I'm also going to see if I can get some stats from a wider set
> of hosts, but)
If routers check the IPv4 header checksum (which I think they are
supposed to
And what about multicast? ;-)
Dino
On Aug 8, 2009, at 7:39 AM, Noel Chiappa wrote:
From: Christopher Morrow
The original version of this discussion started on ipv6@, and was
about
what to do if/when a 4to6 (say a nat64 device) translator gets a
packet
that would match the criteria
> From: Christopher Morrow
> The original version of this discussion started on ipv6@, and was about
> what to do if/when a 4to6 (say a nat64 device) translator gets a packet
> that would match the criteria in question.
Now that it's morning, and my brain is actually functioning,
Christopher Morrow wrote:
On Fri, Aug 7, 2009 at 8:22 PM, Havard Eidnes wrote:
> the O UDP checksum proposal obsoletes all the today deployed nodes
> which check them (so all hosts I know and perhaps a lot of routers too)
OK, so what are the other options for encapsulating a packet in a
Noel Chiappa wrote:
> From: Francis Dupont
> the O UDP checksum proposal obsoletes all the today deployed nodes
> which check them (so all hosts I know and perhaps a lot of routers too)
OK, so what are the other options for encapsulating a packet in a IPv6
packet?
I'm told by some
On Fri, Aug 7, 2009 at 11:13 PM, Noel Chiappa wrote:
> > From: Christopher Morrow
>
> > While a non-lisp node receiving a LISP udp/0 packet dropping it seems
> > fine to me, a translator dropping a udp/0|null-sum packet instead of
> > translating it properly or telling the source-syste
> From: Christopher Morrow
> While a non-lisp node receiving a LISP udp/0 packet dropping it seems
> fine to me, a translator dropping a udp/0|null-sum packet instead of
> translating it properly or telling the source-system: "oops, something
> bad happened" is unacceptable (i
On Fri, Aug 7, 2009 at 8:22 PM, Havard Eidnes wrote:
>> > the O UDP checksum proposal obsoletes all the today deployed nodes
>> > which check them (so all hosts I know and perhaps a lot of routers too)
>>
>> OK, so what are the other options for encapsulating a packet in a IPv6
>> packet?
>
> > the O UDP checksum proposal obsoletes all the today deployed nodes
> > which check them (so all hosts I know and perhaps a lot of routers too)
>
> OK, so what are the other options for encapsulating a packet in a IPv6
> packet?
Um, surely, routers are not specified to validate layer-4
CCing the IAB because I think we are reaching a slippery architectural
slope. Hopefully they can help us out.
On 7 aug 2009, at 20:43, Shane Amante wrote:
Therefore, I'll have to revise my original recommendation in the
first bullet above that we only consider UDP with 0 checksums as
the p
On Fri, Aug 7, 2009 at 3:42 PM, Marshall Eubanks wrote:
>
> On Aug 7, 2009, at 2:59 PM, Christopher Morrow wrote:
>
>> On Wed, Aug 5, 2009 at 5:07 PM, Margaret Wasserman
>> wrote:
>>>
>>> On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote:
>
This I don't recall at all... I think par
On 7 aug 2009, at 21:31, Noel Chiappa wrote:
I'm told by some people that UDP-Lite isn't a standard yet? Or is
it? (It
seems to have a protocol number issued?)
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
Protocol 136, RFC 3828.
Does UDP-Lite work through NAT
bo
On Aug 7, 2009, at 2:59 PM, Christopher Morrow wrote:
On Wed, Aug 5, 2009 at 5:07 PM, Margaret
Wasserman wrote:
On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote:
This I don't recall at all... I think part of my question is we
(as a
group) are assuming that the reasons for requiring
> From: Francis Dupont
> the O UDP checksum proposal obsoletes all the today deployed nodes
> which check them (so all hosts I know and perhaps a lot of routers too)
OK, so what are the other options for encapsulating a packet in a IPv6
packet?
I'm told by some people that UDP-Lite
On Wed, Aug 5, 2009 at 5:07 PM, Margaret Wasserman wrote:
>
> On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote:
>>>
>>
>> This I don't recall at all... I think part of my question is we (as a
>> group) are assuming that the reasons for requiring ipv6 udp checksums
>> as stated +10 years ago are
On Aug 7, 2009, at 12:21 MDT, Iljitsch van Beijnum wrote:
Shane, thanks for infusing this discussion with some data.
On 7 aug 2009, at 20:05, Shane Amante wrote:
Therefore, I'll have to revise my original recommendation in the
first bullet above that we only consider UDP with 0 checksums as
Shane, thanks for infusing this discussion with some data.
On 7 aug 2009, at 20:05, Shane Amante wrote:
Therefore, I'll have to revise my original recommendation in the
first bullet above that we only consider UDP with 0 checksums as the
preferred short-term solution when IPv6 is being used
Hi Margaret,
Apologies for the delay, but it took some time to follow-up with some
vendors. See below.
On Aug 5, 2009, at 12:33 MDT, Margaret Wasserman wrote:
Hi Shane,
On Aug 5, 2009, at 12:50 PM, Shane Amante wrote:
To bring this back up a level, while it's /possible/ to encourage
ve
Francis,
On Aug 7, 2009, at 09:24 MDT, Francis Dupont wrote:
In your previous mail you wrote:
And I understand that current load balancers can only do this based
on a few fields:
src/dest IP addresses (two RLOCs), the IP traffic class, the IP
protocol field (UDP=17) and the src/dest UDP
In your previous mail you wrote:
And I understand that current load balancers can only do this based
on a few fields:
src/dest IP addresses (two RLOCs), the IP traffic class, the IP
protocol field (UDP=17) and the src/dest UDP ports ( and LISP=4341).
I just don't see how
On Fri, Aug 7, 2009 at 5:52 AM, Iljitsch van Beijnum wrote:
> On 5 aug 2009, at 19:34, Christopher Morrow wrote:
>
>> You may see 2-3 year cycle on new asics for this feature to appear...
>> given 1-2 years for haggling/bugs/blah it's safe to say 3-5 yrs before
>> hardware is on the shelf to purcha
On 5 aug 2009, at 19:34, Christopher Morrow wrote:
You may see 2-3 year cycle on new asics for this feature to appear...
given 1-2 years for haggling/bugs/blah it's safe to say 3-5 yrs before
hardware is on the shelf to purchase.
You assume this requires new hardware. Although that's not
inc
On 5 aug 2009, at 16:16, Margaret Wasserman wrote:
What I am asking is whether IPv6 routers containing that silicon
exist in real-world deployments in large enough numbers that they
should be considered in our design choices.
The real question is how many of these routers use parallel links
On 6 aug 2009, at 19:00, Noel Chiappa wrote:
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 independent decision on the
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]
>
>
> From: Havard Eidnes
> 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 making that
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 availab
> > From: Brian E Carpenter
>
> > 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 independent decision
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]
>
>
&
> From: Margaret Wasserman
> 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 errors in the
> From: Brian E Carpenter
> 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 independent decision on the next h
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
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
unpredicta
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 usin
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. Clea
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 d
On Aug 5, 2009, at 3:55 PM, Christopher Morrow wrote:
This I don't recall at all... I think part of my question is we (as a
group) are assuming that the reasons for requiring ipv6 udp checksums
as stated +10 years ago are still valid, I don't see data supporting
that fact.
There are some cl
On Wed, Aug 5, 2009 at 3:32 PM, Margaret Wasserman wrote:
>
> On Aug 5, 2009, at 2:54 PM, Christopher Morrow wrote:
>>
>> What was the original reason for removing the ability to do zero
>> checksums on udp in v6? Are we sure that that decision is still
>> sensible/appropriate in today's internet/w
On Aug 5, 2009, at 2:54 PM, Christopher Morrow wrote:
What was the original reason for removing the ability to do zero
checksums on udp in v6? Are we sure that that decision is still
sensible/appropriate in today's internet/world?
I have not been around long enough to have been there when tha
The basic model is that ECMP works by hashing all the fields.
Therefore, you need two related properties:
1) You need those fields to be stable across all the packets in a flow
in one direction. (There is absolutely no need for the answer to be the
same in the reverse direction, as there is no
Hi Joel,
On Aug 5, 2009, at 1:42 PM, Joel M. Halpern wrote:
Reading this discussion, there seem to be a small number of
practical choices.
If the vendor hardware that is / will be handling IPv6 can handle
the flow label as part of the ECMP / LAG calcualtion, than an I-D /
direction to u
On Wed, Aug 5, 2009 at 2:33 PM, Margaret Wasserman wrote:
>
> Hi Shane,
>
> On Aug 5, 2009, at 12:50 PM, Shane Amante wrote:
>>
>> To bring this back up a level, while it's /possible/ to encourage vendors
>> to adopt the IPv6 flow-label as input-keys to their hash-calculations for
>> LAG/ECMP, it t
Hi Shane,
On Aug 5, 2009, at 12:50 PM, Shane Amante wrote:
To bring this back up a level, while it's /possible/ to encourage
vendors to adopt the IPv6 flow-label as input-keys to their hash-
calculations for LAG/ECMP, it takes [a lot] of time to see that
materialize in the field. Practic
On Wed, Aug 5, 2009 at 1:43 PM, Sam Hartman wrote:
>> "Shane" == Shane Amante writes:
> Shane> With respect to #2, SP's have been mandating that they only
> Shane> buy v6- capable HW for the last /several years/ as part of
> Shane> the normal growth/ replacement cycle of network equip
Reading this discussion, there seem to be a small number of practical
choices.
If the vendor hardware that is / will be handling IPv6 can handle the
flow label as part of the ECMP / LAG calcualtion, than an I-D /
direction to use the flow label seems sensible. (This is about what
will be use
> "Shane" == Shane Amante writes:
Shane> With respect to #2, SP's have been mandating that they only
Shane> buy v6- capable HW for the last /several years/ as part of
Shane> the normal growth/ replacement cycle of network equipment.
Shane> So, yes, this equipment should scale t
On Wed, Aug 5, 2009 at 12:50 PM, Shane Amante wrote:
> Sam,
>
> On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote:
>>>
>>> "Shane" == Shane Amante writes:
>>
>> Shane> Take a look at the following URL:
>> Shane> http://www.sixxs.net/faq/connectivity/?faq=ipv6transit
>> Shane> (Note, I
Sam,
On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote:
"Shane" == Shane Amante writes:
Shane> Take a look at the following URL:
Shane> http://www.sixxs.net/faq/connectivity/?faq=ipv6transit
Shane> (Note, I can't vouch for the accuracy of the entire list,
Shane> but it's about the b
> "Shane" == Shane Amante writes:
Shane> Take a look at the following URL:
Shane> http://www.sixxs.net/faq/connectivity/?faq=ipv6transit
Shane> (Note, I can't vouch for the accuracy of the entire list,
Shane> but it's about the best publicly available list I've seen).
Sha
Margaret,
On Aug 5, 2009, at 08:12 MDT, Margaret Wasserman wrote:
Hi Joel,
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem is not what the ITRs and ETRs use the field for. They
could / can use the field.
The problem is that the UDP header was introduced specifically so
tha
On Wed, 5 Aug 2009, Margaret Wasserman wrote:
Do you really believe that enough IPv6 routers have shipped with
this sort of ECMP behavior in _hardware_ that we need to consider
that legacy deployment? I'm somewhat skeptical that this could be
the case... If we're going to make design compromis
Hi Joel,
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem is not what the ITRs and ETRs use the field for. They
could / can use the field.
The problem is that the UDP header was introduced specifically so
that different flows would be different in a place that the routers
Hi Joel,
On Aug 4, 2009, at 10:51 PM, Joel M. Halpern wrote:
The problem is not what the ITRs and ETRs use the field for. They
could / can use the field.
The problem is that the UDP header was introduced specifically so
that different flows would be different in a place that the routers
On 5 aug 2009, at 1:26, Vince Fuller wrote:
Specifying some alternate reality and hoping that the operational
world will
modify its behavior to match
Isn't that the business the IETF is in?
doesn't seem very practical, particularly since
one of LISP's virtues is that it requires no changes
> That said, I can't see any reason why ITRs and ETRs can't use
> the flow label among themselves, in a way completely compatible
> with RFC3697. But if their hardware engines can't include the
> flow label in the n-tuple, that's a problem.
The issue isn't whether the "hardware engines can't inclu
On 2009-08-05 11:26, Vince Fuller wrote:
>> That said, I can't see any reason why ITRs and ETRs can't use
>> the flow label among themselves, in a way completely compatible
>> with RFC3697. But if their hardware engines can't include the
>> flow label in the n-tuple, that's a problem.
>
> The issu
79 matches
Mail list logo
