MPLS VPNs or not?

Vadim,

Yakov, that was not nice.

If you look at the "opposition" side you'll see quite a lot of people who
had to run real backbones; and who have a feeling of impact featurism has
on reliability of code. For what it worth, nothing makes you appreciate
simplicity and quality as getting dragged out of bed in the middle of the
night to fix backbone falling down in flames because of yet anothing
interesting glitch caused by the flaky but feature-rich software.

My position was always consistent - if you can do something (like VPN) at
the edge boxes w/o inroducing complexity into core transport, this is the
way to do that.

Then to be consistent with your own position, you certainly should agree
that 2547 is "the way to do" VPNs, as with 2547 all the VPN-related
information is confined to the PEs (where "PE" stands for provider *edge*),
and none of the P (core) routers maintain any VPN-related information.

Yakov.

Ghm. Unless you do not count MPLS labels as routing information, that's
it.

  "All that matters for the VPN architecture is
   that some label switched path between the router and its BGP next hop
   exists." [sic]

I particularly liked discussion of using border routers for inter-AS VPN
routing. These are precisely the ones which are usually in deep poo-poo
in case of any routing instability.

  "PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to
   insert /32 address prefixes for themselves into the IGP routing
   tables of the backbone. This enables MPLS, at each node in the
   backbone network, to assign a label corresponding to the route to
   each PE router. (Certain procedures for setting up label switched
   paths in the backbone may not require the presence of the /32 address
   prefixes.)"

I hope i understood that right. Inserting _any_ additional stuff into
backbone IGP is pretty much close to suicide. The first rapidly flapping
circuit or box will get your backbone crash and burn. How many PE routers
are attached to a typical backbone? What is the probability of one of them
going banana (or getting a loose cluster LAN connection, or a flap attack
from _within_ customer VPN, saturating its processor to the point that it
loses backbone IGP timeouts? I.e. all it takes to kill the backbone is
one smartass with gated on his workstation - insides of VPNs are not known
for stringent filtering of routing information).

A good rule for a backbone operator is to have _only_ core routers (not
customer access concentrator boxes) to participate in IGP, injecting one
prefix each, to hang iBGP mesh off. (As a side note - does anyone do flap
damping in IGPs?) That was the reason why i asked Paul and Tony to make a
knob to allow preservation of next-hop addresses in border BGP routers in
the first place (yep, and to hang off all those tiny AS-es off 1239 :slight_smile:

Handwaving, Yakov. Saying that 2547's VPN routing information is confined
to PEs is a case of selective vision. _Interior_ VPN information is
hidden, yes, but exterior of VPNs is quite visible. And in the words "this
enables MPLS, at each node in the backbone network, to assign a label
corresponding to the route to each PE router" are hidden all those teeny
weeny label information exchanges, which have to happen every time IGP
hiccups.

Compare that with tunnelled or NAT-based VPNs which do not force backbone
boxes to do anything but native IPv4 routing; and, yes, allows them to
aggregation, too. And it does not require cross-provider exchange of /32s
or any new bugs in BGP engines.

What i see is an attempt to drag in new features to solve a problem which
was adequately solved years ago in ways which do not contribute to core
network instability. 2547 is a neat idea, but falls short of criteria of
being safe and absolutely necessary to deliver VPN service. Sometimes
older ways are simply better.

--vadim

Vadim,

While trying to parse your mail I am really not sure what are you trying
to smash here. Is it 2547 or is it MPLS LDP based LSPs ? Please notice
that while they may be seen as coupled today that is not the necessity.

Could you clarify ?

Also I find it interesting that for some providers those "teeny weeny
label information exchanges" in the core make it much more stable and
solid as full mesh of ipv4 ibgp there becomes no longer a requiremnt.

R.

PS. Yes mutlicast RPF breaks when you disable full ipv4 ibgp but you can
add a subset of this full table via Multicast BGP and still save on
router's RIB/FIB sizes significantly.