Jim,
So, you would not support Thomas's solution, if the second bit would
denote that the
label is rewritable?
[Just kidding (-:....]
Seriously now... if labels are entities known and stored by routers, as
part of a flow state, whether
that is part of a forwarding table, or classification rules table, then,
carrying a "read-only/write" bit of information in each and every
packet's header is not necessary.
I have difficulties parsing your second part of the message....
Alex
Jim Bound wrote:
>
> 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
S/MIME Cryptographic Signature
