Re: MPLS VPNs or not?

[Robert Raszuk <raszuk () cisco com>]

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. 


> Vadim Antonov wrote:
>
> On Wed, 8 Aug 2001, Yakov Rekhter wrote:
>
> > 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.
>
> 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 :)
>
> 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