[rrg] Summary of architectural solution space

[William Herrin]

On Fri, Dec 5, 2008 at 4:09 AM, Teco Boot <teco at inf-net.nl> wrote:
> |> / RFC 1887 4.4.2 is obviously not functional with *currently deployed
> |> / network stacks*. It would need the kind of software described in
> |> / strategy B or H in order to be viable. Or do you disagree?
> |>
> |> It depends.
> |
> |If it's conditionally functional and the conditions aren't met then
> |it's not functional. Right?
>
> Not agreed at all!!
> Why block a good solution for certain use cases, because there are (few?)
> other use cases that cannot use it?
> Why force an imperfect solution that has (strong?) disadvantages for some
> (few?) use cases?

Teco,

I think you might be missing my point. I wasn't making a value
judgment on the reasonableness of using multiple addresses in order to
multihome. I was simply observing that the users have spoken and what
they've said is that the currently available tools and protocols are
unacceptable.

Multiple-PA multihoming is conditional on a number of factors which,
in current practice, aren't true. So if we want a multiple-PA solution
like strategy B or H, its necessary to rearrange things so that those
conditions -are- true. Saying "go use it" when there's not an adequate
toolset to go use is really no different than the "do nothing"
strategy.

Anyway, if you really want to rehash the "why's" in detail, that's a
subject for another thread.


> By the way, the term SID could be somewhat misleading. Lets distinguish
> transport layer ID (connection ID) from session ID.

Would you expand on that? I'm thinking of a session as an ID that
conceptually speaking, lasts from the TCP SYN to the TCP FIN. Is there
a better definition of session? What's the definition of transport
layer ID?

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004