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