always including the context tag

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

In his review Iljitsch raises the following issue:

my comments are online:

please comment on the issue related to if we should support other 
mechanisms for demux other than the context tag contained in the shim 
payload header

> 1. Always including the context tag
>
> As I've said many times, it's a very bad idea to unnecessarily 
> increase overhead.

well, i think having an additional header is the clean way to do this, 
because there is an additional layer that is being inserted and the 
layer needs to perform its signalling and this is achieved using a 
extra header.

>  Not only is this a bad thing in and of itself, but it also doesn't 
> help convince people to forego IPv4+BGP in favor of IPv6+shim.
>
> Now if we only include the shim header containing the context tag 
> after a failure, this could be a reasonable tradeoff. However, I'm 
> quite sure that if and when shim6 is adopted, some people will use it 
> to manage their traffic engineering by doing a locator change 
> immediately and proceed in a shimmed state for the rest of the 
> communication session.
>
> Earlier, I proposed to include a mandatory way for a host to instruct 
> its peer to not include the shim header, pending mechanisms to do 
> demultiplexing without the context tag. After reading the draft, I 
> realize that this imposes some extra ICMP demultiplexing difficulties 
> on implementations.

depending on which fields do you use for the demux, i guess... i mean 
if you use the flow label, there wouldn't be additional problems, i 
think, right?

>  So if the wg doesn't want to include this mandatory option, I suggest 
> something different: since the traffic engineering mechanisms aren't 
> really developed anyway and this problem is related to that, simply 
> remove the locator preferences mechanism so that the context tag 
> suppression can be included when proper traffic engineering is added.

i don't think this is such a good idea...

i mean i think locator preferneces are useful, i don't see why we 
should remove them from the spec...


> Also see draft-van-beijnum-shim6-suppress-header-00.txt (do it while 
> you can, it expires next week...), this outlines a more fully formed 
> mechanism to suppress the context tag header.
>
> I would very much like to see a consensus call on this subject.
>
>