RFC1883 and ipv6 spec v2

[bound@zk3.dec.com]

Steve,

>> Upon discussing this with a friend.  We decided that if the label is changed
>> by the router after each hop, that the 20-bits for the label would be
>>enough.
>> Providing (number of routers)^20th or even more if the Flow Label Table was
>> done on a per interface basis.

>Yes, there has been some sporadic discussion in the past about redefining some
>or all of the flow label space to be used in a hop-by-hop manner, rather than
>end-to-end, but the only written-down proposal for such a change expired from
>the internet-drafts directories a long time ago.  If the WG receives a solid
>proposal for a change of flow label semantics (including addressing the
>problem of flow-label allocation to multicast flows across multi-access links),
>we will give it serious consideration.  The weasel words at the beginning
>of the Flow Labels section of the IPv6 spec are intended to leave open the
>possiblity of such changes.

I think your statement here may create an objection from me regarding
your base spec (RFC 1883) at last call, but let me check.

For IPv6 I am assuming that we will have an end-to-end flow in the IPv6
header.  Applications want this and the first use of this field has
validity in RSVP for IPv6.  I don't want to parse into the data portion
of a UDP or TCP packet to identify the flow for many reasons and one of
the drawbacks of RSVP for IPv4 and that its not part of the "standard"
socket data structure.

What do we need to do to guarantee the behavior of the flow label for
applications.  This cannot be a router / forwarding path only
consideration?

I would like to see this nailed down and committed to.

If you want IPv6 deployed widely soon we need to start telling ISVs they
can use this header field for what I speak of above, the first
incantations are RSVP for IPv6 but I believe many integrated services
for networking can use the field as defined now.

The other input is a very serious issue I bring forth here.  Most of all
vendor business revenue streams are from private enterprise we coin
Intranets NOT Internet.  I realize the confusion at present around
defining "differential services" and how "neat" it is for researchers to
speculate on what it may or may not do for IPv6.  But, we need to move
forward with IPv6 and the Flow Label field so we can start deployment of
IPv6.

I would like to see these weasel words fixed one way or the other for
the purposes I state above in the next version of the base spec.

Maybe you clarifying where you think things are will cause a productive
discussion of nailing this down.  The limbo state of a critical feature
of an IPv6 header part for deployment is unacceptable.  And sloth on our
part for not completing this attribute of IPv6.

/jim