Re: [Idr] draft on virtual aggregation
Paul Francis <francis@cs.cornell.edu> Thu, 17 July 2008 17:11 UTC
Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id AAAA93A6B19;
Thu, 17 Jul 2008 10:11:20 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4EA3D3A6B19
for <idr@core3.amsl.com>; Thu, 17 Jul 2008 10:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.343
X-Spam-Level:
X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[AWL=0.256,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 8XFVvojxfL-u for <idr@core3.amsl.com>;
Thu, 17 Jul 2008 10:11:17 -0700 (PDT)
Received: from exch-hub2.cs.cornell.edu (mail-hub-2.cs.cornell.edu
[128.84.103.139])
by core3.amsl.com (Postfix) with ESMTP id 43BF83A6B05
for <idr@ietf.org>; Thu, 17 Jul 2008 10:11:17 -0700 (PDT)
Received: from EXCHANGE1.cs.cornell.edu (128.84.96.42) by
mail-hub.cs.cornell.edu (128.84.96.245) with Microsoft SMTP Server id
8.0.813.0; Thu, 17 Jul 2008 13:11:47 -0400
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by
EXCHANGE1.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.3959);
Thu, 17 Jul 2008 13:11:47 -0400
Content-Class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 17 Jul 2008 13:11:45 -0400
Message-ID: <37BC8961A005144C8F5B8E4AD226DE1109D916@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <487CCCCB.6060201@juniper.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft on virtual aggregation
Thread-Index: AcjmliJpGyBGN5MmTcif+A6CLzlIQwBk759Q
References: <200807151426.m6FEQ2gC032246@harbor.brookfield.occnc.com>
<487CCCCB.6060201@juniper.net>
From: Paul Francis <francis@cs.cornell.edu>
To: <raszuk@juniper.net>,
<curtis@occnc.com>
X-OriginalArrivalTime: 17 Jul 2008 17:11:47.0474 (UTC)
FILETIME=[31FC1F20:01C8E830]
Cc: idr@ietf.org
Subject: Re: [Idr] draft on virtual aggregation
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org
Questions/comments inline: > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@juniper.net] > Sent: Tuesday, July 15, 2008 12:14 PM > To: curtis@occnc.com > Cc: Paul Francis; idr@ietf.org > Subject: Re: [Idr] draft on virtual aggregation > > Hi Curtis, > > > Idr should not be adding a hack for small gain in FIB size when > better > > techniques exist and products already exist with quite a few binary > > orders of magnitude headroom. > > This is not a hack. In fact all what this is about can be accomplished > today by sitting down and configuring three routers: edge, lookup > router > and egress (an option). Are you saying here that no router modifications are needed to make this work? > If someone really want to divide the addressing > space as Paul suggest marking can be reg community. This is provider > contained solution - it does not cross any inter-as boundaries. I'm not sure what you mean by "marking can be reg community". Can you expand a bit? > > All this document attempts to is present such option for operators. > Some > may find them useful some may not. I'm concerned that the folks that may find them useful (lower-tier ISPs) aren't typically involved in IDR or IETF for that matter. If there are folks listening who can speak for lower-tier ISPs, please do so. (My knowledge here, such as it is, is all second- or third-hand.) > > Moreover there are other then edge FIB scaling real operational > benefits > for such solutions ... to name one I want to point at very fast > reachability restoration in the event of failure. > > To meet customer's and today's applications requirements one can forget > about hop by hop switching, sending withdraws network wide, re- > propagate > new best paths etc ... That is gone model. For all of this fast restoration stuff, I gather you are thinking in terms of the core-edge structure that most (all?) tier-1 ISPs have? Is your point that simply shrinking the number of routers that have to participate in re-routing will help scale ASBR/PE failure detection, and that we don't need explicit new mechanisms along these lines (i.e. BGP Virtual Link Attribute)? PF > > To meet such requirements requires to store backup paths for all > destinations in FIB ahead of any failure + make sure that such router > have very fast failure detection scheme. Every one could see that the > less routers are configured with accelerated restoration features it > scales much better ... or it allows for much faster OS upgrades on such > boxes vs running around and upgrading all edge boxes. > > Imagine also vast reduction in number of BFD sessions if someone would > choose to use this technology for ASBR/PE failure detection. > > Another one assuming that we would go one step fwd and remove RIB from > the edge and just fully mesh those couple of IP lookup routers any > problems with oscillations are history as well as vast reduction in > intra-as triggered BGP instabilities. > > For the FIB reduction indeed small/mid size ISPs or enterprise networks > may benefit. > > But for not directly mentioned in the draft benefits of moving to > schemes which reduces the number of FIB lookup routers in the network > many ISPs may be interested. And indeed I would like to hear their > opinion on the list on that. > > Cheers, > R. > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
- [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Curtis Villamizar
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Curtis Villamizar
- Re: [Idr] draft on virtual aggregation Curtis Villamizar
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Rajiv Asati (rajiva)
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Rajiv Asati (rajiva)
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Rajiv Asati (rajiva)
- [Idr] Latest draft of FIB suppression Paul Francis