Hi Fred,
Le 4 août 2010 à 10:13, Fred Baker a écrit :
> intellectually, end to end signaling might make sense. If so, it belongs in
> the end-to-end headers.
+1
> More importantly, who's using it?
>
> If using it end to end or end-to-network isn't being useful, either find a
> use, or deprecate it.
RFC 3697, the current standard-track RFC on FLs, doesn't need IMHO to be
deprecated.
It only needs to be improved by relaxing two unnecessary and harmful
constraints (see below).
Reasons to keep RFC 3697 are the following:
- The official purpose of FLs is to facilitate flow-dependent processing in
networks.
- At least draft-carpenter-flow-ecmp-02 describes a pragmatic use of such FLs
for load sharing among equal-cost paths.
- More generally, any load sharing application could take advantage of these
FLs, because they facilitate flow separation:
. With the help of FLs, two packets having different FLs are known to belong
to different flows.
. Without FLs, scanning complete extension-headers is necessary to find out
ports that identify individual flows (a complex task, and one that becomes
ineffective in case of datagram fragmentation).
It is a fact that FLs are today generally set to 0 by sources.
But RFC 3697 requires in its section 3 a stateful and rather complex
construction of non 0 FLs.
This is bound to discourage host implementors as long as networks don't use FLs.
Now, networks aren't permitted to set FLs themselves even if set to 0 by hosts.
There is then a vicious circle where hosts wait for networks that wait for
hosts.
The two modifications of RFC 3679 that may break the vicious circle are:
- Permit intermediate routers to set FLs in place of hosts if received = 0.
- Permit hosts, and routers when they set FLs, to use simple hashes of the 2-
3- or- 5-tuples that identify flows. (This stateless behavior could even be
recommended so that things are kept simple where there are no good reasons to
make them more complex.)
I hope this isn't too long, but it is the best I can see on this subject.
Having a consensus in this direction would permit to leverage what exists
(rather than restarting from scratch), and to move on.
If this this approach is retained, I could contribute on detailed changes to
RFC 3679, with whoever is interested.
Regards,
RD
With FLs, rather with a heuristic flow ID
>
> On Aug 4, 2010, at 10:00 AM, Randy Bush wrote:
>
>>>>>> The flow-label can belong either to the network -or- to the
>>>>>> host(s): pick one[1].
>>> ++
>>
>> <aol>
>>
>> we have spent over a decade trying to find a home/use for flow-labels.
>> e2e signaling makes simple sense. let's try to declare victory and move
>> on.
>>
>> randy
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> http://www.ipinc.net/IPv4.GIF
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
