[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] draft on virtual aggregation
Perhaps, routing and forwarding entries suppression.
Cheers,
Rajiv
> -----Original Message-----
> From: Paul Francis [mailto:francis at cs.cornell.edu]
> Sent: Monday, August 18, 2008 12:14 PM
> To: Rajiv Asati (rajiva); curtis at occnc.com
> Cc: idr at 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 at cisco.com]
> > Sent: Saturday, August 16, 2008 12:00 PM
> > To: Paul Francis; curtis at occnc.com
> > Cc: idr at 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 at cs.cornell.edu]
> > > Sent: Thursday, July 31, 2008 6:11 PM
> > > To: Rajiv Asati (rajiva); curtis at occnc.com
> > > Cc: idr at 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 at cisco.com]
> > > > Sent: Thursday, July 31, 2008 9:07 AM
> > > > To: curtis at occnc.com; Paul Francis
> > > > Cc: idr at 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 at ietf.org [mailto:idr-bounces at ietf.org] On
> > > > > Behalf Of Curtis Villamizar
> > > > > Sent: Tuesday, July 15, 2008 10:57 AM
> > > > > To: Paul Francis
> > > > > Cc: idr at ietf.org
> > > > > Subject: Re: [Idr] draft on virtual aggregation
> > > > >
> > > > >
> > > > > In message
> > > > >
> <37BC8961A005144C8F5B8E4AD226DE1109D860 at 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 at ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/idr
> > > > >
> > >
>
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr