[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: always including the context tag
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
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