Subject: [Idr] A question on longest match

From: "john smith" <[email-masked]>
Date: Tue, 01 Jun 2004 07:49:42 +0000

Hello,

Is there any specific reason why the BGP algorithm relies on the longest 
match paradigm?

Is there any reason why one cannot simply propogate the "range of addresses" 
and use different metrics?
For example one could say "address numbers 100000 - 212123 are here and 
212124 - 312127 are there?

Would this not lead to considerable reduction of the size of the forwarding 
table?

--
(&)
Little John.

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

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

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 1 Jun 2004 14:43:01 -0400

At 8:19 AM +0000 6/1/04, john smith wrote:
>Hello Big Brother,
>
>It is specifically releated to BGP.
>
>Aggregation in non DV protocols is not a possibility unless one goes 
>across Area/Level boundarys.

Maybe I'm missing something, but I wouldn't make that claim. 
Hierarchical topology and multiple levels are not a requirement of 
routing protocols. Many large ISPs run very big single ISIS areas. 
So, there very well may not be Area/Level boundaries to cross.

Hierarchical information hiding MAY be a useful deployment technique 
in LS protocols to reduce the computational load of the Dijkstra 
algorithm, but it's perfectly reasonable and plausible to build 
hierarchical networks in protocols as simple as RIPv1 -- start with 
Class C (usually private space) at the edge and work up, eventually 
going to Class B.

>
>This is due to their inherent nature of sending advertisements of 
>"all connected networks" to "all nodes in the same level or area".
>
>Now you do believe aggregation is good, do you not? I am sure you do!
>
>Now to further that assumption, if aggregation is good, and one was 
>to make a forwarding device which would not do Layer 3 lookup based 
>on the bit aligned boundaries, but on ranges, would it be considered 
>bad or good?
>
>Also please let me know if this is not an item to dicuss on idr, or 
>should the be specifically targetted to the routing-discussion 
>mailing list? In that case I shall not cc the list further on these 
>queries.
>
>--
>(&)
>Little John.
>
>>From: "John Smith" <[email-masked]>
>>To: <[email-masked]>
>>Subject: RE: [Idr] A question on longest match
>>Date: Tue, 1 Jun 2004 13:43:25 +0530
>>
>>Is your question related to BGP or is it related to general routing
>>(networking) principles?
>>
>>If its the latter then you need to start with a good book on basic
>>networking principles (unless ofcourse i am missing your point altogether!)
>>and if its the latter, then it doesn't make much sense to me ! Care to
>>elaborate?
>>
>>--
>>(&)
>>Big brother John
>>
>>----- Original Message -----
>>From: "john smith" <[email-masked]>
>>To: <[email-masked]>
>>Sent: Tuesday, June 01, 2004 1:19 PM
>>Subject: [Idr] A question on longest match
>>
>>
>>>  Hello,
>>>
>The new MSN 8: advanced junk mail protection and 2 months FREE* 
>http://join.msn.com/?page=features/junkmail
>
>

---

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

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?

>
>Its not worth it to aggregate the FIB.  There is very little gain if
>you don't aggregate over holes.
>
>If you aggregate over holes you'd need to include more specific reject
>routes.
>
>If you aggregate the FIB and a withdraw occurs you need to add a
>reject.  You then need to be concerned about aggregating the rejects
>that you are adding.
>
>Gain is small.  There is an increase in completity.
>
>Disallowing longest to allow automatic aggregation was discussed on
>BGP, BGPD, CIDR, or CIDRD more than 10 years ago.  We didn't go that
>way and its way too late to turn back.
>
>Curtis

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

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

>you don't aggregate over holes.

Curtis, the nodes where the holes occur are way down in the network.

Infact the places where they do occur happen to be places where /24 networks 
may actually be connected.

The offset for the same is the fact that the rest of the internet as seen 
from that point is "coniguous".  So it offsets the same.
This has been my observation.

>If you aggregate over holes you'd need to include more specific reject

I do not aggregate over holes. I suggest aggregate "what one can as long as 
the next-hop is the same" and populate the FIB.
I agree it makes more sense to aggregate and propogate, but if not that, can 
we atleast aggregate what goes into the FIB?

>reject.  You then need to be concerned about aggregating the rejects

I could also break the aggregate at that point of time.

I still have the specifics in the RIB rememeber?

>Gain is small.  There is an increase in completity.

It can be the same for *all protocols* Gain can be immense I think.

>way and its way too late to turn back.

:)

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

---

From: "john smith" <[email-masked]>
Date: Fri, 04 Jun 2004 15:50:20 +0000

Sorry for being rude Curtis,

As I said it was an opinion, and I shared it,

It is for the WG to decide.

>From: Curtis Villamizar <[email-masked]>
>Reply-To: [email-masked]
>To: "john smith" <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: [Idr] A question on longest match Date: Fri, 04 Jun 2004 
>11:44:43 -0400
>
>In message <[email-masked]>, "john smith" writes:
> >
> >
> > >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 :)
>
>
>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.
>
>
> > > > 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?
>
>
>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 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*?
>
>
>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.

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail