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

RE: Persistent or opportunistic IDs



Hi Spencer,

> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Spencer Dawkins
>
> 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).

As far as i understand, the application would only need to choose the proper
id that suits its needs. That is, if the application is just a client, it
will use a ephemeral id (i.e. the id with the bit xx set), if the
application will perfom refferals or callbacks, it will choose another id,
on with the ephemeral bit off.
As i see it only the application knows whether it will need to do refferals,
call back or pure client, so only the app can make that choice.
What tasks do you think that can be done in common for all the apps?

(The other opcion is just not to use ephemeral ids...)

Regards, marcelo


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