Re: [Idr] draft on virtual aggregation

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Thu, 31 July 2008 13:07 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 6A8913A6C1E; Thu, 31 Jul 2008 06:07:35 -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 096793A6AE8 for <idr@core3.amsl.com>; Thu, 31 Jul 2008 06:07:34 -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 0dR0r3slqkVa for <idr@core3.amsl.com>; Thu, 31 Jul 2008 06:07:33 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 82C103A69D8 for <idr@ietf.org>; Thu, 31 Jul 2008 06:07:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,286,1215388800"; d="scan'208";a="16090474"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2008 13:07:17 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VD7HX0012489; Thu, 31 Jul 2008 09:07:17 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6VD7HkU001476; Thu, 31 Jul 2008 13:07:17 GMT
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 09:06:26 -0400
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 31 Jul 2008 09:06:59 -0400
Message-ID: <15B86BC7352F864BB53A47B540C089B605E92736@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <200807151457.m6FEv4Cs032524@harbor.brookfield.occnc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft on virtual aggregation
Thread-Index: AcjmjMyrelqXdAYdSYqNZy48D3uorwBnTtvA
References: Your message of "Fri, 11 Jul 2008 06:39:57 EDT."<37BC8961A005144C8F5B8E4AD226DE1109D860@EXCHANGE2.cs.cornell.edu> <200807151457.m6FEv4Cs032524@harbor.brookfield.occnc.com>
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: <curtis@occnc.com>, "Paul Francis" <francis@cs.cornell.edu>
X-OriginalArrivalTime: 31 Jul 2008 13:06:26.0924 (UTC) FILETIME=[3DA2F2C0:01C8F30E]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3757; t=1217509637; x=1218373637; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20(rajiva)=22=20<rajiva@cisco.com > |Subject:=20RE=3A=20[Idr]=20draft=20on=20virtual=20aggregat ion |Sender:=20 |To:=20<curtis@occnc.com>,=20=22Paul=20Francis=22=20<franci s@cs.cornell.edu>; bh=+Gm7kLSQLzqRSeXdZ/A1xbTjKOSxWbgeQGmYPwnnCvQ=; b=HMwOKArLVJUm2GJa1TkXhqY2PfxtDfGb7nJJ+XBN7IsaDLdxPFMzmrdHh/ 5WtWCu6Lx77/vkE+M+xzSOf3SmyS7JklFmOBzzJTtwdGBjk3Nvu2GztW+msv MEBePrnXbo;
Authentication-Results: rtp-dkim-1; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
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

The idea to keep FIB out-of-sync with RIB is a bit discomforting when
the troubleshooting has to be done for the traffic outage. Also, this
unnecessarily increases the complexity of the RIB and FIB interaction. 

For a lot of network operators, it may be cleaner to not even install
the qualified BGP paths into the RIB. FIB suppression would happen
automatically. 

Note that the decision to advertise the BGP paths to the downstream BGP
speaker can be independent of whether the paths are suppressed or not in
the RIB/FIB. This may be proposed by this specification.

Perhaps, you could clarify the rationale/advantages for keeping the
routes in the RIB. Thanks.

Cheers,
Rajiv


> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On 
> Behalf Of Curtis Villamizar
> Sent: Tuesday, July 15, 2008 10:57 AM
> To: Paul Francis
> Cc: idr@ietf.org
> Subject: Re: [Idr] draft on virtual aggregation
> 
> 
> 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
> 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr