Re: A tunneling proposal

["Michel Py" <michel@arneill-py.sacramento.ca.us>]

My opinion it that it all comes to this: If we thought that multihoming
the way it is currently done was good, this working group "multi6" would
not exist to begin with. I think the purpose of this workgroup is not to
reproduce the existing situation but rather fix it.
 
My $0.02
Michel.
 
-----Original Message----- 
From: Tony Li 
Sent: Tue 7/17/2001 1:30 PM 
To: Iljitsch van Beijnum 
Cc: RJ Atkinson; multi6@ops.ietf.org 
Subject: Re: A tunneling proposal




	 | > >> Modern routers don't fall over with 100,000 routes in
them.  But
	 | > >> initial table load and BGP convergence times when paths
change are
	 | > >> both a lot longer than many would like.
	 |
	 | > >Ok, but is that enough reason to throw out the current way
of
	 | > >multihoming?
	 |
	 | >         Yes.
	 |
	 | Well, I disagree. Slow initial sync and convergence times are
bad, but
	 | outlawing current multihoming is very bad as well. And I'm
certaintly
	 | not convinced this is well-optimized. Not much is.
	
	
	You are welcome to disagree.  However, the facts of the matter
are very
	clear.  If the Internet is to grow, it will continue to add
'sites' to it,
	almost indefinitely.  Some percentage of those sites will want
to
	multihome.  Under the current multihoming architecture, those
sites will
	appear in the DFZ routing table.  If the growth rate of those
sites exceeds
	Moore's law, then it will be become exceedingly expensive to
support the
	routing subsystem.
	
	It is vital to the life of the net that the routing subsystem
continue to
	scale well.  The price of this scalability is the discipline to
adhere to
	a scalable architecture.
	
	Are you willing to pay that price?
	
	
	 | > >> The size of individual routing state entries in modern
routers has
	 | > >> been the subject of a great deal of optimization over
the years.
	 | > >> Don't expect to see it improved by an order of magnitude
or even by
	 | > >> a factor of two.
	 |
	 | > >Really?
	 |
	 | >         Yes.
	 |
	 | So how does this relate to my experience that the amount of
memory used
	 | by BGP table entries is the same as six years ago?
	
	
	Your experience does not match mine.
	
	
	 | > >Do we have any inidication that the global routing table
is growing
	 | > >faster than the Moore's Law rate?
	 |
	 | > As I recall, tli has made precisely this claim in the past.
I'm
	 | > strongly inclined to just take tli's word on such a point.
	
	
	To be 100% accurate: I made the point that the rate of growth is
increasing
	and that if left unchecked, this implies that the growth will
someday
	exceed Moore's law.
	
	
	 | I'm not even talking about economics, but just basic
functionality and
	 | human nature: how are you going to convince someone stop
doing something
	 | that works for them to help some greater good, that doesn't
show obvious
	 | signs of needing help? "Global warming? Let me turn up the
airco..."
	
	
	We're well aware that we have a tragedy of the commons scenario.
The first
	step has to be to convince you that the IPv6 routing
architecture needs to
	be something scalable.
	
	
	 | If there really is a limit above which global routing breaks
down, we
	 | should implement some policies to prevent the number of
routes from
	 | reaching this limit. This means forcing existing ASes to
aggregate, and
	 | limiting the growth in the number of ASes. That way,
SCTP-like solutions
	 | become more attractive.
	 |
	 | But I think we can:
	 |
	 | 1. optimize protocols
	
	
	This has been in progress for 8 years.
	
	
	 | 2. optimize implementations
	
	
	This has also been in progress for 8 years.
	
	
	 | 3. look for alternative ways to aggregate, for instance on
geography
	
	
	Local geographic aggregation (i.e. metro aggregation) has issues
about
	forced connectivity that we are not able to regulate.  Global
geographic
	aggregation (i.e., at the continental scale) has been struck
down as a bad
	idea.
	
	If you ignore history, you're doomed to repeat it.  Just like
this
	conversation.
	
	Tony