The referred presentation asks: Is loc/id-split the solution ? (  to be fair, 
Dino never claimed that LISP is the clean-slate solution)
 
The problem is that the so-called loc/id-split discussion was  just to create 
the aroma for the, by two steps hopping,  LISP. The documents use the term 
"topological aggregatable addresses" but  mean  topologically non-aggregatable 
data (better said:wears the feathers  of topology aggregation but serves a 
model which is to prevent topology  aggregation). The term "loc" is used for 
RLOC-addressing, i.e. for something  which is certainly NOT "location". The 
term 
"loc/id-split", emphasizing "split",  is misleading too.  If you want to get 
rid 
of the nasty scalability problem  you must ADD (!!!) LOCATION !!! Yes ADD, 
not split (there hasn't been any  location information yet). Yes LOCATION, not 
something else.Ok, there may be  reasons for splitting i.e. making a clean cut 
between network layer and  transport layer, but this is a different animal and 
 shouldn't be mixed up  with solving a network layer internal problem. 
Instead, this is a transport  layer internal problem, and should be discussed 
THERE 
!  Well, so far  I mentioned so many results of TARA (getting rid of the 
update churn as well as  of the table size problem, making the IPv4 address 
depletion a non-issue,...).  Maybe I should add, given that routing were done 
based 
on location,  that  TCP identification can stay as it is, even in case of  
multihoming or mobility (roaming). And there are still more advantages  
compared 
with today's inter- domain and also intra-domain routing.
 
I just wonder how the RRG discussion runs. Hereby I learnt to know the term  
"non-starter" (and therefore had to improve TARA as to avoid incremental  
deployability problems). Really, I would never have dared to offer a  solution 
which depends on renumbering. 
 
Heiner
 
 
In einer eMail vom 30.10.2008 15:55:00 Westeuropäische Normalzeit schreibt  
[EMAIL PROTECTED]:

http://www.1-4-5.net/~dmm/iteotwawki-ipam-mraws3.pdf

Dave


_______________________________________________
rrg mailing  list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg




_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg

Reply via email to