Subject: Route Reflectors versus Route-servers

From: "Alok Dube" <[email-masked]>
Date: Fri, 10 Oct 2003 02:44:18 +0530 (IST)

hi,

I would like to understand the difference in using either one on a L3VPN
topology. (route reflectors versus route servers).
I read some threads which said that the RR may not need a "VRF" as it will
not have an "interface" in the VPN associated with the VRF.
But the RR will make the "best path decisions as seen by itself locally".

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?

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
would be in the path anyways, so why not the VRF?

if it was a sort of "route server", it would never run the decision
process and pass on all routes learnt from client peers to the each and
every non client peer and client peer , and those from non client peers to
client peers. In this case it may not even be in the forwarding path.

is my interpretation correct?

-thanks
Alok

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 09 Oct 2003 22:40:49 +0200

Hi Alok,

Yes I think your observations are correct. But please observe that if 
you follow a principle of different RD per each vrf your RR's best path 
selection would turn into a pure formality as each path will be unique 
and best path selection will always be running there essentially over a 
single path.

If your RDs are the same on any set of vrfs it seems indeed that falling 
down to IGP cost to next hop especially in the case when you run LDP and 
RRs are not in the forwarding path or that don't set next hop to self is 
questionable. I should not break anything connectivity wise. Only in the 
cases of multihomed sites it could make the path less optimal.

Cheers,
R.

 > Alok Dube wrote:

---

From: PamSri <[email-masked]>
Date: Fri, 10 Oct 2003 07:22:38 -0700 (PDT)

Hi Alok,
       Sub-optimal routing is just one of the
consequence. It could lead to blackholes should the RR
start making the routing decisions on the received VPN
routes. Here's the reason:
Since the RR does'nt have VRF it cannot really use the
RTs for the policies. So if RR were to choose a best
route (ofcourse as Bob said, using RD to uniquely
identify the VPN routes) which its client were to
discard due to non-match of RT for the VRF then that
VRF never gets any more routes for that. 

sri

> > is my interpretation correct?

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

---

From: "Jim Guichard" <[email-masked]>
Date: Fri, 10 Oct 2003 10:27:48 -0400

I don't think the possibility for blackholes exists unless you misconfigure
the import/export policy. The RTs have nothing to do with route selection.
If you happen to send two routes with same RD:IP-address pair, and these two
routes do not carry the right RT values (or one does and the other does
not), then the PEs that were supposed to receive the routes might lose
connectivity to that specific prefix. Jim

> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]On Behalf Of
> >PamSri
> >Sent: Friday, October 10, 2003 10:23 AM
> >To: [email-masked]; [email-masked]
> >Cc: [email-masked]
> >Subject: Re: Route Reflectors versus Route-servers
> >
> >
> >Hi Alok,

---

From: PamSri <[email-masked]>
Date: Fri, 10 Oct 2003 08:35:18 -0700 (PDT)

Blackholing is a subset of suboptimality and the
former is a condition arising out of the latter. Whole
idea of RRs usage in this scenario is prevent meshes
and to not cause suboptimality. Does it mean that this
condition is seen in every scenario ? I dont think so
but there are cases where this is prone to this
condition. IMO, its oversimplifying to rule out this
condition.

BTW, RTs have everything to do with route selection as
they remain the prime criterion to be even considered
for route selection. 

sri

--- Jim Guichard <[email-masked]> wrote:
> > >From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > >PamSri
> > >> you follow a principle of different RD per each
> vrf
> > >> your RR's best path
> > >> selection would turn into a pure formality as
> each
> > >> path will be unique
> > >> and best path selection will always be running
> there
> > >> essentially over a
> > >> single path.
> > >>
> > >> If your RDs are the same on any set of vrfs it
> seems
> > >> indeed that falling
> > >> down to IGP cost to next hop especially in the
> case
> > >> when you run LDP and
> > >> RRs are not in the forwarding path or that
> don't set
> > >> next hop to self is
> > >> cases of multihomed sites it could make the
> path
> > >> less optimal.
> > >>
> > >> Cheers,
> > >> R.
> > >>
> > >>  > Alok Dube wrote:
> > >>  >
> > >> > hi,
> > >> >
> > >> > I would like to understand the difference in
> using
> > >> either one on a L3VPN
> > >> > I read some threads which said that the RR
> may not
> > >> need a "VRF" as it will
> > >> > not have an "interface" in the VPN associated
> with
> > >> the VRF.
> > >> > But the RR will make the "best path decisions
> as
> > >> seen by itself locally".
> > >> >
> > >> > In that case, would it not need a VRF for
> those
> > >> VPNs?
> > >> >
> > >> > 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
> > >> > if it was a sort of "route server", it would
> never
> > >> run the decision
> > >> > process and pass on all routes learnt from
> client
> > >> peers to the each and
> > >> > every non client peer and client peer , and
> those
> > >> from non client peers to
> > >> > client peers. In this case it may not even be
> in
> > >> the forwarding path.
> > >> >

---

From: "Jim Guichard" <[email-masked]>
Date: Fri, 10 Oct 2003 12:23:00 -0400

> >Sent: Friday, October 10, 2003 11:35 AM
> >To: Jim Guichard; [email-masked]
> >Cc: [email-masked]
> >Subject: RE: Route Reflectors versus Route-servers
> >
> >
> >former is a condition arising out of the latter.

not in the case of a 2547 network - if there is a specific scenario you have
in mind that details a blackholing event then I would be interested to see
it .. apart from misconfiguration I cannot think of a single case.

 Whole
> >they remain the prime criterion to be even considered

not at the RRs - they could not care less about RTs - RTs are used for
import/export policy at the PE-routers - note that RTs have no place within
the BGP selection criteria. If you misconfigure the RTs then they may not
pass the ARF check but then this is a misconfiguration rather than a flaw in
the architecture.

Jim

---

From: PamSri <[email-masked]>
Date: Fri, 10 Oct 2003 11:00:08 -0700 (PDT)

Did i ever refer to the fact that the RRs were using
RTs ? Was'nt the whole issue that the RRs did'nt need
to store the VRF info inclusive of the RTs was
resulting in sub-optimal routing ? Before we get
offtrack let me re-iterate my concern for the sake of
clarity.

My concern is about the RRs running the route
selection on the VPN prefixes by comparing routes with
the same RD heading to different VRFs. In this case
the best route selected and propagted by the RR will
get populated in only some VRFs (ofcourse this is
conditional). Thus resulting in black holes.

sri

--- Jim Guichard <[email-masked]> wrote:
> > >> I don't think the possibility for blackholes
> exists
> > >> unless you misconfigure
> > >> the import/export policy. The RTs have nothing
> to do
> > >> with route selection.
> > >> routes do not carry the right RT values (or one
> does
> > >> and the other does
> > >> not), then the PEs that were supposed to
> receive the
> > >> routes might lose
> > >> > >consequence. It could lead to blackholes
> should
> > >> the RR
> > >> > >Since the RR does'nt have VRF it cannot
> really
> > >> use the
> > >> > >RTs for the policies. So if RR were to
> choose a
> > >> best
> > >> > >discard due to non-match of RT for the VRF
> then
> > >> that
> > >> > >> Yes I think your observations are correct.
> But
> > >> > >> please observe that if
> > >> > >> > would be in the path anyways, so why not
> the
> > >> VRF?
> > >> > >> >
=== message truncated ===

---

From: "Jim Guichard" <[email-masked]>
Date: Fri, 10 Oct 2003 14:18:57 -0400

> >From: PamSri [mailto:[email-masked]]
> >Sent: Friday, October 10, 2003 2:00 PM
> >To: Jim Guichard
> >Cc: [email-masked]

once again, this is a misconfiguration. If two routes with the same RD
arrive at the RRs then they must be equal to be compared e.g.
RD:1:10.1.1.1/32 is not comparable with RD:1:10.1.1.2/32. The best path is
selected and advertised to the PEs. If the RT has been configured correctly
on the exporting PEs then there is no problem. Also, note that we recommend
using separate RDs per VRF per PE and therefore this situation should not
even arise. Jim

---

From: "Sakthivadivu.S.S" <[email-masked]>
Date: Mon, 13 Oct 2003 12:43:38 +0530

Hi,

    Section 4.3.3 of 2547 draft says in 2'nd method of Route Reflector
  "Note that this technique will not work properly if some client PE
   has a VRF with an import Route Target that is not one of its 
   export Route Target" 

   Can you please tell me why does this method not work?

Thanks,
Sakthi

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 13 Oct 2003 13:19:30 +0200

Hi Sakthi,

Reflector partitioning as described in 4.3.3 point 2 It will not work 
when on any PE your import RTs and not part of the export RTs attached 
to vpnv4 routes.

Reason is very simple. 4.3.3/2 relies on PEs connected to a subset of 
RRs not all of them ! Therefor RRs build dynamically a list of 
"interested" RTs for all PEs connected to them. On the other hand in 
vpnv4 updates only exported RTs are carried. So RRs have no way of 
finding out what other RTs may be configured on PEs for import to 
include them in the list. This list is used to filter routes coming from 
other RRs. So if not all import RTs are advertised with vpnv4 routes 
(are exported) it is likely that some of the interesting vpnv4 routes 
will be dropped by such a RR hence not propagated to PEs.

I hope this is clear now. Also pls note that 4.3.3/2 could very well 
work when PE would "out of band" of vpnv4 routes signal his imported RT 
list to RR. That could be done by the use of ext community ORF or by 
rt-constrain idea: draft-marques-ppvpn-rt-constrain-01.txt

Rgs,
R.

 > Sakthivadivu.S.S wrote: