[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flow label versus Extension header
Hi Erik,
Thanks for encouraging the receiver-based allocation idea.
I was reading the thread trying to get up to date, and reading
all the descriptions of trying to fix sender-side systems hurt to
look at.
Erik Nordmark wrote:
marcelo bagnulo braun wrote:
I mean, do you think that if context tag values are repeated across
different context, based on the fact that locator set of the peer are
disjoint, receiver based context tag allocation can guarantee proper
demux?
I mean, as i see it, when we are handling dynamic locator sets, the
only option to guarantee proper demuxing is to solely rely in the
context tag i.e. not include the addresses in the demux operation.
This isn't the only option. With receiver-based tag allocation, then the
receiver can choose which locators it advertises for which contexts.
For instance, a receiver can have multiple locators in each prefix and
keep them separate. So {P1:X, P2:Y} can use tag=1 and be associated with
one context, and {P1:Z, P2:W} can use tag=1 and be associated with a
different context.
Of course, if the host doesn't do this, then it can assign the tags to
that it never needs to look at the locators in order to lookup the context.
I guess this provides a potential extension to the set of identifiers,
but only if the locators are likely to remain separate.
If there was going to be a problem with collision between sets, there
may be possibility for migration from one (reused) identifier to a
receiver unique identifier at locator proposal time, if needed.
It may be possible to have a different identifier (an extended session
identifier) only used during the signaling phase which disambiguates
session maps if there's a collision.
This may allow usage of the flow label on the forwarding plane, without
having unidentifiable proposals to add locators to a non-unique
identifier.
I'd guess the simple case (and fairly general) would be to have the
receiver allocate unique labels in most cases.
[chop]
and finally because of the expected number of sessions, probably we
need a bigger field than the flow label in order to guarantee
uniqueness of the context tag.
I would say that this is the simpler approach. I may not be the most
efficient though.
I agree it is simpler.
One could augment it with the receiver ability, when the peer wants to
add locators to the set, to be able to refuse the addition (due to a
potential conflict).
If that mechanism is present then the receiver can ensure that a tuple
<src locator, dst locator, tag> always uniquely identifies one shim
context. It is't clear to me what tag allocation algorithm the host
would use to maximize the utility of such a scheme. When the allocation
is done, the host has been told the (initial) set of locators for the
peer, so it could at least verify that there isn't overlap between
those. So we can handle overlap in the initial sets that the peers send
in the context establishment, and we can handle dynamic locators, but
the host would have to refuse when a the overlap is due to the dynamic
addition locators by the peer.
I don't know if this provides good enough benefits.
There's a good argument to allow sequential allocation, and recover
old allocations with soft-state (timeout of agreed lifetime, no activity
on an ID for a long period).
Certain peerings could be allocated longer lifetimes (for example, based
on IPSec SA lifetime). By default hosts having difficulty allocating
unique identifiers (for example reaching an allocation threshold) would
start re-using identifiers.
For these hosts, adds/moves/changes of locators to sets may become more
challenging, as refusals and renegotiation occur.
If a recipient can negotiate movement of a session to a different
(unique) identifier, then this can mitigate the issue for troublesome
sessions.
Greg,
Who thinks flow-labels are better than extension headers, otherwise
shim6 looks too much like Mobile IPv6.