Re: [Tsvwg] multiaddressing

Ok, I will finally comment a bit on this :-0

Wesley Eddy wrote:
> On Mon, Nov 15, 2004 at 01:40:47PM -0500, Wesley Eddy wrote:
> 
>>In draft-crocker-mast-analysis-01 (now expired), the concept of
>>"multiaddressing" for solving multihoming and mobility problems is
>>explained.
>>

The crocker draft was just an attempt to take the
SCTP add-ip draft and duplicate it into a lower level.. I never
thought it would work since the reason we have been holding
the add-ip draft is the fact that there are security issues
with it. These should be solved as soon as we finish the
work on the auth draft.. but you can't do that without state which
means a shim layer can't do it.. unless you want to mirror all
the transport state at a layer below transport.. ughly and far
from simple... I know that first hand.. I am working on NAT
and SCTP and let me tell you its tricky when restarts can
show up .. and thats not even the multi-homing .. just single
homed SCTP :-0

>>The HIP groups and multi6 are focusing on multiaddressing solutions
>>built for "simple" transports that can only bind to a single address
>>with no means to update or extend that binding when it might be required
>>by mobility or multihoming.  Adding a wedge-layer to map dynamic locators
>>to fixed identifiers fixes these problems and allows the transport to go
>>untouched and remain simple.
>>
> 
> 
> I previously brought up the idea that a multiaddressing wedge should at
> least pass a bit up to the transport to notify it of mobility events.
> 
> Another consideration, in comparison to systems where the transport does
> all the book-keeping of addresses and handles mobility and multihoming
> on its own, is that the transport<->wedge interface will likely not be
> rich enough for the transport to do the sorts of things that SCTP is
> capable of, like retransmiting on alternate paths, load balancing
> between interfaces, etc.  I'm not sure that the wedge interface could be
> made rich enough to support those types of transport decisions without
> completely negating the benefit of its simplicity, and certainly we
> don't want the wedge to be doing those types of things silently itself
> without the transport's consent.

I just don't see how you can have anything simple below transport
doing this.. It just gets more and more complicated.. IMO we should
leave it where per-connection state can be maintained so one can
do the necessary things...

R

> 
> It looks like this issue is another point in favor of transport-based
> mobility/multihoming schemes.  I'm still in favor of passing the
> book-keeping off to a common wedge somehow, but it looks like there's
> still quite a bit of utility in having the transport be able to query
> and richly interact with that wedge, rather than have it just
> transparently "make things work".
> 
> -Wes
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tsvwg mailing list
> tsvwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg