[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some Comments on ID/Loc Separation Proposals

On 18-nov-03, at 23:04, <Margaret.Wasserman@nokia.com> wrote:

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?

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

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.

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.

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.