Le 13 sept. 2010 à 01:38, Brian E Carpenter a écrit :
> On 2010-09-10 00:09, Rémi Després wrote:
> ...
>> R3. Intermediate nodes MAY replace null FL values by non-zero FL values,
>> PROVIDED these non-zero values generally differ from a flow to another.
>
> IMHO that isn't a strong enough condi
On 2010-09-10 00:09, Rémi Després wrote:
...
> R3. Intermediate nodes MAY replace null FL values by non-zero FL values,
> PROVIDED these non-zero values generally differ from a flow to another.
IMHO that isn't a strong enough condition, if we want load balancing to be
the preferred default usage.
On 2010-09-11 01:18, Pascal Thubert (pthubert) wrote:
> You know that in the back of my mind I still wish to use the Flow Label as an
> alternate to the RPL HbH option.
I can imagine how that might work as long as the packets concerned never
left the scope of RPL, but the results would be very
Le 10 sept. 2010 à 21:02, Fernando Gont a écrit :
> Hi, Rémi,
>
>>> As for keeping track of flows, as I've just noted to Steven, this
>>> is a refinement. But you could probably live assuming that all
>>> flows terminate in a period equal to the duration of the flow label
>>> space (i.e., when
Le 10 sept. 2010 à 22:35, Brian E Carpenter a écrit :
> On 2010-09-10 20:21, Rémi Després wrote:
>> Le 9 sept. 2010 à 23:51, Brian E Carpenter a écrit :
>>
>>> Rémi,
>>>
>>> This is quite similar to one possible version of
>>> draft-carpenter-6man-flow-update-04 that is spinning
>>> around on m
On 2010-09-10 20:21, Rémi Després wrote:
> Le 9 sept. 2010 à 23:51, Brian E Carpenter a écrit :
>
>> Rémi,
>>
>> This is quite similar to one possible version of
>> draft-carpenter-6man-flow-update-04 that is spinning
>> around on my hard disk. But I really want to get clarity
>> (if not rough con
Hi, Rémi,
>> As for keeping track of flows, as I've just noted to Steven, this
>> is a refinement. But you could probably live assuming that all
>> flows terminate in a period equal to the duration of the flow label
>> space (i.e., when the flowlabel space wraps and you'd reuse a
>> flowlabel valu
ided standards are still complied after their networks have been
traversed.
> What do you think?
Expressed above.
Regards,
RD
>
> Pascal
>
>> -Original Message-
>> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
>> Brian E Carpenter
>>
ber 09, 2010 11:51 PM
> To: Rémi Després
> Cc: Thomas Narten; 6man 6man; Steven Blake; Fred Baker (fred)
> Subject: Re: Revising Flow-Labels of RFC-3697 - A possible direction?
>
> Rémi,
>
> This is quite similar to one possible version of
> draft-carpenter-6man-flow-update-04
Le 9 sept. 2010 à 23:51, Brian E Carpenter a écrit :
> Rémi,
>
> This is quite similar to one possible version of
> draft-carpenter-6man-flow-update-04 that is spinning
> around on my hard disk. But I really want to get clarity
> (if not rough consensus) on the immutability thread before
> being
Hi Fernando,
Thanks for the fast reaction.
More below.
Le 9 sept. 2010 à 20:31, Fernando Gont a écrit :
> Hi, Remi,
>
>> Draft-gont-6man-flowlabel-security is based on the assumption that FL
>> values are set as currently specified in RFC 3697, i.e. with a
>> *stateful* algorithm that needs to
Rémi,
This is quite similar to one possible version of
draft-carpenter-6man-flow-update-04 that is spinning
around on my hard disk. But I really want to get clarity
(if not rough consensus) on the immutability thread before
being certain what we should propose.
I think the rules about tunnels sho
Hi, Remi,
> Draft-gont-6man-flowlabel-security is based on the assumption that FL
> values are set as currently specified in RFC 3697, i.e. with a
> *stateful* algorithm that needs to keep track of flow establishments
> and terminations, and with FL immutability.
Note: the only additional "state
Hi all.
Draft-gont-6man-flowlabel-security is based on the assumption that FL values
are set as currently specified in RFC 3697, i.e. with a *stateful* algorithm
that needs to keep track of flow establishments and terminations, and with FL
immutability.
However, assuming that the aim of envi
14 matches
Mail list logo