Re: [Idr] draft on virtual aggregation
Robert Raszuk <raszuk@juniper.net> Tue, 15 July 2008 16:16 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 9B20728C25F; Tue, 15 Jul 2008 09:16:29 -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 A237D28C25B for <idr@core3.amsl.com>; Tue, 15 Jul 2008 09:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level:
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 QEg0+rz3nxWq for <idr@core3.amsl.com>; Tue, 15 Jul 2008 09:16:27 -0700 (PDT)
Received: from psmtp.com (exprod7ob113.obsmtp.com [64.18.2.178]) by core3.amsl.com (Postfix) with ESMTP id 60F733A6AD4 for <idr@ietf.org>; Tue, 15 Jul 2008 09:15:35 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Tue, 15 Jul 2008 09:15:35 PDT
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 09:14:10 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 09:14:09 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 09:14:08 -0700
Received: from [172.26.250.98] ([172.26.250.98]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6FGE7x36560; Tue, 15 Jul 2008 09:14:07 -0700 (PDT) (envelope-from raszuk@juniper.net)
Message-ID: <487CCCCB.6060201@juniper.net>
Date: Tue, 15 Jul 2008 09:14:03 -0700
From: Robert Raszuk <raszuk@juniper.net>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: curtis@occnc.com
References: <200807151426.m6FEQ2gC032246@harbor.brookfield.occnc.com>
In-Reply-To: <200807151426.m6FEQ2gC032246@harbor.brookfield.occnc.com>
X-OriginalArrivalTime: 15 Jul 2008 16:14:08.0810 (UTC) FILETIME=[CFA260A0:01C8E695]
Cc: idr@ietf.org
Subject: Re: [Idr] draft on virtual aggregation
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@juniper.net
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org
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). 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. All this document attempts to is present such option for operators. Some may find them useful some may not. 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. 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