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 include
On Wednesday 05 August 2009 00:09:13 ext Rémi Després wrote:
No harm expected? I find that generating scary-reading false
positive in my
system logs is harmful.
I don't get the point about scary-reading false positive.
As already mentioned (several times?), some operating systems log
Le 5 août 09 à 08:29, Rémi Denis-Courmont a écrit :
On Wednesday 05 August 2009 00:09:13 ext Rémi Després wrote:
No harm expected? I find that generating scary-reading false
positive in my
system logs is harmful.
I don't get the point about scary-reading false positive.
As already
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
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 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
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
Shane == Shane Amante sh...@castlepoint.net 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
Hi Margaret,
On Tue 8/4/09 8:53 PM, Margaret Wasserman m...@lilacglade.org wrote:
Hi Byzek,
On Jul 30, 2009, at 8:31 PM, byzek wrote:
It's not about performance; a large percentage of the currently-
deployed
hardware can¹t do UDP checksum calculations during encapsulation
because
Sam,
On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote:
Shane == Shane Amante sh...@castlepoint.net 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
Le 5 août 09 à 16:09, Iljitsch van Beijnum a écrit :
On 4 aug 2009, at 15:27, Rémi Després wrote:
That's pointless, because the IPv6 spec, against which
implementations have been heavily tested, reject such packets.
You seem to have missed that the proposal includes a relaxation of
the
On Wed, Aug 5, 2009 at 12:50 PM, Shane Amantesh...@castlepoint.net wrote:
Sam,
On Aug 5, 2009, at 09:01 MDT, Sam Hartman wrote:
Shane == Shane Amante sh...@castlepoint.net writes:
Shane Take a look at the following URL:
Shane http://www.sixxs.net/faq/connectivity/?faq=ipv6transit
Shane == Shane Amante sh...@castlepoint.net 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
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
On Wed, Aug 5, 2009 at 1:43 PM, Sam Hartmanhartmans-i...@mit.edu wrote:
Shane == Shane Amante sh...@castlepoint.net 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/
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.
On Wed, Aug 5, 2009 at 2:33 PM, Margaret Wassermanm...@sandstorm.net 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
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
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
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
On Wed, Aug 5, 2009 at 3:32 PM, Margaret Wassermanm...@sandstorm.net 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
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
On 5/08/09 8:24 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote:
Hi Joel,
On 2009-08-05 03:08, Joel M. Halpern wrote:
It has become clear with the passage of time that the description of the
flow label in the original IPv6 specs served only to convince everyone
not to use that
Hi,
One of my problems with existing address selection implementations is
that they pick just one source address per destination address. They
never try another source address even if a valid alternative source
address existed for a destination address. This has caused me some
headaches with
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 Flow
Label
values assigned by source nodes. Router performance
On Thu, 6 Aug 2009, Brian E Carpenter wrote:
'flow label bits alone make a poor material for a hash key'... isn't
this the reverse of saying that we'll (operators) require vendors to
use flow-label for hashing on ECMP/LAG? If so, then... I don't think
flow-label's going to cut it.
Please note
27 matches
Mail list logo
