Re: always including the context tag

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

On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote:

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

Clean != best

We also have ample precedent for non-clean solutions.  :-)

> > 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?

Right, but that's not a discussion that we need to have. What I  
advocate is having the receiver tell the sender that it must not  
include the header because the receiver can demux. How the receiver  
does this is up to the receiver and doesn't need to be part of this  
spec. (The most obvious choice is having locator-only addresses for  
each ULID address so there is always an unambigious identification of  
packets sent to locators and an unambiguous mapping back to the ULID.)

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

They're useful, but if we have locator preferences and not context  
tag suppression, this creates the opportunity for using shim6 as a  
load balancing mechanism that introduces additional per-packet  
overhead in cases where there is no failure. This is a very bad  
thing, in my opinion.

So that's why I think if we can't agree on the CT suppression in this  
spec, we should also remove the preferences and then introduce both  
of them at some later date, along with a more comprehensive traffic  
engineering solution, because the preferences alone aren't enough for  
that anyway.