RE: Some Comments on ID/Loc Separation Proposals

[<Margaret.Wasserman@nokia.com>]

> Wnc> The use of the term "Identifier" or "ID" sweeps an important
> MWnc> issue under the rug in some cases:  Is this a host ID or an
> MWnc> interface ID?
> 
> or a 'stack id' or an 'endpoint id'?  and what do these mean,
> precisely.

Exactly,  Noel Chiappa referred to a host/endpoint/stack ID as though
a host, an endpoint and a stack are all the same thing.  But are they
really the same thing?  Is there even a 1:1:1 correlation between
these things?

> MWnc>     - Initial end-to-end connection set-up.
> MWnc>     - Referrals.
> MWnc>     - What happens when two nodes try to establish connections
> MWnc>       to each other "simultaneously"
> MWnc>     - How does the mechanism avoid connection hijacking?
> 
> These are really good points.  For example, I had frankly been
> avoiding trying to handle referrals, but any solution needs to attend
> to this requirement explicitly.

Yes.  And, there are enough commonly deployed application that use
referrals that I think that we should consider it an operational
requirement that a multi-homing mechanism includes support for
referrals.

> MWnc> MAST Feedback:
> 
> MWnc> Uses a control protocol between the two end-nodes to 
> MWnc> exchange address information.  The current proposal is
> MWnc> two sparsely defined to allow a full analysis of its
> MWnc> properties.
> 
> And, of course, that is intentional.  The intent is to distinguish
> between basic approach, versus the essential details of a
> specification that permits real implementation.

I understood that this was intentional, and I didn't mean to be
insulting in any way.  It's just that the proposal is not yet 
detailed enough to allow the type of operational/functional analysis
that I was trying to perform.

> MWnc>         - How do the end-points know when they need to
> MWnc>           send SET operations to update the locators 
> MWnc>           being used on the ends of this connection?
> 
> ignoring the heartbeat function that is suggested, why would not the
> obvious "when something changes" rule suffice?

How would an end-node detect when "something changes", such as 
connectivity through a particular ISP?  The routing system may know
about this change (through routing protocols, for instance), but
I don't know how the end-node IP stack would notice -- unless it
receives some sort of "advice" from ULPs when communications are
failing to progress?  Or snoops routing messages?

> MWnc>         - The draft suggests using IPsec to secure the
> MWnc>           control connection, but IPsec doesn't support
> MWnc>           changing end-point addresses.
> 
> As one or another of the other wedge proposals suggests, IPSec would
> run above the Mast address pool mechanism.  Hence, IPSec would only
> see one "address".

So, the MAST control connection would also run over MAST, using
the MAST IDs?  If so, how is the initial connection set-up
accomplished?  Is there a bootstrapping issue here?

> MWnc>         - The PROBE message sounds (to me) similar to 
> MWnc>           the old proposal to use pings to detect dead
> MWnc>           gateways.  What can we learn from the problems
> MWnc>           with that model that apply here?
> 
> I, too, would greatly like to hear feedback on this construct.  I've
> seen a couple of comments that raised no concerns about it, but none
> that offered assurance it would work ok.

One of the problems with active connectivity detection is bandwidth
use.  Perhaps this could be alleviated by suppressing MAST messages
when ULPs are progressing -- similar to how Neighbor Solicitations
are suppressed in IPv6 ND?  

Margaret