: Brian E Carpenter brian.e.carpen...@gmail.com; Shane Amante
sh...@castlepoint.net; 6man ipv6@ietf.org
Sent: Thursday, May 06, 2010 1:15 AM
Subject: Re: DRAFT: Request for guidance about the flow label
On May 5, 2010, at 2:18 AM, Tina TSOU wrote:
[Tina: How about keeping the previous flow label
Hi,
Comments in line.
B. R.
Tina
http://tinatsou.weebly.com/contact.html
- Original Message -
From: Shane Amante
To: Rémi Després
Cc: 6man ; Brian E Carpenter
Sent: Friday, April 23, 2010 3:30 AM
Subject: Re: DRAFT: Request for guidance about the flow label
Remi,
I think we may
On May 5, 2010, at 2:18 AM, Tina TSOU wrote:
[Tina: How about keeping the previous flow label in the option of IPv6 Header
for restoral? When the exit router receives the packet, it uses the previous
option to replace the existing one to implement restoral.]
Yes, one could do that. It
On Thu, 22 Apr 2010 15:23:27 -0500
Manfredi, Albert E albert.e.manfr...@boeing.com wrote:
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Shane Amante
c) Declare the flow-label is _immutable_ and must be set by
all hosts and must
Le 22 avr. 2010 à 04:56, Brian E Carpenter a écrit :
I think we need to simplify the change proposed in
draft-carpenter-6man-flow-update-02 even more after the recent
discussions, while maintaining the proposed duality
(RFC 3697-like
use still possible, but locally-defined use also possible
Brian, Remi,
On Apr 22, 2010, at 06:50 MDT, Rémi Després wrote:
Le 22 avr. 2010 à 04:56, Brian E Carpenter a écrit :
I think we need to simplify the change proposed in
draft-carpenter-6man-flow-update-02 even more after the recent
discussions, while maintaining the proposed duality
(RFC
Le 22 avr. 2010 à 17:31, Shane Amante a écrit :
Brian, Remi,
On Apr 22, 2010, at 06:50 MDT, Rémi Després wrote:
Le 22 avr. 2010 à 04:56, Brian E Carpenter a écrit :
I think we need to simplify the change proposed in
draft-carpenter-6man-flow-update-02 even more after the recent
Remi,
I think we may be in agreement that domain-specific uses of the flow-label are
problematic for the reason you illustrate below? Namely, that once one domain
sets it to something that is not known to be a 3- or 5-tuple of the IPv6
header, then you lose the ability to use that flow-label
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Shane Amante
c) Declare the flow-label is _immutable_ and must be set by
all hosts and must only contain a 3- or 5-tuple hash of the
appropriate IPv6 headers. Further use cases for the
(Sorry, I messed up the subject of this thread by including DRAFT)
On 2010-04-23 07:30, Shane Amante wrote:
snip
I completely agree that this is a challenging problem;
however, I see a few ways of potentially dealing with it:
a)
Restoral of domain-specific flow-label values, (your
personally, I would prefer to see it *mutable*, and undefined. Given that there
are many host implementations out there, I could imagine difficulties getting
any specific specification (such as a hash) widely deployed in a finite amount
of time. However, if a network could use it to identify an
On Apr 22, 2010, at 2:40 PM, Brian E Carpenter wrote:
However, consider that the flow label is a forgeable field, not
protected by any checksum (including IPSEC).
So maybe mutability is in fact the only way to make it safe to
use across domain boundaries?
Interesting. I had it in my head
The problem for me is that if it is arbitrarily mutable, then we can not
use the flow label in a reliable and useful fashion in the ECMP / LAG.
After all, if it is arbitrarily mutable some ISP might set it to 0xFACE
because that was useful to them without regard to specific flows.
I would
It is already mutable, as it turns out. It always was.
On Apr 22, 2010, at 6:57 PM, Joel M. Halpern wrote:
The problem for me is that if it is arbitrarily mutable, then we can not use
the flow label in a reliable and useful fashion in the ECMP / LAG. After all,
if it is arbitrarily mutable
Hi,
Sheng and I would like to continue our attempt to make the flow label
useful. The discussions in Anaheim and on this list have been very
stimulating. I think we need to simplify the change proposed in
draft-carpenter-6man-flow-update-02 even more after the recent
discussions, while
15 matches
Mail list logo
