Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely
HeinerHummel@aol.com Fri, 07 September 2007 13:07 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 1ITdY5-000174-I4; Fri, 07 Sep 2007 09:07:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdY5-00016j-6I for ram@iab.org; Fri, 07 Sep 2007 09:07:01 -0400
Received: from imo-m22.mx.aol.com ([64.12.137.3] helo=imo-m22.mail.aol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITdY3-00006L-Uo for ram@iab.org; Fri, 07 Sep 2007 09:07:01 -0400
Received: from HeinerHummel@aol.com by imo-m22.mx.aol.com (mail_out_v38_r9.2.) id z.c96.1874f3a2 (65100); Fri, 7 Sep 2007 09:06:45 -0400 (EDT)
From: HeinerHummel@aol.com
Message-ID: <c96.1874f3a2.3412a6e4@aol.com>
Date: Fri, 07 Sep 2007 09:06:44 -0400
Subject: Re: [RAM] Number of DFZ routers - radical improvement of BGP unlikely
To: iljitsch@muada.com, jnc@mercury.lcs.mit.edu
MIME-Version: 1.0
X-Mailer: AOL 9.0 VR sub 27
X-Spam-Flag: NO
X-Spam-Score: 2.1 (++)
X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d
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>
Content-Type: multipart/mixed; boundary="===============1003761416=="
Errors-To: ram-bounces@iab.org
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 iljitsch@muada.com: 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
_______________________________________________ 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