[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flow label - the problem



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.)