Subject: RE: Consensus on identifier/locator split?

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 6 Aug 2003 19:12:45 -0400

> From: "Christian Huitema" <[email-masked]>

    > I believe the question cannot be resolved in a general sense

I don't agree. If you decide it's absolutely necessary to provide a
capability which inherently separates location and identity (be it switching
providers while keeping "connections" open - even if it's sessions, not
classical TCP connections - or mobility, or whatever), they you *have*
answered the question "in a general sense".

Perhaps a more useful question is "do we want to provide one set of
underlying architectural capabilities which can be used to provide separation
of location and identity to a number of different "applications" - such as
mobility, multi-homing, etc.

    > specifically not if you ask for a "locator/identifier split", which by
    > its very wording is tied to the Internet Protocol layer.

Well, not really. I can easily imagine providing the "identification" part at
another layer - e.g. as part of some sort of session thingy.

However, if you want to keep the existing TCP (and I would think that's a
good idea, if you want to try and keep within the bounds of what's vaguely
feasible), then I suppose you have a point.

	Noel

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 7 Aug 2003 12:52:15 +0900

> mobility, multi-homing, etc.

I would personally support that path, but is multi6 the right working
group for a genenal purposed loc+id separation solution ? If the idea is
to standardize a solution which can be used for multihoming, mobility,
etc - (which I would like to see happening), I think it goes further
than the multi6 charter.

> feasible), then I suppose you have a point.

Thierry.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 7 Aug 2003 09:45:48 -0500

I agree with Thierry here, both in my personal support and my
curiosity about
the right place for the discussion to take place. On the other hand,

- multi6 does have a charter that leads in this topic area, and

- while an OPS area working group isn't the right place to do major
protocol/
  architecture changes, it's not a bad place to think about the
impacts of those
  changes.

Spencer