Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP)

From: [email-masked] (Noel Chiappa)
Date: Tue, 17 Apr 2007 10:13:01 -0400 (EDT)

> From: Yakov Rekhter <[email-masked]>

    >> My guess is that the architectural commonality between LISP
    >> 1/1.5/etc and the eventual deployed stuff is likely to be:
    >> ..
    >> - End-end names are mapped into new locators as they cross the
    >> boundary

    > What you called "end-end names" are not really "end-end names" but
    > locators.

In the current "classic" IPvN architecture, yes, the end-end names are also
locators. In LISP:

    > It just the scope of these locators is not the whole Internet.

The end-end names in LISP are also locators with local scope, it is true.
However, they are *principally* end-end names.

And as I said a while back (to Ran Atkinson, if memory serves), over time,
it's possible that the LISP mapping function would move closer and close to
the hosts, which would mean that the scope of those locally-significant
locators would get smaller and smaller. The limit of this process is clear:
is a "locator" with zero scope really a locator?

All the while, their end-end naming function would remain unchanged, which
is why I think of them as *principally* end-end names.

	Noel

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Apr 2007 17:14:57 +0200

> is why I think of them as *principally* end-end names.

That's valid from a 10,000 meter Internet architect viewpoint. I suspect
that from the viewpoint of a repair technician at or slightly
below ground level, they would remain *principally* IP addresses,
as today. That's actually the beauty of LISP.

     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Apr 2007 09:35:51 -0700

> the hosts,

I have been saying this all along; once even to you, IIRC.

Fred
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Apr 2007 18:54:26 +0200

Hi Fred,
>
>> it's possible that the LISP mapping function would move closer and
>>     
>> close to the hosts,
>>     
>

It depends on what you mean, but in general I would view this as a bad 
thing.  Let's again discuss ETRs and ITRs separately.  If you wish to 
move the ETR function closer to the host then you must either advertise 
a more specific EID/prefix match, in which case you will explode the 
number of mappings (still not a good thing), or you will impose 
suboptimal routing if multiple interior ETRs advertise the same 
EID/prefix.  In the general case, there are only so many ways into and 
out of an end site, and so it's not clear what benefit you buy by moving 
these things toward the host, other than perhaps distributing the 
untunneling load, assuming the cost of doing so is huge to begin with (I 
do not believe it is).

ITRs are also best kept to a minimum, but it is less demanding on 
everyone else because we don't have to know about where you put your 
ITRs (although you still impose load in terms of determining the 
mapping).  Still, each ITR is going to need to play the mapping game.  
This means that either there is a predistributed and precomputed TIB, to 
borrow terminology from Juanjo, or you must reconstruct the entries 
realtime (or a mixture of both).  I think you want to do as little of 
that as possible, no matter which way you slice it.  It is true it would 
reduce your memory requirements on single devices, but it also adds 
complexity into your IGP which for most end sites is not there today.

The mapping function is again key here.

Eliot

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Apr 2007 11:39:27 -0700

> number of mappings (still not a good thing),

No; not more mappings. The mapping would still be to a site
border router for the destination's site, but the ETR could
be deeply embedded within the site. The way it would work is
that the encapsulated packets would be directed to a (globally
routable) locator for a site border router, but once the
packets reach the site they are forwarded to the ETR within
the site by routing on the identifier in the inner header.

Or, we could just leave the ETR at the site border routers
themselves or at some middlebox within the site; the choice
is up to the individual sites.

> or you will impose 

One benefit of locating the ETR close to the end system is
that the closer one gets to the end system the more it tends
to resemble true end-to-end.

> mapping).  Still, each ITR is going to need to play the 

Sure, and the ITR can do that even if it is co-resident on
the same physical platform as the end system.

> complexity into your IGP which for most end sites is not there today.

I don't follow this. IMHO, we can place the ITRs as close
to the end systems as we like - even on the same physical
platform as the end system - without incurring any scaling
issues.
 
> The mapping function is again key here.

Right, but we do have some candidates on the table.

Thanks - Fred