The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jan> msg00108



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

route targets and IBGP in mpls VPNs

  • From: "Andrew Bartholomew" <Andrewb@layer8.co.uk>
  • Date: Wed, 10 Jan 2001 07:47:42 -0000
  • Importance: Normal
  • X-MDaemon-Deliver-To: mpls@uu.net

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: Andrewb@Layer8.co.uk