Re: Thoughts about layering multi-addressing

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

> It is clear that the priority is that the shim provides multihoming  
> support for unchanged ULPs
>
> The question is: after the shim is available, wouldn't it make  
> sense to allow modified ULPs to have a richer signaling with the shim?
>
> I mean, in this scenario, the shim is still used to provide some  
> basic features for multiaddressing support, like the shim protocol  
> is used to securely exchange the address set available for each  
> end, for instance, and perhaps the path exploration procedure of  
> the shim can be used to identify available alternative paths. But  
> shim capable ULPs could actually do some functions that they would  
> perform more adequately, like failure detection more adjusted to  
> their own vision of what a failure is, or enhanced referral support  
> (including all the address set in the referral)

I concur.

Additionally:

To me it looks like the (currently available) locator set is a  
property of a host and not of a connection; locators are meant to  
denote topological locations in the network, anyway.  Hence,  
architecturally, locator set management seems to belong to the  
networking layer, i.e., IP.

We have traditionally taken care of path properties at the  
transport.   Now we are moving some of this functionality to the  
networking layer, which may be the right direction in the very long  
run.   However, IMHO we should aim for a conservative approach where  
we try to keep the shim as simple as possible, and keep the path  
property discovery at the transport layer.

In some way we seem to have two contending goals here:

1. keep locator sets at the IP layer, as a locator set is a property  
of a host and not a connection, and

2. keep path property discovery at the transport layer, as it has  
traditionally been done, separated from IP

However, I don't consider these to be that incompatible; anyway, we  
can have joint data structures that allows this distinction to be  
kept.  Something like Dave's and Avri's CELP, or maybe what Brian  
alluded.  The flip side of this is, of course, that this breaks the  
layering abstraction, somewhat.  Consequently, I think that in the  
very long run we should reconsider where to place the traditional  
transport functionality; my gut feeling is that we may need to split  
it into path-dependent and connection-dependent parts, separated by a  
multi-addressing layer.

So, it looks to me that we are facing something like the following  
steps:

1. Minimally intelligent shim, one primary locator, unchanged
   transports

2. Shim as in #1, richer interface between shim and ULPs,
   shim-aware transports being able to use multiple locators
   at the same time

3. Further research on the proper new location(s) of traditional
   transport functions in the stack

#2 and #3 are clearly research at this point of time, and outside the  
scope of the WG charter.  As I wrote in my first message in this  
thread, I would very much see running code or simulations in that  
space; without that we'd be driving in the dark.

However, I am worried that we may be trying to jump directly to #3  
and design too much functionality to the shim.  KISS vs. over- 
engineering, if you will.

--Pekka Nikander