[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


ender: idr-bounces at ietf.org
Errors-To: idr-bounces at ietf.org


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