Subject: Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?

From: [email-masked]
Date: Sun, 24 Jan 2010 18:50:31 EST

In einer eMail vom 24.01.2010 20:47:40 Westeuropäische Normalzeit schreibt  
[email-masked]:

However,  LISP is still not a new routing architecture - which I claim we 
will
still  need, when all the dust settles. And _none_ of the proposals here  
(well,
the Compact Routing stuff comes closest) is a new routing  architecture....

Noel

Indeed none of the submitted proposals. But it is also true that all kind  
of arguments are used to fight a new routing architecture such as TARA.
TARA-goals: 
1)Scalability:
Table size: 64800 entries (1 per geopatch) + 3600 meta-table entries + n  
times 60 entries (in the worst case) with n TARA-routers inside the own  
geopatch
Update churn: tending to zero.
The scalability issue will be eliminated once and forever
2) Multicast to millions of receivers (imagine TVoIP of the opening  
olympique celebration to hundred millions of receivers - admitted, TARA  would be 
the basis, a better than today's MC is needed (and could be  developed), too 
3)Traffic engineering:
Enables all kind of detouring Multipath (not just ECMP) while  
recongizing,any dead-end path.
Enables congestion handling for  all kind of streams, in particular  voice 
and live-TV streams whose transmission rates cannot be  slowed down, based 
on a communication between the congested and the respective  upstream 
neighbor network.(i.e. provides a rearview mirror)
Enables time-of-day routing.
Abolishes loops.Would overcome the TTL-mechanism which appears to be a  
relict from the stone age.
4) Mobility:
Enables  Mobility  solutions without a home agent or rendez-vous  server.
Well scoped ANYWHERE-cast using well-scoped broadcast mechanism (better  
than  flooding)
Hence will certainly enable services which are still unknown today
5) Moore's Law: Will increase the speed of the next hop retrieval by factor 
 20 i.e. enable Moore's law applicability - even in cases where the best 
next hop  is be replaced by some other (e.g. detouring) next hop.
6) Will enable stretch-1 and disable the Istanbul-effect
7) Clean slate:
Will overcome the orthogonality between intra- and inter-domain  routing.
Will overcome the either-or thinking between network-based versus  
user-based
8)Multihoming:
Enables Multihoming (just like all the other proposed solutions)
9) Enables Multi-addressing (IPv4, IPv6 just like LISP, eventually more:  
HIT, names, E164 without enum ?! )
   because the transit router uses the TARA-locator, doesn't look  at the 
other address;
10) Eliminates the IPv4 depletion issue, because of 7): IPv4 must be  
locally unique only. PI or PA? All are PI effectively.
11) Provides a strategy for incremental deployment
 
12) Provides a new realm for working on IP technology in the future.

However many do not want a new routing architecture. I can see this by  the 
critiques I have received so far: Best example: the partitioning argument.  
Or do not  acknowledge that TARA is a new routing architecture
(e.g. by comparing it with GIRO or metro-based routing)
 
Heiner

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 25 Jan 2010 11:49:58 -0500 (EST)

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

    >> LISP is really intended to achieve one chief goal: to split up
    >> location and identity

    > (Insert repeat of arguments about "identity", and how LISP separates
    > global from local routing, here.)

(Insert repeat of arguments about how LISP Mobile Node stuff shows examples
of where a LISP EID has _no_ location semantics, and how as long as you have
un-modified legacy hosts, you can't do a total 100% clean separation. :-)

    > The just-in-time ugly Internet.

Yes... installed base, the Architect's Bane! :-)

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 26 Jan 2010 12:17:41 -0500 (EST)

> From: Patrick Frejborg <[email-masked]>

    > In the future core-edge split architecture the enterprise can have
    > PI-addresses ... If the future core-edge split architecture encourages
    > the usage of PI addresses, that would be a carrot for the enterprises
    > to migrate, wouldn't it?

Perhaps we are having a problem caused by your use of the term "address",
which does not seem (see below) to mean what I usually take it to mean.

(I really wish we could just stop using the term "address", because it means
so many different things to different people...)

To me, although there are apparently many different definitions for
"address", they almost all share one common attribute: that they are used by
the path-computation process. So in saying something is an "address", one is
implicitly saying 'this will be injected into the routing'.

Furthermore, "PI" means 'does not contain any information on location', i.e.
it not local to one particular scope, i.e. its scope (i.e. the part of the
network over which it must be advertised) is global.

So now we have "PI address" meaning 'something which has to be injected into
the routing, and must be visible over a global scope'.

So how is it that these 10 million (or however many companies it is) can all
have "PI address[es]"? I am sort of forced to the conclusion that what you
mean by the phrase "PI address" is something different, perhaps some sort of
identifier which is _not_ injected into the routing?

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 26 Jan 2010 13:33:32 -0500 (EST)

> CES is all about taking out the multi-homed PI addresses from the DFZ -
    > transforming them into PA-addresses (RLOCs, which are aggregated) and
    > provide a multi-homing solution for IPv6 so it will not further expand
    > the size of DFZ.

Exactly - except it's not just multi-homing, separating locatiom from
identity allows us to do many other things too - e.g. portability, mobility,
etc.

	Noel