[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts about layering multi-addressing
In any of these approaches, the locator annotated for outgoing
packets are a suggestion of they must be honored? i mean, i guess
this is related with how does the shim informs the ULP that a given
locator is no longer reachable, right?
I don't know what would be the right approach. Currently I think
that the best approach might be to signal the ULP that the shim layer
was unable to send the packet due to the suggested locator no more
being associated with the ULID. At that point the ULP could ask the
shim for the new set of active locators, and pick a suitable one from
The alternative would be the shim layer to pick the locator, in the
same way as it would pick if there was none given by the ULP. The
drawback of this approach is that the ULP has no information about
the locator having been overwritten...
Hence, my question is if the transport are likely to need anything
else than the following:
- both ULIDs and locators in incoming packets
- ability to define locators for outgoing packets
- what happens if the locators are not available any
more? Host-internal ICMP-like response?
coming back to this point.. by locators you mean locator pair,
right? i mean the shim should inform the ULP that a given locator
pair is no longer reachable, right?
As I indicated above, I am no that far yet in my thinking. So, the
brief answer is that I don't know.
I wonder if it wouldn't be useful to allow the ULP to inform the
shim about some sort of preferences w.r.t. which alternative
locator pair to try with in case of an outage.
Hmm. Let's consider the complexity implications. If the shim just
fails and signals the ULP about the failure, the ULP will have all
the necessary information about picking a locator to use. It can
easily update its preferences dynamically based on multiple source of
input, e.g., based on flows on different locators. That would keep
the shim simple, pushing the complexity to the transport.
On the other hand, if the shim has more information, such as
preferences per transport, that brings more complexity to the shim
layer. Conversely, if we accept the architectural principle that I
suggested, we shouldn't pick this way, as in this case the shim knows
more than is absolutely necessary.
I am currently tempted to try to keep the shim as simple as
possible. Due to having transports that won't know about locators,
we clearly need to have some sort of preferred locator at the shim,
and associated fail over mechanisms. However, to me it "smells"
better if we would not use them, at least by default, with more
intelligent transports that supposedly know better.
But there is one point here: As we apparently need to have a
preferred locator at the shim, we should allow the transports to
learn about that, too. Apparently we also need some administrative
interface for changing the preferred locator dynamically....