Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt]

From: [email-masked] (Noel Chiappa)
Date: Thu, 7 Jun 2007 11:41:49 -0400 (EDT)

> From: Scott W Brim <[email-masked]>

    > - "Within its site, A must have an Identifier and Locator that match
    > - 1:1 for the convenience of operational staff"

    > Do you really mean 1:1? There needs to be at least one Identifier
    > known to operations staff which maps to a particular locator, but
    > there can be more.

I haven't read the full text of the latest version yet, but this (and I
don't know the whole context, maybe it's somehow less restrictive than it
sounds) caught my eye.

If identifiers and locators have a 1:1 relationship, a variety of things
become impossible (such as doing widespread smale-scale multihoming using
identifer<->locator bindings, with multiple locators bound to a single
identifier).

In fact, making that restriction removes much of the value of having
separate "locator" and "identifier" namespaces. If A is 1:1 to B, then you
can use A all the time, and having B around offers you no value.

The only exception to that observation would be if the binding can be
changed over time, while remaining restricted to 1:1 bindings. (So that
e.g. A could be bound to B at one point, and later A could be bound to C
instead.) That would at least support mobility.

Still, it's a very crippling restriction, and while it might have some
value in operational simplicity, one wonders if the cost in lost potential
functionality is not much higher than what it buys you.

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Jun 2007 09:19:50 +0200

below...

> functionality is not much higher than what it buys you.

Actually it's plain wrong, in that in IPv6, the same interface can have
multiple addresses anyway. I'll have to review the 01 text to be sure it's
OK, but most of the problems were in the 00 text.

    Brian