Re: [Idr] draft on virtual aggregation

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Sat, 16 August 2008 16:00 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 1D7233A6BA7; Sat, 16 Aug 2008 09:00:26 -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 410F33A6BDE for <idr@core3.amsl.com>; Sat, 16 Aug 2008 09:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 cfhFoUAp+91H for <idr@core3.amsl.com>; Sat, 16 Aug 2008 09:00:24 -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 BE8F43A6BA7 for <idr@ietf.org>; Sat, 16 Aug 2008 09:00:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.32,222,1217808000"; d="scan'208";a="17695322"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 16 Aug 2008 16:00:02 +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 m7GG02Z0010221; Sat, 16 Aug 2008 12:00:02 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7GG02S9024299; Sat, 16 Aug 2008 16:00:02 GMT
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Aug 2008 12:00:02 -0400
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 16 Aug 2008 12:00:01 -0400
Message-ID: <15B86BC7352F864BB53A47B540C089B605FB8A02@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1110DAA0@EXCHANGE2.cs.cornell.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft on virtual aggregation
Thread-Index: AcjmjMyrelqXdAYdSYqNZy48D3uorwBnTtvAAsvxwCACtdJcEA==
References: Your message of "Fri, 11 Jul 2008 06:39:57 EDT."<37BC8961A005144C8F5B8E4AD226DE1109D860@EXCHANGE2.cs.cornell.edu> <200807151457.m6FEv4Cs032524@harbor.brookfield.occnc.com> <15B86BC7352F864BB53A47B540C089B605E92736@xmb-rtp-20b.amer.cisco.com> <37BC8961A005144C8F5B8E4AD226DE1110DAA0@EXCHANGE2.cs.cornell.edu>
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: "Paul Francis" <francis@cs.cornell.edu>, <curtis@occnc.com>
X-OriginalArrivalTime: 16 Aug 2008 16:00:02.0243 (UTC) FILETIME=[24428130:01C8FFB9]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7701; t=1218902402; x=1219766402; 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=22Paul=20Francis=22=20<francis@cs.cornell.edu>,=20< curtis@occnc.com>; bh=P+woUhd5hDdAOopDoi5XZY99zKrF0+1lnoI/XIdaD5Y=; b=G71von1Uutwcypzsc2JYNL6iC5XRZj8Yp0vj0mRlF2zd+BVxKkVI8r2+jB FHtPUoTJudAOoYl4q4B4/kfjiFuuBspBzRHbnQtOnSndlNy3uztkHbsndPdn H4HIHhQWRk;
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

Hi Paul,

Please see inline,

> Bottom line is that if the router doesn't have the full RIB, 
> then it can't participate fully in eBGP.  People already 

That may deserve further scrutiny. Let's make sure that we are referring
to the same terminology here. RIB, per RFC4271 is considered different
from the routing table that the router uses to build the forwarding
table. In that context, I think you are really referring to Loc-RIB
above. 

Whether or not the routes are installed in the routing table so as to
advertise them out to eBGP peers is unrelated.


One can certaily define a local policy which results in routes being
advertised to eBGP neighbor without being added to the local routing
table. For example, if we look at Inter-AS VPN Option C for AFI/SAFI
such as VPNv4 etc., then the route reflector advertises the VPNv4 routes
to eBGP peers without installing them in any routing table.


The last sentence in the following excerpt from the BGP specification
(RFC4271 or RFC1771) may help  -

~~~~~~~~~~~~
3.2.  Routing Information Base

   The Routing Information Base (RIB) within a BGP speaker consists of
   three distinct parts:

	..<deleted>..

   Routing information that the BGP speaker uses to forward packets (or
   to construct the forwarding table used for packet forwarding) is
   maintained in the Routing Table.  The Routing Table accumulates
   routes to directly connected networks, static routes, routes learned
   from the IGP protocols, and routes learned from BGP.  Whether a
   specific BGP route should be installed in the Routing Table, and
   whether a BGP route should override a route to the same destination
   installed by another source, is a local policy decision, and is not
   specified in this document.  
 ~~~~~~~~~~~~~~~~~~
 
We should also look at the section 11 of RFC4277.

If BGP, per your proposal, only installs selected routes in the routing
table, then forwarding table just gets it. No implementation changes
between how RIB and FIB interact. This becomes a pure BGP solution, and
the changes are limited to BGP, not beyond it.

Cheers,
Rajiv

> -----Original Message-----
> From: Paul Francis [mailto:francis@cs.cornell.edu] 
> Sent: Thursday, July 31, 2008 6:11 PM
> To: Rajiv Asati (rajiva); curtis@occnc.com
> Cc: idr@ietf.org
> Subject: RE: [Idr] draft on virtual aggregation
> 
> Bottom line is that if the router doesn't have the full RIB, 
> then it can't
> participate fully in eBGP.  People already know how to shrink 
> RIB and FIB in
> edge routers that don't need to be full eBGP speakers.  
> Virtual Aggregation
> makes it possible to shrink the FIB in any router.
> 
> You are certainly right that trouble shooting becomes more 
> complex.  The
> admin has to ask if the route is installed or not, and if not 
> figure out what
> aggregation point the packet is supposed to go to and so on.  
> This is one of
> the trade-offs that the ISP has decide if it is worth making.
> 
> Could you be more clear about what you mean by "increases the 
> complexity of the RIB and FIB interaction"?  
> 
> PF
> 
> 
> > -----Original Message-----
> > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]
> > Sent: Thursday, July 31, 2008 9:07 AM
> > To: curtis@occnc.com; Paul Francis
> > Cc: idr@ietf.org
> > Subject: RE: [Idr] draft on virtual aggregation
> > 
> > 
> > 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