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 15:31 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 LAA08513 for <idr-archive@ietf.org>; Tue, 4 May 2004 11:31:32 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL1tO-0003WK-GP for idr-archive@ietf.org; Tue, 04 May 2004 11:31:34 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1sP-0003Op-00 for idr-archive@ietf.org; Tue, 04 May 2004 11:30:34 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL1rV-0003HW-00; Tue, 04 May 2004 11:29:37 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1o1-0003JC-Mp; Tue, 04 May 2004 11:26:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1j1-0001sJ-R6 for idr@optimus.ietf.org; Tue, 04 May 2004 11:20:51 -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 LAA07827 for <idr@ietf.org>; Tue, 4 May 2004 11:20:49 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL1j0-0002V0-MP for idr@ietf.org; Tue, 04 May 2004 11:20:50 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1hz-0002Qb-00 for idr@ietf.org; Tue, 04 May 2004 11:19:48 -0400
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1BL1hP-0002L3-00 for idr@ietf.org; Tue, 04 May 2004 11:19:11 -0400
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8E2C42D4879; Tue, 4 May 2004 11:18:41 -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 55586-01-99; Tue, 4 May 2004 11:18:30 -0400 (EDT)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3608C2D4869; Tue, 4 May 2004 11:18:30 -0400 (EDT)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i44FIUN04841; Tue, 4 May 2004 11:18:30 -0400 (EDT)
From: Jeffrey Haas <jhaas@nexthop.com>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Tulip Rasputin <tulip_rasputin@yahoo.ca>, idr@ietf.org
Subject: Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]
Message-ID: <20040504111830.C4638@nexthop.com>
References: <20040504114849.230.qmail@web60704.mail.yahoo.com> <Pine.LNX.4.44.0405041757060.4273-100000@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.44.0405041757060.4273-100000@netcore.fi>; from pekkas@netcore.fi on Tue, May 04, 2004 at 05:58:11PM +0300
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 11:18:30 -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

On Tue, May 04, 2004 at 05:58:11PM +0300, Pekka Savola wrote:
> Route collectors or route servers used for other debugging purposes 
> are an entirely different thing from route servers used to replace 
> iBGP mesh, right?

And an even stronger distinction:

If you're going to do iBGP mesh, a route reflector is usually a better
solution.

Route servers are generally designed to serve as route proxies to
create view-based policy.  At the least, this is the design for RSd.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr