In einer eMail vom 22.09.2008 15:41:56 Westeuropäische Normalzeit schreibt  
[EMAIL PROTECTED]:

Brian  wrote:
|I fully agree, and what I'm suggesting is that the (sad) history  of
|the initial success of CIDR followed by the recent backsliding  which
|I call "the PI heresy" shows us that economics will always 
|tend  to create
|a swamp, so we'd better engineer the system for a swamp. And  
|in a swamp,
|any benefit from aggregation is both limited and  unpredictable. (Would
|anybody like to predict the effect of the collapse  of the US financial
|system on BGP4 aggregation two years from  now?)


Do you really mean that? Are you really suggesting that we  engineer routing
for 2^48 prefixes? 


|True. But that is, to use  the technical term, a crap-shoot, just as
|BGP aggregation of adjoining PI  prefixes is a crap-shoot. It will
|be the exception rather than the rule;  that's the nature of a swamp.
|There are no natural economic forces that  provide incentives for
|aggregation.


True. The alternative is  for us to remove the incentives to deaggregate (as
best we can) and then to  restrict things so that people can't hurt the
system.

And the right alternative is to do forwarding without any address prefix  
dependency at all, see also my previous emails.
 
Heiner
 



|So I stick to my guns: we need to map the edge-swamp into a  
|significantly
|smaller core-swamp, or nothing will change. Relying on  aggregation at
|the edge hasn't worked for BGP, so why should it work for  any form
|of EID/RLOC mapping (regardless of terminology)?


I'd  argue that if there's a core swamp, you've already failed to  scale.

Tony







   
--- Begin Message ---




-------- Kabel E-Mail Forward ---------------
From: [EMAIL PROTECTED]
To : [EMAIL PROTECTED];[EMAIL PROTECTED]
Date: 18.09.2008 19:37:46


More catch up... 

Brian wrote:
|I fully agree, and what I'm suggesting is that the (sad) history of
|the initial success of CIDR followed by the recent backsliding which
|I call "the PI heresy" shows us that economics will always 
|tend to create
|a swamp, so we'd better engineer the system for a swamp. And 
|in a swamp,
|any benefit from aggregation is both limited and unpredictable. (Would
|anybody like to predict the effect of the collapse of the US financial
|system on BGP4 aggregation two years from now?)


Do you really mean that? Are you really suggesting that we engineer routing
for 2^48 prefixes? 


|True. But that is, to use the technical term, a crap-shoot, just as
|BGP aggregation of adjoining PI prefixes is a crap-shoot. It will
|be the exception rather than the rule; that's the nature of a swamp.
|There are no natural economic forces that provide incentives for
|aggregation.


True. The alternative is for us to remove the incentives to deaggregate (as
best we can) and then to restrict things so that people can't hurt the
system.


|So I stick to my guns: we need to map the edge-swamp into a 
|significantly
|smaller core-swamp, or nothing will change. Relying on aggregation at
|the edge hasn't worked for BGP, so why should it work for any form
|of EID/RLOC mapping (regardless of terminology)?


I'd argue that if there's a core swamp, you've already failed to scale.

Tony


--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: & ftp://psg.com/pub/lists/rrg

--- End Message ---

Reply via email to