draft-coene-sctp-multihome

[Bill Fenner <fenner@research.att.com>]

There are a lot of grammar / spelling / sentence structure / document
structure issues, which I won't go into.  It certainly made the document
hard to read.

I think my biggest concern is from section 2.2; my previous assumption
was that if you really wanted to use SCTP multihoming you would make
arrangements a priori to get routing tables that would make it work.
The most obvious answer there was static routing and letting the SCTP
probes learn what paths were or weren't alive; alternately you could
run a seperate instance of the routing protocol specifically to distribute
a known subset of the routes to an SCTP speaker.

However, the second sentence of 2.2 says "The host does not know
beforehand to which other host it is going to send something".
I had not previously considered this as a usage mode of SCTP
multihoming, simply because it was inconceivable to me that there
was a way to make it work properly with routing without teaching
end systems every single route, which in itself is a non-starter
except in very special situations.

I'm not sure what to suggest here.  While it's reasonable to distribute
a small amount of routing information to a multi-homed host, I'm not
particularly comfortable with having that information dynamically based
on what multihomed SCTP peers the host currently has associations with
(as is proposed in the second paragraph).  I'm not sure what the actual
direction would be for the proposal in the final paragraph (of not
requiring any information at the host for multihoming) - perhaps this
means there's an SCTP proxy that knows how to do multihoming and the host
forwards all of its connections through the proxy?  *Something* needs
to have enough information.

I guess I need to get my expectations set (or set someone else's).
I've been expecting that complete use of SCTP multihoming requires a
very special network configuration that most sites would not have,
and either end-systems capable of handling full routing tables or
a special routing setup for the known destinations.  If this is
acceptable, then section 2.2 could say that; if it's not, then
I need to understand better what the expected usage model of SCTP
multihoming is.


On a seperate topic, Section 2.4 seems to be obsoleted by
draft-ietf-ipsec-sctp-04.txt (it has a reference to -02; I don't know if
it has changed significantly).  Since draft-ietf-ipsec-sctp-04.txt is
on this week's telechat, does it make sense for the "issues" document
to raise a solved issue [presuming that ipsec-sctp-04 passes] in the
same way as it talks about the others?


  Bill