Subject: Re: Transport level multihoming

From: [email-masked] (Sean Doran)
Date: Sat, 4 Aug 2001 12:00:45 +0200 (CEST)

I think that if a draft comes forward which is explicit in how
it meets the present requirements work, or is explicit in WHY it
obviates the present requirements work (a la Randy's question), 
that not even I am too stubborn to insist that we ignore it.

Put another way - the obvious next step after we have the reqs out
the door is to do a detailed comparison of the various individual
proposals that are on the table now (and the ones that aren't yet),
and try to come up with a rough consensus on which one(s) we propose.

It's rather hard to validate one's belief in a given architecture
without understanding what it is you're trying to accomplish, and
frankly from my perspective as a netwok operator, that lack of
understanding is commonplace.

Ignorance is neither shameful nor incurable - what we're
trying to do with the first two drafts is to demonstrate
that the elephant is not a kite, a snake, or a tree.

I realize that this is slower than some people would like,
but frankly, if anything, I regret to say that *every* proposal
may obviously "need more work" when compared to the reqs draft.

Please do not take that as a cheap shot at the authors
and potential authors.  This is not a trivial problem
to solve and it is beyond the ability of any single
writer to draw up a complete solution.   That's hopefully
why we're trying to engineer in committee anyway, and while
we're here we can make it easier on authors by pushing them
into treating the reqs document as a series of FAQs that ultimately
need to be answered.

Obvious valid answers are "we do X",  "we don't do X but...".
On the other hand "we think X is stupid" is something that
should really be dealt with in advance (i.e., NOW) so that
we don't have to keep rewriting the reqs when we discover
they're wrong in some way. :-)

	Sean.

---

From: [email-masked] (Sean Doran)
Date: Sat, 4 Aug 2001 12:09:53 +0200 (CEST)

| According to the chairs, we shouldn't figure out how to properly route
| it yet, until we finish our requirement draft.

I (personally) would really love some answers to the questions
I posed to you when I wrote up the analysis of your draft here
on the mailing list some months ago.   Certainly, I can be
persuaded that your solution is both a complete and a routing one,
but it will take some work.

I also hope to have some time to write up some detailed questions/comments
about the other specific proposals, but was hoping other folks in the WG
could do some of that for me. :-)

| While 3 multi6 meeting are being spent on it, discussions on specific
| proposals are discouraged to make the requirement draft abstract
| and separated from the real world.

The reqs draft should be based on the draft which explains
what the real world is today.  Anything else would be foolish.
Therefore, I think we are in agreement.

What I would like to have is a toolset so that you and your
"competition" (i.e., other authors) have some hints about the
criteria which must be met before anything like rough consensus
happens in the WG.   The reqs doc based on today's practises,
cleaned up a bit and so on, is the best thing I can think of.

I am open to suggestions.   However, I think we are using
too much time in meta-standardizing.   The reqs document is
not really that hard to complete and move forward.

If you think the reqs are separating from the real world,
please shout out now with specific objections, rather than waiting
for the formal last call.   I know that people are listening...

	Sean.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 7 Aug 2001 15:46:54 -0700 (PDT)

Sometime back there was some discussion on multi-level multihoming
scenario while GxSE was being discussed i.e what if your upstream
ISP is multi-homed, how does GxSE work in this case ? 

Doesn't similar constraints apply to any transport level solution ?
I am not sure how a transport solution works when one of the
upstream ISP's link fails. Isn't this one of the requirements ?

thanks
-mohan

> Date: Tue, 07 Aug 2001 17:01:51 -0500
> From: Brian E Carpenter <[email-masked]>
> X-Accept-Language: en,fr
> MIME-Version: 1.0
> To: Greg Maxwell <[email-masked]>
> CC: Ben Black <[email-masked]>, Randy Bush <[email-masked]>, Peter Tattam 
<[email-masked]>, [email-masked]
> Subject: Re: Transport level multihoming
> Content-Transfer-Encoding: 7bit
> 
> Greg Maxwell wrote:
> > 
> > On Tue, 7 Aug 2001, Brian E Carpenter wrote:
> > 
> > [snip]
> > > On the other hand we know that major restructuring of applications isn't 
going
> > > to happen - that's the real world. So if we have to do work in the 
transport
> > > layer, the transport layer is going to have to hide most of it below some
> > > sort of socket API. I can't see any reason in principle why that API
> > > would have to expose a bunch of addresses, even if it turns out that
> > > multi6 requires more than one. A "primary" address per host would be 
enough
> > > to expose to the middleware.
> > 
> > If the primary address is functional at connection setup time, then, yes
> > it could learn the other transports from the remote end. However, what do
> > you do if the primary is down? The only solutions I can think of either
> > require the applications to rotate the address passed to the API, or
> > require the transport to consult DNS (what an ugly kludge and layering
> > violation THAT would be!).
> 
> There is *always* an abstraction layer above which a single handle identifies
> the other party in a session (and probably no handle at all identifies
> "this" end of the session). So whatever layer is the highest layer to
> be aware of N addresses, there is always a layer above that (conceptually
> at least) that has a single handle for that set of N addresses.
> 
> All I am saying is that this abstraction layer may just as well be a socket
> API, and that single handle may just as well be one of the N addresses - and
> if you do it that way, you minimise the impact on existing apps layer logic.
> 
> It's probably sloppy to write as I did of a "primary" address being the
> handle; it's just an arbitrary choice among the N addresses available.
> It's the one that gethostbyname (equivalent) chooses to return to you;
> it might conceal a bunch of others from you below the socket API,
> and use them as needed for multihoming or whatever other cookery it
> needs to do.
> 
>    Brian
>