Re: [Idr] draft on virtual aggregation

["Rajiv Asati (rajiva)" <[e-mail]>]

 
Perhaps, routing and forwarding entries suppression.

Cheers,
Rajiv

> -----Original Message-----
> From: Paul Francis [mailto:[e-mail]] 
> Sent: Monday, August 18, 2008 12:14 PM
> To: Rajiv Asati (rajiva); [e-mail]
> Cc: [e-mail]
> 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:[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