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

Iljitsch van Beijnum <iljitsch@muada.com> Fri, 07 September 2007 11:26 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITbz9-00017G-4p; Fri, 07 Sep 2007 07:26:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITbz7-00017A-Vn for ram@iab.org; Fri, 07 Sep 2007 07:26:49 -0400
Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITbz6-0005uW-GE for ram@iab.org; Fri, 07 Sep 2007 07:26:49 -0400
Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l87BMqFh023789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Sep 2007 13:22:57 +0200 (CEST) (envelope-from iljitsch@muada.com)
In-Reply-To: <20070907014744.773DF872F3@mercury.lcs.mit.edu>
References: <20070907014744.773DF872F3@mercury.lcs.mit.edu>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <CF896403-4EFF-4EB0-A8D1-E03BD7B83854@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely
Date: Fri, 07 Sep 2007 13:25:15 +0200
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

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

>> From: Iljitsch van Beijnum <iljitsch@muada.com>
>
>> 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
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram