Subject: Re: Route Reflectors versus Route-servers

From: "Alok Dube" <[email-masked]>
Date: Fri, 10 Oct 2003 18:12:50 +0530

John,

an errata on my part :

>which also implies that the RR still sees them as 2 >different routes and
propogates them both.

should be "which implies on an incorrectly configured network the RR still
sees them as 2 different routes and propogates them both."

apologies.

-Alok

----- Original Message -----
From: "Alok Dube" <[email-masked]>
To: "John Smith" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 10, 2003 5:59 PM
Subject: Re: Route Reflectors versus Route-servers

> John,
>
> some things I would appreciate if you could clarify..
>
> ----- Original Message -----
> From: "John Smith" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, October 10, 2003 3:01 PM
> Subject: RE: Route Reflectors versus Route-servers
>
>
> > Alok,
> >
> > > Which implies that for an RR to operate effectively, the RR has to be
in
> > > the forwarding path of the traffic.
> > > In that case, would it not need a VRF for those VPNs?
> >
> > Even if the RR falls in the forwarding path, it does not need to
configure
> VRFs.
> >
> > Consider this scenario.
> >
> > A -- RR -- B
> >
> > where both A and B are RR Clients. Suppose B advertises some BGP Labels
to
> RR which in
> > turn are advertised to A by the RR. The information that A receives is
(i)
> The BGP label
> > associated with some prefix (some FEC) (ii) the BGP NEXT_HOP which
happens
> to be the
> > loopback IP address of B in most of the cases.
>
>
> for the part below, I assume you saying  we do not have LSPs from A to B.
> >
> > A searches for the IGP Tunnel label associated with the bgp NEXT_HOP.
The
> tunnel could
> > have been set up using LDP, etc. So what A simply needs to do is to push
> the BGP label
> > (the one which it received from the RR) and then push the tunnel IGP
label
> and send this
> > MPLS packet towards RR. RR upon recieving this packet simply swaps the
top
> most label and
> > pushes a new label and sends it off to B.
> >
> > B recives the MPLS packet with the tunnel label (if PHB is not
supported)
> or the BGP
> > label. It looks at its ILM and forwards the packet based on the entries
it
> has.
> >
> > In this case, the RR falls in the forwarding path, but it still does not
> need to
> > configure any VRF. I think the golden rule to remember is: Use VRFs only
> when connecting
> > to customers!
>
>
> My point is not VRF....I may not use the right word, but it seems to be
more
> like a "table/seperate database" to me.
>
> What i see is something like this:
>
> Incoming Routes from clients----->export RT matched--->table based on
export
>  RT (RT is unique to the VPN)---->BGP decision algorithm "per
table"--->send
> out the best routes to peers.
>
> if this means that there is seperate decision making algorithm "thread"
> running in this case for each table (depending on how you plan to
implement
> it), what is the exact overhead you see in doing so? I am calling it a
> "table" and not a VRF and as you can see, there are no interfaces here
too.
>
> I am also not asking for multiple instances of OSPF etc on this device.
All
> I am pointing out is "seperate tables/database seperation on the device
per
> VPN"
>
> About the multihoming case, I see that the draft seems to suggest -use the
> same RD for the VPN if its on the same router, use the same RD for the VPN
> if its on different routers- and as Robert pointed out, the fact that RDs
> are the same implies they are the same route in a correctly configured
> network..which also implies that the RR still sees them as 2 different
> routes and propogates them both.
>
> Now if the RR is to anyway propogate them both, the only outcome is that
the
> RR is avoiding the full mesh.
>
> The same could be done by simply passing on everything the RR learns.
>
>
> >
> > > In 1 case , the decision making algorithm (incase it is not in the
> > > forwarding path) may lead to suboptimal routing, and in the 2nd case,
it
> >
> > I think its well known that using RR can sometimes lead to suboptimal
> routing if its not
> > in the forwarding path.
>
> How would using a  forwarding device like a route server cause a problem
> here? this is what is confusing me.
>
> thanks for your clarifications though,
>
> -rgds
> Alok
>
> >
> > > would be in the path anyways, so why not the VRF?
> > >
> >
> > Cheers!
> >
> > ________________________________________________________________________
> > Want to chat instantly with your online friends?  Get the FREE Yahoo!
> > Messenger http://mail.messenger.yahoo.co.uk
> >
>