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