Multipath (Re: draft-coene-sctp-multihome-03.txt)

[Harald Tveit Alvestrand <harald@alvestrand.no>]

seems to me that we need to branch briefly into architecture here.

in the Internet architecture:

- an address does not determine a path. The path can change, and will often 
change in response to failures.

- the sharing or non-sharing of paths between two destination addresses 
that "end up in the same place" is unknown and unknowable to the sender for 
all hops beyond the first hop.

- nevertheless, sometimes some legs of the path can be different for two 
destination addresses, and there is presumed to be some set of failures 
that will affect one path and not the other

- given that set of failures, and the presumption that it is significant, 
the approach of SCTP's multiaddress feature makes sense

- one can do operational things that increases the count of possible 
failures that affect one path and not the other

- and that's what this document should say



--On torsdag, april 03, 2003 06:36:26 -0800 Randy Bush <randy@psg.com> 
wrote:

> ops-dir review:
>
> - needs editorial, ID-nits, etc. work (e.g. references in the abstract,
> author's address vs editor's address at the end, titles, section
> headers etc. should be first-word capitalized, etc.)
>
> - the request for arch review seems valid.  A workaround would be trying
> to split off stuff about routing paths (other than writing down a problem
> with them).  Ie. it's a different thing to say "knowledge of routing paths
> may be needed for reasons A, B, and C; a solution is TBD." than saying
> "knowledge of routing paths may be needed for reasons A, B, and C, and
> therefore routing paths must be exposed to end-hosts with mechanisms D,
> E,  or F" (or even somoething more normative).
>
> - that is, I'd like to try postpone the issue of routing paths until/if
> we  get some architecture on the subject (much more generic than SCTP)
> first.
>
> - in the SCTP context, I'm not expert, but I'm not sure if it's
> requirement to use "best paths" or absolutely know the routing paths.  I
> think a working principle could also be "try one; assume it works until
> you know otherwise".
>
> - the other option would seem to be work on the architecture now, with
> this draft..  frankly doesn't seem to be realistic.