Thomas,
>And I also think that IPv6 should "borrow the mechanisms". An I would like
>to see a combine model for use of the flow-label where the "intserv"/per
>flow model would exist in the access and that a aggregated/"differv"/"mpls"
>like model with possibility to re-write the flow label would exist...
The only way I for one would support what your saying is if we also
defined the first bit of the flowlabel to denote it can be rewritable.
That first bit set or not is decided by the client or the clients
network (meaning a zone within which the client exists authoritatively).
If this bit is set then any e-2-e predications are lost and users would
need to understand that.
The other option is to use the traffic class bits.
But I also think the flowlabel can be used when defined by the client
and set by the client to assist greatly the evolution of the ECN model
and help with increasing bandwidth efficiency with TCP to notify a
client with a fast path for the search to find the clients entry in the
table. So I will argue what the router folks have done with MPLS will
need to be done by those wanting faster searches for congestion and lost
packets with TCP.
Steve's position is par excellence and I would like to see your response
to Steve as Alex has?
/jim
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
