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

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Sep 2007 18:46:36 +0200

[Sorry to again reply many weeks later]

On 7-jul-2007, at 3:42, Robin Whittle wrote:

> I can't imagine any
> backwards-compatible upgrade or incrementally deployable
> replacement for BGP could achieve the radical improvements I was
> hoping for.

> Maybe someone else will have some great ideas for dramatically
> souping up BGP.  BGP solves some very difficult problems.  I can't
> think of any drastic improvements.

That's an interesting challenge. As the saying goes: given enough  
thrust, pigs fly just fine. 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.  :-)

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.

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

---

From: [email-masked]
Date: Fri, 7 Sep 2007 09:06:44 EDT

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  
[email-masked]:

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

>> From: Iljitsch van  Beijnum <[email-masked]>
>
>> 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.

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 9 Sep 2007 22:25:28 -0400 (EDT)

> where the new protocol is spoken in the middle and BGP both on the left
    > and on the right.

Right, and if the fundamental concepts of the new design are very different
from those of BGP (e.g. it exchages maps, rather than routing table entries),
that translation, forwards and backwards, could be rather tricky.

    > It gets even more interesting when two clouds speaking the new protocol
    > are separated by a BGP cloud.

Now you're either i) limiting the new system to having the capabilities of
BGP (in which case, you lose a lot of the point of doing something new), or
ii) you have to accept that two such discontiguous regions of New Stuff
simply don't get all the benefits of New Stuff until they somehow manage to
connect directly.

    > I don't think an internet-wide map based protocol is feasible

We will have to agree to differ... :-)

    > 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.

It happens that map-based system are ideally suited to building systems where
eveyone has a different view of the network...

	Noel

---

From: [email-masked]
Date: Mon, 10 Sep 2007 05:00:36 EDT

> are separated by a BGP  cloud.

that would be l'art pour l'art, but makes no sense - IMHO
 
Heiner