Subject: RE: Some Comments on ID/Loc Separation Proposals

From: <[email-masked]>
Date: Tue, 18 Nov 2003 17:04:34 -0500

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Nov 2003 11:32:44 +0100

> really the same thing?  Is there even a 1:1:1 correlation between

Is the nature of that which is identified an important attribute of the 
identifier? I don't believe it is. But if I would have to make a 
choice, I'd go for a host identifier, or stack identifier in NSRG 
terminology. (But I prefer the term "host identifier".)

>> For example, I had frankly been

> requirement that a multi-homing mechanism includes support for

As referrals are pretty much broken in today's internet anyway, I don't 
see why we would have to burden multihoming mechanisms with meeting the 
fairly arbitrary expectations of applications doing referrals. A much 
better approach would be to spin off this issue and solve it 
independently of what happens with multihoming.

> use.

Yes, this is something we need to avoid.

> Perhaps this could be alleviated by suppressing MAST messages
> when ULPs are progressing

Supress them too when the upper layers are idle. This can lead to a 
slight delay when the communication resumes if something went dead in 
the mean time, but that's certainly preferable to wasting bandwidth 
when nothing is going on.

For wedge solutions I'm thinking along the way of monitoring ULP 
interactions and only send and explicit keepalive (request) when there 
is no traffic from the other side when the failover logic expects there 
to be. For a transport solution this would be unecessary as transport 
protocols know exactly when something should be coming back or not, so 
the only reason to do keepalives would be to see which paths are 
available when the primary one looks dead.