Re: Persistent or opportunistic IDs

["Spencer Dawkins" <spencer@mcsr-labs.org>]

I like the idea here, but this does seem like functionality that
shouldn't be coded application-by-application. It's easier to get
right than congestion avoidance, but it's duplicating a lot of
functionality in every application (that cares about identifier
lifetimes).

Spencer


From: "marcelo bagnulo" <mbagnulo@ing.uc3m.es>
To: "Erik Nordmark" <Erik.Nordmark@sun.com>
Cc: "Geoff Huston" <gih@telstra.net>; "Iljitsch van Beijnum"
<iljitsch@muada.com>; "Multi6 List" <multi6@ops.ietf.org>
Sent: Wednesday, May 12, 2004 4:25 AM
Subject: RE: Persistent or opportunistic IDs


> >
> > Yes. In effect the application need to know and express to the
"stack"
> > whether there is a need to do "callbacks" on referrals, since this
> > affects which source identifier to use for the communication.
> > Would such a scheme be acceptable for the applications?
>
> I wouldn't dare to answer that question considering my limited
knowledge on
> apps, but, perhaps it would be possible to distinguish the ephemeral
ids
> from the stable ids (IP addresses in this case) using a
ephemeral/stable
> (e/s) bit in the id itself.
> So, when the app that will perfom a call back discovers its own
identifiers,
> the noid+wimp layer will show multiple addresses, some stable ids
and some
> ephemeral ids. The app can, because of the (e/s) bit on the ids,
identify
> the ephemeral identifiers, so it can avoid sending them to the other
end as
> a call back information.
> Perhaps, something similar can be done with refferals. I mean, the
> application first discovers the ids available in its own endpoint,
and then
> selects one that fits its needs, (stable or ephemeral), and then it
performs
> a bind to the selected id.
>
> But perhaps this is too complex and i don't know if it is worthy...
>
> Regards, marcelo
> >
> >    Erik
> >
> >
>
>
>