Re: Thoughts about layering multi-addressing

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

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

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.

> > Anything else?
>
> 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....

--Pekka