RE: Persistent or opportunistic IDs

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Iljitsch van Beijnum
> Enviado el: viernes, 07 de mayo de 2004 19:08
> Para: Erik Nordmark
> CC: Multi6 List
> Asunto: Re: Persistent or opportunistic IDs
>
>
> On 6-mei-04, at 23:48, Erik Nordmark wrote:
>
> > If we are assuming that the persistent identifiers provide a superset
> > of the functionality/semantics prociuded by the short-lived
> > identifiers,
>
> No, that's not the case. Unfortunately we all seem to mean something
> slightly different when talking about these two types of identifiers.

agree.
I think we need to include a terminology section or at least to include a
explicit definition when a new concept is used in the architectural draft.

> The difference I'm interested in is the one between a NOID-like
> approach where we have FQDNs and locators, but no new identifier space,
> vs the FQDN -> long lived ID -> locators approach. We had solutions in
> this area on the table a little under a year ago, but this type of
> approach isn't so much in vogue any more now. (This is what I was
> getting at with "old fashioned id/loc approaches".)

I don't have the same feeling about this point. IMHO there are good
proposals on the table that follow this approach, like SIM or HIP. (Thes is
the kind of approaches that you are considering by old fashioned id/loc
right?

>
> Anyway, to get to the point: in NOID-type approaches it's possible to
> be backward compatible with existing transport protocols. This isn't
> really possible with approaches that introduce a new ID namespace.

Why?
I think you can be backward compatible with HIP or SIM, since the new id is
128 bit long. Am i missing something?


> So
> the latter isn't a proper superset of the former.
>
> > then taking the step should be easy; the question is what benefit
> > one would derive, if any, (and at what cost) from taking the step to
> > the persistent identifiers.
>
> Three things:
>
> 1. It's possible to set up new sessions when some locators are
> unreachable without cooperation from applications.

I guess you can do that if you are using something like noid, since you
don't have to use the AID as locator for the first packet (if you know that
the other end supports noid, which is the same for the persistent identifier
case, i think)

> 2. References work.

Well, it would work if have a way to translate from the new id to the
locators, which is not so clear now. Also, if tou are using noid,
refferences may work if the locator that you are using is still working
properly.

> 3. If the identifiers are properly secured (secure mapping service such
> as DNSSEC or the identifiers are crypto-based) there are more and
> better ways to secure the multihoming solution.

Agree. IMHO this would be the main benefit of a new id namespace.


>
> > As one example, I think that multihoming with short-lived identifiers
> > implies a change to the applications that do referrals and/or callbacks
> > (depending on the actual multi6 approach they might need to change to
> > pass FQDNs, locator lists, or something else where they today
> > might pass a single IP address). Thus they need some change.
>
> Yes.
>
> > Will moving from short-lived identifiers to persistent identifiers
> > imply another change to that class of applications?
> > [This is just an example; I don't expect anybody to answer this
> > particular
> > question at this point in time.]
>
> If we can make these identifiers fit inside locators (= they must be 62
> bits or shorter) I don't think we need to change anything that's
> visible to applications. Obviously the multi6 solution must be extended
> to support the identifiers, there will probably have to be a mapping
> service of some kind and we need changes to address configuration so
> hosts can configure themselves with an appropriate identifier.
>
> > Thus I do think we'd need to understand more details about such a
> > transition
> > (or probably, coexistence) between different classes of identifiers
> > before being able to guage the cost/benefit tradeoffs.
>
> Of course. Let's start with a question that's probably a bit easier to
> answer: is a NOID-like solution that's mostly about keeping existing
> sessions running when there is an outage sufficient?
>
>

IMHO, something like NOID probably can provide most of the stuff required
for multihoming support. However, since the adoption of a multihoming
solution will impose an important effort becuase it implies the modification
of all the hosts, then it makes sense to adopt a solution that provide most
benefits, even in other areas.
I mean, introducing a new id namespace, for instance a crypto based
namespace, wouldn't be also help to provide a better support in other areas,
like mobility, enhanced security, etc?
I guess this is one of the key outputs of the architectural analysis, a new
namespace or not?

Regards, marcelo