Re: [Idr] draft on virtual aggregation

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Mon, 18 August 2008 19:49 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 9279B3A6D78; Mon, 18 Aug 2008 12:49:18 -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 DEE193A6D1B for <idr@core3.amsl.com>; Mon, 18 Aug 2008 12:49:17 -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 DNr1lHykV9bu for <idr@core3.amsl.com>; Mon, 18 Aug 2008 12:49:16 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 12D3C28C174 for <idr@ietf.org>; Mon, 18 Aug 2008 12:49:15 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.32,230,1217808000"; d="scan'208";a="17965253"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Aug 2008 19:49:15 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7IJnF0H019819; Mon, 18 Aug 2008 15:49:15 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m7IJnFRr016857; Mon, 18 Aug 2008 19:49:15 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); Mon, 18 Aug 2008 15:49:15 -0400
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 18 Aug 2008 15:49:57 -0400
Message-ID: <15B86BC7352F864BB53A47B540C089B606019F16@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1110DCBD@EXCHANGE2.cs.cornell.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft on virtual aggregation
Thread-Index: AcjmjMyrelqXdAYdSYqNZy48D3uorwBnTtvAAsvxwCACtdJcEADGrrDgAAeV9/A=
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> <15B86BC7352F864BB53A47B540C089B605FB8A02@xmb-rtp-20b.amer.cisco.com> <37BC8961A005144C8F5B8E4AD226DE1110DCBD@EXCHANGE2.cs.cornell.edu>
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: "Paul Francis" <francis@cs.cornell.edu>, <curtis@occnc.com>
X-OriginalArrivalTime: 18 Aug 2008 19:49:15.0250 (UTC) FILETIME=[7E845520:01C9016B]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10023; t=1219088955; x=1219952955; 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=LU0+jWAbqRb061nTpkUZ5AZZkiaHdZYgUranAmrvUkY=; b=mkjmRPQ36yeyFfNFJzV29ivfePjUtaIphPD7BS/GXG0suY8ypFAxUqP4TX 0LDc9SK0FWJ/uO9yY8N8avlBnJVc8PaC6lj/gu0d3EtLEaGbjwBNacRJrOcY w3UnWwRVE+;
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

 
Perhaps, routing and forwarding entries suppression.

Cheers,
Rajiv

> -----Original Message-----
> From: Paul Francis [mailto:francis@cs.cornell.edu] 
> Sent: Monday, August 18, 2008 12:14 PM
> To: Rajiv Asati (rajiva); curtis@occnc.com
> Cc: idr@ietf.org
> Subject: RE: [Idr] draft on virtual aggregation
> 
> Ah, now I see your point.  You are right, I've been sloppy 
> with terminology,
> and as a result we've been talking at cross purposes.  When 
> I've been saying
> "RIB", I really mean the combination of Loc-RIB and the Adj-RIBs.  
> 
> If the simplest way to keep entries out of the FIB is by not 
> putting them in the Routing Table, then great.  
> 
> I've been using the term "FIB suppression".  One way to deal with the
> confusion this generates is to simply have some text in the 
> draft that makes
> it clear that "FIB Suppression" includes not installing 
> entries into the
> Routing Table.  Another way to deal with it is to create another term.
> Somehow "Routing Table Suppression" seems too broad and 
> doesn't get at the
> core idea.  
> 
> Any suggestions???
> 
> PF
> 
> 
> 
> 
> > -----Original Message-----
> > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]
> > Sent: Saturday, August 16, 2008 12:00 PM
> > To: Paul Francis; curtis@occnc.com
> > Cc: idr@ietf.org
> > Subject: RE: [Idr] draft on virtual aggregation
> > 
> > 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