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
- Re: [RAM] Number of DFZ routers - radical improve… Noel Chiappa
- Re: [RAM] Number of DFZ routers - radical improve… Iljitsch van Beijnum
- Re: [RAM] Number of DFZ routers - radical improve… HeinerHummel
- Re: [RAM] Number of DFZ routers - radical improve… Noel Chiappa
- Re: [RAM] Number of DFZ routers - radical improve… HeinerHummel