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

From: "john smith" <[email-masked]>
Date: Fri, 04 Jun 2004 06:22:29 +0000

Hi Curtis,

> >
> > 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.
>
>
>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.
>

exactly.

>
> > >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?
>
>
>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.
>
Agreed.
The point is that other than BGP no other protocol has to rely so heavily on 
the paradigm of longest match. Mainly as BGP has to carry that information.

It really is not a problem to find a route-server equivalent PC which can 
store a considerable amount of routes without adding an expense to it.

The problem is that out of those 300,000 routes, a lot of them are very 
redundant and I certainly do not appreciate vendors coming out with "1 
million routes in the forwarding table" models for no rhyme or reason.

Even if we add up the existing deployment of routers, most of them are 
sufficient to handle the existing prefixes when aggregated for a 
considerable amount of time.

>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.
>

It certainly is better than entring a "split brain" with NO_EXPORT :)

>
> > Or we are saying BGP is specifically meant only for vendors and 
>operators
> > who can cater to such hardware?
>
>
>Providers can aggregate better but it requires better coordination
>among providers.
>

How has this got *anything* to do with coordination among providers?

It is upto the IETF to make the providers cordinate. Eitherways if the IETF 
thinks the idea makes *any sense* then they should take a step in that 
direction rather than say "too late".

If people can build terabit routers which can switch millions of packets and 
have a huge FIB, they can figure out ways to reduce the FIB size too. It is 
a matter of what the "specs" say.

Are specs *not* made for scalaibilty? To quote someone from another list, is 
it not the job of the *specs* to say what is *techincally correct*?

>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.
>

Is that the reason why they want to prefix limit?

For that matter, may I be bold enough to ask what *high speed FIB* the merit 
route servers were using?

>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.
>
You contradict the statement below :) where you say you thought of it first.

You could probably do a quick search on google and you will find lots of 
folks who have asked for summarization feature of BGP routes.

>
> > >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.
>
>
>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.
>

agreed. The answer was specific to your question.

>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 has that got anything to do with the question?

>
> > >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.
>
>
>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.
>

As i said, please do a google on the same. The question is simple, does the 
WG intend to scale in a suitable manner or not?

>
>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.

:-) how many providers did you speak to?
Eitherways, I believe it can be specified in the draft, how it is handled 
can be an implementation issue.

_________________________________________________________________
The new MSN 8: smart spam protection and 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: Fri, 04 Jun 2004 11:44:43 -0400

> It certainly is better than entring a "split brain" with NO_EXPORT :)

We're talking about two different things.  Automatic aggregation of
the FIB is safe to do under all circumstances.  Automatice aggregation
and reannouncement is not always safe.

> How has this got *anything* to do with coordination among providers?

If provider A has a aggregate and some customers are dual homed to
provider B, then provider B or downstream can't safely aggregate those
routes.  If any of those dual homed customers loosed connection to A
and most providers rightfully send traffic for the A aggregate to A,
then those customers don't have backup through B.

See 10 year old discussion on "hostile aggregation".

The modern twist on this is that the "provider coordination" these
days can be as simple as adding a BGP community.  We now have a BGP
communitity that can work across any number of AS crossings, the
NOPEER.  The classic example where this is a problem is the
non-aggregation of Australian routes in the US and Europe.
Unfortunately the NOPEER isn't being used enough so you need to use
the "clue club" (as someone who has contributed a lot to operations
has called it, or was it the "clue bat") with the provider origination
the route.  That too is a form of interprovider coordination, but not
one easily standardized.

That's what PTOMANE and GROW are all about.  Or a big part of it.

In the case of 4/8, there were a very small number of more specific.
In all likelyhood these are only the ones that really needed to be
there (or at least most of them) so you shouldn't touch them.

> it not the job of the *specs* to say what is *techincally correct*?

Not to be rude but I chopped off the rest of your response.  I
responded the first time off list because I didn't want to get into an
extended thread on this.

You are not telling the IETF something that the IETF is not aware of
or hasn't thought about.  If you want to see what the IETF WGs have
had to say about this topic, look in the archives.  In particular you
want to look at the PTOMAINE and GROW WG, more PTOMAINE.

Thanks for the advice.  :-)

Curtis