Dear All,
splitting this field not so obvious:
- API should be changed - or at least truncate the existing flow field to
8 bit.
- applications relying on 20 bits flow bits should be sought and fixed. I
believe they assumed the flow field is immutable
Although I dont see the motivation for the flow field to be mutable.
Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
On Thu, 29 Jul 2010, Pascal Thubert (pthubert) wrote:
Hi Aleksi:
I think that the premise in the discussion was that the network egress
is incapable of restoring zero.
This taken into account we observe that:
- there is a clear and documented need for the network to tag the
packet. This happens for load balancing reasons, but also for routing
reasons, when multiple topologies can be used (eg multihoming, RPL
etc...)
- 12 mutable bits is seen as enough. We had a proposed usage in RPL that
needed just that as well. RPL ended up with the Hop by Hop mainly
because the use of flow label was too largely undefined to feel safe
using it, with the side effects that you know of, like IP in IP.
- flow label is the only field that an application can use to place an
abstract tag in the packet in order to dialog with the network. Removing
that capability seems really short sighted.
- 8 bits have been enough for a considerable amount of functionality in
the past. For the one I have in mind - application aware tagging, it is
enough.
What can I say? We are asked to choose between 2 evils when a simple
trade off exists...
Pascal
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of
Aleksi Suhonen
Sent: Wednesday, July 28, 2010 5:01 PM
To: [email protected]
Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable
Hi,
On 07/28/10 13:24, Tina TSOU wrote:
I like the proposal from Pascal Thurbert in today's meeting.
I believe that It's more acceptable for the majority of the
different
camps.
I hated it. :-(
I feel that changing the structure of the IPv6 header like that at
this stage is too
late. And I feel the change is bigger than people think it is.
Some earlier discussion has suggested that if the label is "0", then
it's mutable
and otherwise it's immutable. And if an operator does change it, they
should
reset it on egress, and maybe hijack some other bit in the header
(e.g. from
DSCP?) to signal that the flow label has been fiddled with. This bit
should of
course also be reset at the same time as the label is reset.
--
Aleksi Suhonen
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
