Subject: Re: [rrg] Map and Encaps

From: [email-masked]
Date: Wed, 10 Dec 2008 04:11:46 EST

In einer eMail vom 09.12.2008 21:41:59 Westeuropäische Normalzeit schreibt  
[email-masked]:

I've  said this from the beginning but I'll try once more: I get much
less  confused about LISP if I use different terminology, because the
LISP "EID"  is not an EID. Think of it as a local locator (which also
happens to be  globally unique) and call it LOC0 for example. Then the
LISP "RLOC" is a  less local locator that just happens to be globally
routable as well as  globally unique; call it LOC1 for example. As HAIR
points out (and I  pointed out last year) the obvious conclusion is a
recursive model with any  number of layers of locator scope.

GSE/ILNP and HIP are deeply  different in that they genuinely separate
a unique *non-locator* ID from  one or more locators. Trying to use the
phrase "loc/id split" to cover both  of these models is certain to
lead to confusion.

Brian
Brian,
It is a general problem that problems are being delt with by  using not 
adequate language.
I guess I am the only one who pursues location based routing rather than  LOC 
based routing.
 
Or: Topology aggregating addressing. This term is - according to my  
impression - used for PA addresses !!:-(
 
Or  look at the root cause in the strategy overview list: 
 
The root cause of the routing table growth problem is that we're using the  
same element (IP address) to express three distinct concepts:  
    1.  the globally unique identity (GUID) needed by the originating client  
system to find the destination server,  
    2.  a component of the session identity (SID) used by the layer 4 and 
higher  protocols to keep track of communications with other hosts, and  
    3.  the node's present location or locations (LOC) within the network  
topography. 

Show just these 3 points to the smartest but non-IETF human being on earth:  
If he/she concluded: "ooops, you must have a severe scalability problem" then 
I  will humble withdraw my critic that this 3-folded-ness is
rather defusing than clarifying the root cause.
 
Heiner
 
Heiner
 
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked]
Date: Tue, 16 Dec 2008 15:44:41 EST

In einer eMail vom 16.12.2008 20:02:33 Westeuropäische Normalzeit schreibt  
[email-masked]:

I  really thought deserved a substantial reply...>

>  From: "Fleischman, Eric" <[email-masked]>
> Date: Mon, 1 Dec 2008 10:45:43 -0800

>  Map-and-encaps shields the host from knowing the actual network
> topology such that an arbitrarily complex network topology can  be
> created that is transparent to the end user  host

This is also true of the existing internetwork layer, though...  It's an
interesting point as to whether this is a correct architectural  choice, or
whether some applications want/need to be _able_ to see more  (i.e. it would
not be mandatory, and those applications which didn't need  it could/would
continue in blissful ignorance, just as most applictions now  don't care about
virtual memory) - but that's not the main point I want to  go over here, so
I'll pass on, and leave that for another  day/thread.

Promise: By TARA each DFZ router would get a view of the entire internet  
which is a) good enough to determine the best next hop, b) which would  hardly 
encompass more than 2000 links. 
 
The amount of the respective data is so little that in case "some  
applications want/need to be _able_ to see more"   the  multihomed user might request 
the respective internet topological view from  each of its  DFZ routers for 
being evaluated/compared as to make the  right decision from the application's 
point of view.
 
It is no secret: If your basic architecture needs very little wrt to memory  
and/or time (like at most 3 table offsets) then more sophisticated 
applications  will only require a multi-fold of just these very small numbers.
 
Concurrently, it becomes easily affordable to provide everything for a 100  % 
multipath capability (i.e. both from the memory and performance  prospective)
 
Heiner