Subject: route targets and IBGP in mpls VPNs

From: "Andrew Bartholomew" <[email-masked]>
Date: Wed, 10 Jan 2001 07:47:42 -0000

If I understand draft-rosen-rfc2547bis-02.txt  properly I believe some
clarification of the use of route targets would be helpful.

My understanding is that route targets are used to control the flow of
traffic within a VPN, rather than have a full mesh of routes between PEs.
However, the "hub and spoke VPN" and the "firewall in an extranet" examples
given in the draft suggest that all PEs do have routes to all parts of the
VPN, just indirect ones in some cases.

Specifically, in section 1.5 of the draft, the "firewall in an extranet"
example, it says

"This means that it needs to be possible to set up two routes to the
   server.  One route, used by sites B and C, takes the traffic directly
   to site A.  The second route, used by site D, takes the traffic
   instead to the firewall at site B.  If the firewall allows the
   traffic to pass, it then appears to be traffic coming from site B,
   and follows the route to site A."

This gives rise to the issue of IBGP speakers propagating updates received
from one IBGP peer to another, something not normally allowed in IBGP, and
also begs the question when such an update should be propagated, to avoid
incorrect updates flooding the VPN.

One could add a rule that if a PE router R installs a route with an export
RT set S, and the corresponding VPN has an export RT set E (at R) such that
E-S is not empty, then the route should be propagated by R with itself as
the BGP next hop and with export RT set E-S.

This route should only be considered by other PEs in the VPN who do not have
an element of S as an import RT, since those that do should use the direct
route rather than the one propagated by R.  But, I do not see how other PEs
could determine whether a route had been propagated or not without an
explicit indication in the update from R.

If propagation of routes between IBGP speakers is not allowed then some
sites in a VPN will be unable to reach certain destinations without
management intervention - is this really the intention?

Regards,
Andrew.

--
Andrew Bartholomew

Layer 8 Consultancy                      Observa et sapiens cresces.
Services Limited                             

Tel:   +44 1202 558409
Fax:   +44 1202 556748
Email: [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 09 Jan 2001 23:31:05 -0800

Andrew,

RTs do allow you to control the distribution of routes within each VPN
among routers participating in the VPN. 

> incorrect updates flooding the VPN.

The propagation of IBGP updates is done only in route relfectors. The
principles of bgp do not change at all.

> VPN, just indirect ones in some cases.

Let me give you a small example how hub and spoke would work. Considers
three PEs: PE1, PE2 & PE3. Let PE1 be the PE connecting hub site and
PE2/3 the PEs connecting the spoke sites. In the VRFs of PE2/3 you will
find only local routes and the default out to PE1 hub site. Setting the
right RT combination allows you to easily achive this. 

I am not sure what do you mean by "indirect routes" ??? I am only
guessing that what you meant to say all the routes but only with
different next hop (for example pointing at hub PE). If so no as you see
from the above example default to hub site is what most spoke sites
would use to get out.

R.

> Andrew Bartholomew wrote:
>