Subject: Re: [Idr] A question on longest match

From: "john smith" <[email-masked]>
Date: Thu, 03 Jun 2004 16:53:13 +0000

Hello Curtis,

> > Hello Curtis,
> >
> > That is strange indeed.
> >
> > I have seen very different results when doing the same.
> >
> > I am not talking about aggregating over holes at all.
> >
> > I am simply saying,
> >
> > I receive 20 prefixes of say /19 from 1 link and 40 of say /20 from the
> > other.
> >
> > Most of these as far as I can see can be aggregated, but are still
> > advertised as they are due to the presence of longest match paradigm
> >
> > However, I guess this is specific to my view,
> >
> > Though, why is there a problem in doing so?
>
>
>The issue is really what gains can be made for the router with 300,000
>prefixes in the FIB.  I did the analysis when the number of global
>routes was well under 20,000 and the gains where not all that great
>unless you aggregated over the holes.
>

Please check the specific examples I emailed you offline. Or for that matter 
please check any node on the internet. In most cases the reduction is quite 
a bit.

>At this point there is no problem in doing so but the cost of FIB
>storage isn't that great and the slow down in route insertion/deletion
>would be a bad thing for the space reduction.  The time lookup is no
>issue either with modern hardware.
>

So we are saying that we will not have more routes?

Or we are saying BGP is specifically meant only for vendors and operators 
who can cater to such hardware?

>When you do packet filtering (all core routers need to be able to do
>this on all interface types because private peerings can be over
>OC192c POS) you have to keep a FIB for the router and then you have to
>apply the packet filtering rules per interface.  That already
>increases the work (the same card can have one processor but more than
>one interface, even OC192c or 10GbE).

I think most people tend to do:
ip route <RFC1918> null0

and if they want to use *some RFC 1918 address space* internally, they put a 
route to pass that space as a more specific. That definately is not an issue 
which hampers this.

Eitherways this is definately *not* packet filtering.

>
>Anything which further multiplies the change to the FIB makes route
>convergence slower and that is a big issue today.  Its not the size of
>the FIB that matters today its trying to process the amount of change
>that can occur in the "well under 1 second" time frame that providers
>are looking for.
>

So can we have something to the effect of:
"if there is a terrible impact in performance such a feature should be 
turned off but if not, it makes sense" ?

How it is done can be an implementation issue.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 03 Jun 2004 17:55:53 -0400

John,

I dropped the IDR Cc but I see you added it back.

Comments inline.

Curtis

> please check any node on the internet. In most cases the reduction is quite 

Yes I did.  You pointed to the 4/8 prefix and some more specific, none
of which were contiguous.  You also pointed to a block that started at
x.x.211/24 and fell under a /16 but I pointed out that a block
starting at .211 doesn't compress well unless you fill the holes and
then you just need the /16.

> So we are saying that we will not have more routes?

There will be more routes.  I did the analysis when there were less
than 20,000 routes.  There are now 300,000 routes or more depending on
who you talk to.

Back then this idea was known as "FIB compression" and if you like you
can search the archives for a lot of discussion on the issue and quite
a bit of measurement done at that time.

> who can cater to such hardware?

Providers can aggregate better but it requires better coordination
among providers.

It is up to providers to decide how they configure their routers.
Having worked very closely with many router vendors over the last 12
years, and working at one now, I can tell you that the RIB with lots
of peers is a much bigger problem than the size of the FIB.

There is nothing to stop a vendor from compressing the FIB if they
think that will make a better routers.  It just happens that none do
it an IMHO it would not be a good idea to do so.

> Eitherways this is definately *not* packet filtering.

At peer and most customer boundaries, most providers also do things
like block all traffic destined to port numbers for OSPF, BGP, SNMP,
and a few others except their EBGP peerings.  Some put other packet
filters in place, many on source address to prevent spoofing.  It to
some extent depends on what their routers can do.

Filtering is often applied on a per interface basis.  It is at least
different for outward facing interfaces (connected to peers or
customers) than inward facing (connected to the core).  For a router
with lots of interfaces this is added work.  It is not an important
point though but it does affect convergence a little if there is lot
of filtering that has to be applied after the RP sends the FIB.

> How it is done can be an implementation issue.

Its up to the providers to decide which trafeoff is more important.
No provider has been telling me that they want their routers to do
more computation and eat more memory in the RP to compress the FIB
such that the line cards can have less entries.  If you are a
provider, talk to your router vendor if you think that's a good
tradeoff.  If you are a vendor, talk to providers and see it they are
interested.  AFAIK there is not interest in FIB compression.

ps - but if FIB compression takes off I can claim to have thought of
the idea first.  :-)  But I honestly don't think it will.