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