Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely

[[e-mail]]

 
I am pretty in line  with Iljitsch. I also think that it is  
feasonable/reasonable to have the new design in the middle. At least for an  introduction 
period.
When I would talk about 1-2 K FIB entries, I mean of course 1-2 K  
links,mainly loose links, the more remote, the looser,  however precisest in length. I 
would also call the  database "map-based". But because this is also a routing 
table, the  alternative should rather be called "prefix-based".
 
Same remarks about the current stage.
We have had a very long discussion about the dual nature id/loc.  We never 
had a discussion about strict/loose links. I mean  algorithmically  determined 
loose links.
We have adopted the term "stretch" but none of the current models  
(LISP,lvip,..) has anything to do with it. It takes  map-based models, as  to rate them 
by stretch values, doesn't it ? (I would claim stretch=1 for my  map-based 
concept of course :-)
 
Another fundamental point of discussion is: 
Shall a) the IP-header  serve the model or b) shall the model serve  the 
IP-header ?
We have seen that a) is possible (TOS converted to DSCP). Why not again  here 
!? 
 
In summary, it is too early to start with the finish.
 
Heiner  
 
In einer eMail vom 07.09.2007 13:27:10 Westeuropäische Normalzeit schreibt  
[e-mail]:

On  7-sep-2007, at 3:47, Noel Chiappa wrote:

>> From: Iljitsch van  Beijnum <[e-mail]>
>
>> The question is whether  it would be easier to replace it. So far, I
>> can't think of anyone  else other than myself speaking out in favor of
>> that, or even  entertaining the question seriously. :-)

> Really?  :-)

Dangers of caching: information from long ago may disappear  unless  
it's refreshed periodically.  (-:

>>  Obviously a new protocol would have to be able to interact with   
>> BGP and
>> be not much worse at talking BGP than a  native speaker.

> Well, "interact with BGP" and "talk BGP" sound  like two very  
> different things
> to me - unless by "talk  BGP" you mean "emulate a BGP speaker".

Yes, they are different things:  there is the protocol, which would be  
more or less independent from  BGP, and the implementation, which  
would almost certainly need to be  able to talk both the new protocol  
and talk to BGP speakers. Whether  this counts as emulating... don't  
know.

> The thing is  that if you have a system with a fundamentally  
> different  model
> of the world (e.g. map-based, instead of route-table based),  the  
> interface
> between it and BGP is necessarily going  to be something of a  
> kludge, and any
> emulation is  perforce going to be be something less than stellar.

At the very least  a new protocol would have to support the situation  
where the new  protocol is spoken in the middle and BGP both on the  
left and on the  right. Obviously the BGP speakers may at that point  
also interact  through regular BGP, e.g.:

BGP A -- New -- BGP B
\       /
BGP C

(Where "new" may be one or more ASes running the new  protocol.) So  
the new protocol must be able to emulate BGP  processing so well that  
it allows A and B to make (almost) identical  decisions as in the case  
where there was no new protocol. For  instance, AS paths must be at  
least retained and probably be added  to as information travels  
through the new protocol. It gets even  more interesting when two  
clouds speaking the new protocol are  separated by a BGP cloud.

I don't think an internet-wide map based  protocol is feasible, unless  
aggregation is so draconian that the  protocol itself becomes largely  
irrelevant and operators will mostly  be dealing with traffic  
engineering exceptions rather than the  protocol itself. A system  
where there is a map of the "center" of  the network (as seen from a  
given vantage point) where mapping  to/from prefix tables happens at  
the edges of the map would be very  interesting.

_______________________________________________
RAM  mailing  list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram







   

_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram