Hi Thomas,
>> 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).
>Yes, I agree here in fact I'm writing a draft on this topic and the way I
>have intended to see it (then we can debate if people agree) is that we
>should have a dual-semantics of the flowlabel and inside the flow-label have
>one bit telling if the flowlabel is globally unique and possibly one bit
>telling if its ESP encrypted (see earlier discussion about changing the
>length field to ip header length field)
OK I will read it. But I don't support changing the header length field
at all.
>> The other option is to use the traffic class bits.
>If the bit is not set, you mean? If so of course - I agree.
Yes.
>> 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.
>Why do you think we need to take extra bits from the flow-label? The way I
>thougth most people saw it was to use to two unassigned bits in IPv4
>ToS/IPv6 Traffic Class field for ecn??
Because the diff serv bits are too precious rather take one from 20 than
the few left in tos/class. But I am not convinced this is the correct
technical answer but might be the only answer. I got at least 4
different inputs in the customer base for four different uses of the
flowlabel. But the good news is the needs all aggregate to I hope two
solutions we are discussing now.
>> 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.
>
>But why not use the extra two bits for ECN and use the flowlabel with dual
>semantics:
>1) intserv/per flow identification set by the client in the access
>2) mpls like semantics in the core with a possibility to do mpls-like TE (I
>say mpls like since it should be the same management software operating on a
>different traffic plane - v6 header instead of mpls header)
Think I answered above on why not the tos/class field.
I suppose if we can bit-twiddle the ECN bits to do what they need to do
and get a differentiation for flowlabel that would be cool.
regards,
/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]
--------------------------------------------------------------------
