|
Thread Index [isp-bgp] Re: Zebra as Route Reflector
On Tue, 2003-07-29 at 23:13, Tulip Rasputin wrote:
> > It was originally thought that the number of TCP sessions in a mesh
> > could be a problem. My opinion is that this is not really an issue. iBGP
> > meshes w/ several hundreds of routes work just fine.
>
> I beg to differ on this one. I would like to know what others feel on this issue. If you need RRs
> to only do you aggregation then i think one can use the 'aggregate' command pretty well.
>
The word aggregation is often ambiguous. In the context i'm using it it
means to do information reduction by having an RR select the best out of
a series of paths for the same prefix.
The "aggregate" command reduces information by suppressing more specific
prefixes.
My apologies for using ambiguous terminology.
> The problem in assuming that RRs will be used for what you advocate is that you need to ensure
> that the RR then lies in your forwarding path - thereby putting some severe network design
> constraints!
I wouldn't call it advocacy. I'm trying to alert the original poster to
the issues that he/she should have in mind when using route reflection.
The sure way to do it is to put the RRs in the forwarding path. It is
possible to do it otherwise if one is aware of the caveats.
I would think that forwarding tends to impose harder requirements on
network equipment than control (routing). Thus if the equipment is good
enough to be on the forwarding path it should be ok to do route
reflection.
>
> >
> > One could think of a route reflector-like box that doesn't always
> > advertise just one path and doesn't always advertise all.
> > But that is a very significant change from the current model.
>
> There is nothing which says that we should not be looking at something which is significantaly
> different from existing current models. How else do you want to evolve?
>
I'd like to understand first the problem. :-) If the issue is the fact
that configuring a mesh is very painful and error prone (which it is) i
would say we should address that from that point of view.
If the desired effect is information reduction through one system
choosing a path out of a set of possible paths (route reflector) then
that system needs to have a view that is consistent with the clients to
which serving by selecting the best path out of a given set.
If the issue is the number of TCP sessions (which i personally believe
is a non issue) then you want a route server. i.e. a system that doesn't
perform any path selection.
regards,
Pedro.
------------------------ANNOUNCEMENT---------------------------------
---------------------------------------------------------------------
ISPCON FALL 2003 - Santa Clara Convention Center
October 20-22 - The Definitive Event Wired and Wireless ISPs
www.ispcon.com
----------------------------------------------------------------------
----------------------------------------------------------------------
Thread Index |
|
