Subject: Re: [RAM] Terminology: ID/Locator split

From: [email-masked]
Date: Fri, 2 Mar 2007 11:25:37 EST

"Addressing can follow topology or topology can follow addressing.  Choose 
one."
Jakov's law. We had such discussion before. Maybe we should get back to it  
again?
 
Heiner
 
In einer eMail vom 02.03.2007 16:29:57 Westeuropäische Normalzeit schreibt  
[email-masked]:

We agree  completely.

Brian

On 2007-03-02 15:01, RJ  Atkinson wrote:
> 
> On  2 Mar 2007, at 03:59, Brian E  Carpenter wrote:
>> I've already expressed my concern that the word  "split"
>> is wrong in itself for many of the solutions  being
>> considered.
> 
> Agreed.
> 
>>  What we have in reality today are context-
>> dependent locators,  which in some contexts are used as
>> identifiers for transport,  security, applications or network
>> management.
> 
>  Agreed.
> 
>> The question really is whether we  embrace
>> this architecturally (which shim6 and lisp both  do)
>> or whether we try to change it by abolishing the
>>  context dependency (which is what a true split would
>> do).
>  
> I don't think LISP does.  As near as I can tell,
> LISP  separates the routing space into 2 distinct
> pieces -- so to me LISP  looks like a "Multiple Locator"
> solution rather than a  "Identifier/Locator Split".
> 
> In particular, with LISP the  transport session state
> still includes location information (albeit  not all
> of the location information), which seems to  disqualify
> it from the "ID/Locator Split" category.
> 
>  As I've said in other notes, I don't think that the solution
>  necessarily requires a strict "ID/Locator Split".  I do
> think  that clear conversation is assisted by being crisp
> and clear in how  one describes various proposals' architectural
> approach.
>  
> Thanks,
> 
> Ran
>  

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

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

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 3 Mar 2007 18:59:04 -0500

> Would you say if IDs were from PI space and
> not injected into the routing system, we then have a true split?

No.  The key distinction for "ID/Locator Split" as a term
is how the object is used in a layering sense (e.g. network-layer
XOR transport-layer), rather than whether something
is IGP data or EGP data.

If IDs are not used for network-layer packet forwarding,
then one has a true split.  Having a true split means
(roughly) that one Identifier is never used in any
network-layer routing and that transport-layer state
(e.g. TCP pseudo-header checksum) does not include
any sort of name used for network-layer packet forwarding.

If one had an Identifier, not used for packet forwarding,
but used in TCP pseudo-header calculations, I think
it would still qualify as a true split even if that
Identifier were used as part of an ARP/ND *cache index*.

> Dino
>
> P.S. Modulo site-based routing on the ID.

LISP is very interesting, but is NOT a true ID/Locator split.
Instead, I'd say one has multiple Locator domains or
multiple routing domains with LISP.

And to repeat my earlier comment, I don't think that a
true ID/Locator split is *required* to solve the issues
that this list has been discussing.  So I think it would
be cleaner, clearer, and more advantagous for LISP itself
if folks did not refer to LISP as an ID/Locator split
approach.

Ran

---

From: [email-masked] (Noel Chiappa)
Date: Sat, 3 Mar 2007 20:23:30 -0500 (EST)

> From: RJ Atkinson <[email-masked]>

    > The key distinction for "ID/Locator Split" as a term is how the
    > object is used in a layering sense (e.g. network-layer XOR
    > transport-layer), rather than whether something is IGP data or EGP
    > data.
    > If IDs are not used for network-layer packet forwarding, then one has
    > a true split.

That's an interesting way to classify it, because it points out what made
me so uneasy about a scheme you mentioned a while back (Jan 16 2007,
Subject: "Candidate properties of some new name types", if anyone cares),
where you suggested:

  "A Locator names a single sub-network, not an interface or node"

and I was rather unhappy, because perforce this meant that the other name of
the pair you suggested (an "Identifier") was therefore necessary to identify
the particular interface; i.e. that "Identifier" name was used at the
internetwork layer as well as the transport layer. (If the packet *cannot* be
delivered by the internetworking layer *without* use of the Identifier, the
Identifier is [in part] an internetworking-level name.)

Oh. and while we're at it on the subject of terminology, can I convince
everyone to use "internetwork layer" when they mean the internetworking
layer, because "network layer" is really confusing on networks like ATM,
etc which have a real network layer of their own. Just because the ISO
model is crippled and doesn't have enough layers, that doesn't mean we have
to swallow it lock, stock and barrel.

    > Instead, I'd say one has multiple Locator domains or multiple routing
    > domains with LISP.

This claim makes no sense to me at all. LISP is a jack-up scheme, and in
all jack-up schemes the end-end identification functionality stays with the
upper "internetwork" layer. So there's no way the top namespace is a true
locator, because it still has the end-end naming functionality. There's
simply no way anything called a "locator" can have *any* end-end naming
functionality.

Sure, in the long term, it would be good to migrate that end-end naming
functionality off to yet another namespace, but as long as we're trying to
maintain backward compatability with IPv4, we are going to have some ugly
kludges...

    > I think it would be cleaner, clearer, and more advantagous for LISP
    > itself if folks did not refer to LISP as an ID/Locator split approach.

This debate seems particularly sterile. It is what it is (and see previous
comment about "backward compatability with IPv4").

	Noel