RE: MAST Review JimBo

["Bound, Jim" <jim.bound@hp.com>]

Dave,

> Many thanks for the detailed comments.  I'll send detailed
> responses, later, but wanted to offer some quick reactions quickly:

OK.

> 
> 
> BJ> Attached are revs of MAST and CHOICE.  Bottom line is I
> think MAST
> BJ> should just stick to multiaddreses injection btw transport and IP
> BJ> layer.
> 
> That's what it does.

I believe there is much other work going on in MAST that is not
multiaddressing.

> 
> However I think that your embedded suggested to just focus on
> multihoming, rather than including mobility, exactly misses 
> the point behind the term "multiaddressing".  As I suggest in 
> the docs, mobility and multihoming should be viewed as two 
> sides of the same requirements coin.  The general form of 
> each has properties of the other.

Mutliaddressing technical depth work is a lot of work and will take time
to finish your model, then to build an architecture, and then eventually
a true protocol specificaiton. My point was to not confuse that work
with the many discussions around multihoming and mobility (so both)
stick to the technical work at hand with multihoming and mobility as
input clearly.  I am saying if this work is to be useful it requires
very focused technical work as what your suggesting sits between the
transport and IP layer in implementaitions and requires much analysis
and thought. 

But I also believe SCTP is the real way to solve this and until SCTP is
deployed out of just Telco this will not be fixed.  Multi6 could make
SCTP a mandatory requirement for all platforms.

> 
> 
> BJ> But, I think SCTP does this fine and any extensions your model
> BJ> proposes is input to SCTP.
> 
> As I note, putting the functionality inside transport is a
> reasonable approach. However I think that the nature of 
> multiaddressing support really is independent of particular 
> transports and am increasingly of the view that it needs to 
> be in an "endpoint" IP layer, above the relaying IP layer.

But SCTP already has it done.  Including addition and deletion of
addresses.

So can you clarify what is missing in SCTP?

> 
> Basic IP handling is done well.  We should not mess with it.
> So my own bias is increasingly against messing with the core 
> of IP.  Multiaddressing works quite well and an endpoint 
> service.  The use of an intermediary (such as a home agent, 
> for the mobility folks) is an extremely useful adjunct, but 
> is not essential to the model.

What does this mean?  MIPv6 works?  The issue here is orthogonal.  It
would help if you could clearly articulate in model terms what problem
your trying to solve and then we can put it in terms of technical
options.  Movement Detection et al is another working group.

> 
> 
> BJ> I think also you should label MAST as a "Reference Model"
> stage no
> BJ> one could implement this except maybe a rapid base prototype and
> BJ> then only
> 
> The document tries to make clear that it is not a
> specification.  It defines functionality, sufficient to 
> permit evaluating its essential architecture.  It defers the 
> specification tasks that are equivalent to "debating between 
> commas and semicolons".

Try just calling it a model that is far more clear than members guessing
thats what you mean.

> 
> 
> BJ> believe you have a model.  But I see no advantage at all
> over SCTP
> BJ> and
> 
> SCTP is still developing its support for mobility.  More
> importantly is that it offers nothing for the installed base 
> of TCP, whereas MAST targets that base.

My view is if you want this to work with IPv6 you move to SCTP it will
be a much cleaner and safer path than MAST hacking between the transport
and IP layers and then call outs to the DNS et al tomorrow.  Also most
platforms support SCTP now because of Telco market. Randy is doing a
poll now who has it and who don't.


/jim

> 
> 
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
> 
>