Re: [Idr] draft on virtual aggregation

[Paul Francis <[e-mail]>]

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:[e-mail]]
> Sent: Saturday, August 16, 2008 12:00 PM
> To: Paul Francis; [e-mail]
> Cc: [e-mail]
> 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:[e-mail]]
> > Sent: Thursday, July 31, 2008 6:11 PM
> > To: Rajiv Asati (rajiva); [e-mail]
> > Cc: [e-mail]
> > 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:[e-mail]]
> > > Sent: Thursday, July 31, 2008 9:07 AM
> > > To: [e-mail]; Paul Francis
> > > Cc: [e-mail]
> > > 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: [e-mail] [mailto:[e-mail]] On
> > > > Behalf Of Curtis Villamizar
> > > > Sent: Tuesday, July 15, 2008 10:57 AM
> > > > To: Paul Francis
> > > > Cc: [e-mail]
> > > > Subject: Re: [Idr] draft on virtual aggregation
> > > >
> > > >
> > > > In message
> > > > <[e-mail]>
> > > > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/idr
> > > >
> >
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr