Subject: MAST Review JimBo

From: "Bound, Jim" <[email-masked]>
Date: Fri, 7 Nov 2003 00:39:11 -0500

Dave,

Attached are revs of MAST and CHOICE.  Bottom line is I think MAST
should just stick to multiaddreses injection btw transport and IP layer.
But, I think SCTP does this fine and any extensions your model proposes
is input to SCTP.  

I think also you should label MAST as a "Reference Model" stage no one
could implement this except maybe a rapid base prototype and then only
by consulting with you.  Not ideal for implementation.  So for now I
believe you have a model.  But I see no advantage at all over SCTP and
SCTP does this naturally to support multiple addreses and has mechanisms
to add them and delete them.  The model discussion is fine here and part
of the multi6 charter for problem to solve at hand.  But the actual work
on a real architecture and spec I think would be done as new WG in
Transport Area.  But as I said SCTP solves this problem.  

On CHOICE I think this should become two drafts and orthogonal to MAST.
One is a draft on emerging terminology that would exists next to our
multi6 requirements.  The other one would be the long list of
"assumptions" you state about our required terminology.  These should be
separate efforts and have nothing to do with MAST.

Regards,
/jim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 7 Nov 2003 00:05:29 -0800

Jim,

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

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 layer.

That's what it does.

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.

BJ> But, I think SCTP does this fine and any extensions your model proposes
BJ> 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.

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.

BJ> I think also you should label MAST as a "Reference Model" stage no one
BJ> could implement this except maybe a rapid base prototype and 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".

BJ> believe you have a model.  But I see no advantage at all over SCTP 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.

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