Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Jeffrey Haas <jhaas@nexthop.com> Tue, 04 May 2004 19:04 UTC
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21475 for <idr-archive@ietf.org>; Tue, 4 May 2004 15:04:47 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL5Dk-0001On-L2 for idr-archive@ietf.org; Tue, 04 May 2004 15:04:48 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL5Cn-0001JN-00 for idr-archive@ietf.org; Tue, 04 May 2004 15:03:50 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL5CZ-0001Dw-00; Tue, 04 May 2004 15:03:35 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL57C-00076f-37; Tue, 04 May 2004 14:58:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL549-0006Mc-Kt for idr@optimus.ietf.org; Tue, 04 May 2004 14:54:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20785 for <idr@ietf.org>; Tue, 4 May 2004 14:54:50 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL546-0000Mz-Qo for idr@ietf.org; Tue, 04 May 2004 14:54:50 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL53F-0000Ef-00 for idr@ietf.org; Tue, 04 May 2004 14:53:58 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BL52J-0007lW-00 for idr@ietf.org; Tue, 04 May 2004 14:52:59 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B3B962D4826; Tue, 4 May 2004 14:52:29 -0400 (EDT)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 62758-01-48; Tue, 4 May 2004 14:52:18 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 35DB42D4804; Tue, 4 May 2004 14:52:18 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i44IqIv05317; Tue, 4 May 2004 14:52:18 -0400 (EDT)
From: Jeffrey Haas <jhaas@nexthop.com>
To: "Howard C. Berkowitz" <hcb@gettcomm.com>
Cc: idr@ietf.org
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Message-ID: <20040504145218.G4638@nexthop.com>
References: <20040504114849.230.qmail@web60704.mail.yahoo.com> <Pine.LNX.4.44.0405041757060.4273-100000@netcore.fi> <20040504111830.C4638@nexthop.com> <p05100318bcbd8be8bfa0@[192.168.0.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05100318bcbd8be8bfa0@[192.168.0.2]>; from hcb@gettcomm.com on Tue, May 04, 2004 at 02:13:40PM -0400
X-Virus-Scanned: by amavisd-new at nexthop.com
Sender: idr-admin@ietf.org
Errors-To: idr-admin@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Tue, 04 May 2004 14:52:18 -0400
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Note: I haven't been doing this stuff anywhere near as long as some of the members of this forum. This said, here is my opinion based on some second and third hand stories. On Tue, May 04, 2004 at 02:13:40PM -0400, Howard C. Berkowitz wrote: > In my experience, newbies better understand all of the scalability > methods if one adds the idea of the "classic" or "historic" RsD-style > route server as an _e_BGP scalability technique. SO to come back to > Jeff's comment, a route server replaces/reduces full eBGP mesh at > exchange points. In the beginning of the Internet, route servers served a useful role in reducing the routing table traffic load on the hosts at an exchange point to levels within the capacity available to the boxes at the time. Apparently, the window of time where this was necessary was "reasonably small". When routers were deployed that could handle the number of eBGP views at a typical exchange point, the route servers were only useful (for route reduction purposes) for protecting smaller boxes. I think it is likely today that most exchange points will typically find boxes deployed that are capable of handling the relevant full or partial mesh that the business model that XP operates under can use. The route servers often caused more problems than they were worth in environments where reachability to the route server didn't imply reachability to the actual router advertising the routes. In the era when boxes are thought to be capable of handling a pretty serious routing load, the route server model excels at one thing - proxying policy. "I ask for X set of destinations, I only want to send you Y destinations". Configure it in a database, run RtConfig and let it rip. Nothing stops a bgp speaker from doing similar things with RtConfig at their edges. However, when you start doing it for a reasonable number of peers, your policy tends to get huge. Some boxes deal with huge policy better than others. If you wish to contemplate how route servers scale, remember that a route server is much the same case as a 2547 PE router. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr
- RFC1863 to historic? [Re: [Idr] Last Call on draf… Pekka Savola
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Jeffrey Haas
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Robert Raszuk
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Jeffrey Haas
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Tulip Rasputin
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Jeffrey Haas
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Pekka Savola
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Kurt Erik Lindqvist
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Jeffrey Haas
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … John G. Scudder
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Howard C. Berkowitz
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Howard C. Berkowitz
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Jeffrey Haas
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Curtis Villamizar
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Paul Jakma
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Kurt Erik Lindqvist
- Re: RFC1863 to historic? [Re: [Idr] Last Call on … Kurt Erik Lindqvist