Re: Flow label - the problem

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 24-apr-2005, at 19:52, Erik Nordmark wrote:

> > Yes, but not necessarily at this point. Presumably, the shim  
> > address  remapping will happen early in the processing of a  
> > packet, while  scanning the full list of extension headers happens  
> > much later.

> Can you explain why such (undesired from a performance perspective)  
> type of behavior would be required?

Well, I can't be sure, but if processing of any other headers that  
may be present requires knowledge of the ULIDs then it could be  
necessary to go through the list of headers twice.

But...

> AFAIK it is sufficient for the implementation to step through the  
> extension headers, and when and if it finds a shim6 extension  
> header, it would lookup the shim6 context state, and remap the IP  
> address fields to the ULIDs that are contained in that context.

I guess that that should be enough if we can proscribe that the  
headers that come before the shim header (counting from the beginning  
of the packet, not the order in which they are created) only deal  
with the locators and the ones that come later only deal with the ULID.

So in that case there aren't any adverse effects when the header  
isn't present.

I still don't like it, though.  :-)

(And the argument that a header will give us a more bits is a  
fallacy, 20 bits is already more than we should want to use up. Less  
is more, as a long label only increases lookup times.)