Re: [Idr] draft on virtual aggregation

Curtis Villamizar <curtis@occnc.com> Tue, 15 July 2008 14:57 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 88FF03A68ED; Tue, 15 Jul 2008 07:57:06 -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 954293A68ED for <idr@core3.amsl.com>; Tue, 15 Jul 2008 07:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.161
X-Spam-Level:
X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1]
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 5jHhYqY-b5O1 for <idr@core3.amsl.com>; Tue, 15 Jul 2008 07:57:04 -0700 (PDT)
Received: from harbor.brookfield.occnc.com (unknown [69.37.59.172]) by core3.amsl.com (Postfix) with ESMTP id 81F433A686A for <idr@ietf.org>; Tue, 15 Jul 2008 07:57:04 -0700 (PDT)
Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id m6FEv4Cs032524; Tue, 15 Jul 2008 10:57:04 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com)
Message-Id: <200807151457.m6FEv4Cs032524@harbor.brookfield.occnc.com>
To: Paul Francis <francis@cs.cornell.edu>
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Fri, 11 Jul 2008 06:39:57 EDT." <37BC8961A005144C8F5B8E4AD226DE1109D860@EXCHANGE2.cs.cornell.edu>
Date: Tue, 15 Jul 2008 10:57:04 -0400
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: curtis@occnc.com
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

In message <37BC8961A005144C8F5B8E4AD226DE1109D860@EXCHANGE2.cs.cornell.edu>
Paul Francis writes:
>  
> To be clear, we are talking about one new attribute, zero changes to
> the data plane, zero changes to the existing BGP decision
> process....just some rules for automatically setting up tunnels and
> new address aggregates (virtual prefixes).  Better to do this now well
> before the next generation of routers runs out of FIB.
>  
> PF


Paul,

Most providers amortize their routers in three years but keep them in
service for five or more.  Typical growth rates in healthy providers
are a doubling in about 1.5-2 years with some providers reporting 1
year (unconfirmed).  They keep routers in service by moving them
closer to the edge where the lower capacity of the router is less of
an issue, sometime redeploying from major cities to lesser cities.

A smart provider looks at their current default free routing size and
looks for at least 2 and better 4 or more times that in FIB and RIB
capacity, with RP memory size also dictated by the number of BGP peers
and peer groups that are expected to be supported.

Most of the providers with very large FIB and RIB are those top tiers
that do not do a good job of aggregating the routes for their own
infrastructure.  To aggregate well, they have to first allocate blocks
of addresses by POP and also subdivide their network into areas and
aggregate at area boundaries (possibly the only functionality where
confederations may be more straightforward and less error prone than
RR, but that is another topic).

If my memory serves me correctly, the target for major router vendors
(dictated by certain tier-1 providers) was over 1 million circe late
1990s, about 2 million early 2000 and some asked for as much as 4
million just to have headroom (and got it from some vendors).

RAM is cheap.  Once you go off chip (RAM off the forwarding ASIC)
memory bandwidth is much more an issue than memory size.

The problem is mainly "enterprise switch/routers" with on chip CAM and
TCAM and no provision for off chip RAM that have been a problem.  To a
lesser extent a few routers inteded as large enterprise routers or
default free provider routers will now require that you replace the
forwarding cards.

IMHO again: I think this is not a hack that IDR should pursue.  But I
have mostly worked with tier-1 providers and I am open to other
opinions.  Lets hear from some providers on this.

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