MPLS VPNs or not?

Wed Aug 8 12:42:20 UTC 2001

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Actually I think I find myself agreeing with both of these
viewpoints.  

When MPLS first launched everyone was hyping what a massive speed
increase it would have through your network which has been proved to
be a load of rubbish.  However I do believe that it has some useful
applications and deploying it as an enabler technology across your
backbone may not be a bad thing - infact certain features (i.e.. fast
reroute) are a good thing in certain topologies.

Many of the "applications" that are being (note I say are being as
they don't work well enough yet!) developed i.e. L2 and L3 VPNs may
well be, in the future, very handy and very sought after services to
sell to your clients but currently there are just too many flaws to
really consider (in my opinion - and from experience) deploying them
in anger.

In the future I have no doubt that routers and vendor code sets will
be able to cope with the strains and stresses these "features" place
on them but at the moment the abilities to deploy, provision and
support these applications are just not viable on a large ISP/carrier
backbone.  This is backed up by my inherent dislike of offline
provisioning/management tools which many vendors are recommending for
L3 VPN provisioning on a large scale.

The other debate you often find yourself in is the "do we use LDP/TDP
to dynamically distribute labels and create LSPs or do we statically
(RSVP) define LSPs"?  Both have their advantages and it depends on
your network, traffic topologies and congestion levels but if your
network is in good shape then my personal opinion is that I'd plump
for LDP anytime as I'm not a fan of the Telco/ATM theories of
creating a large PtP mesh network.

Anyways - just my 2 cents.

James

- -----Original Message-----
From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu]On Behalf
Of
Neil J. McRae
Sent: 08 August 2001 08:31
To: Daniel Golding
Cc: Craig Partridge; davei at biohazard.demon.digex.net; nanog at merit.edu
Subject: Re: MPLS VPNs or not?

Daniel,

> The scary thing is that the "speed" of MPLS-based networks is taken
> as gospel by an alarming number of engineers, mainly those who have
> come out of the large telco's (i.e. ILECs), and are still kind of
> mad that ATM didn't work out. These folks are more or less alarmed
> by IP, and desperately seek a more deterministic, switch-based
> model of data transmission for the Internet as a whole. The fact
> that there is no practical, real-world difference in forwarding
> speed between straight IP, and IP over MPLS is generally explained
> away by these guys in a fairly elaborate handwaving exercise. At
> least one major hardware vendor is not helping this, with some of
> their engineers convincing major customers that conventional IP
> routing is bad, and that anything MPLS is good. While I agree that
> MPLS has it's uses - i.e. TE as an exception handling mechanism for
> outages, and L2VPN technology as a FR/ATM replacement, some folks
> need to approach the technology with additional caution, and not
> blindly embrace it as a panacea. As the internet engineering
> community evolves, learning from things like ATM, becomes quite
> important.
> 

Too true! Whats scary is that product "managers" believe the hype,
and
you get into discussions about how MPLS can enable "application based
QoS" because some sales "engineer" [WTF is that anyway?] at a vendor 
conference has waffled on about it and how well it works.
What isn't provided at these conferences are the realities in
deploying it, or any real life examples of an application, and also
finding some dumg idiot thats willing to pay for it when he can
buy something else [ATM/FR/SDH/PDH] at fraction of the price isn't
clear either. Oh and that the router supports these features in:
3.fixed3bugs.added14others.4.hohoyoureatotalnutterifyourunthiscode.1
and that the management system will be able to manage these features
in q4 of 2010 which , "but no we won't commit to that" and isn't our
CLI
wonderful.

Some of the VPN/VRF functionality clearly isn't deployable in a
scalable
manner [atleast my definition of scalable], I think one of the
solutions
to scaling is to deploy multiple sets of route-reflectors to manage
routing updates for different services. One set for Internet, one for
high
level service, and one for low etc. That, to me, isn't the definition
of
scaling and the minute you get a customer who wants to cross the
boundaries
of this setup you are screwed.  

The other thing that is worrying is how many telco dinosaurs have
come out of their hiding places claiming to be gurus on all things
IP and MPLS because to them it looks like a telephone switch. These
people will cause you to lose hair - either trying to get a word in
edgewise or trying to fix the abortive "designs and solutions" that
they have "engineered". Be afraid!

Regards,
Neil.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBO3EzqTyrtEQtecfwEQJKxgCgwTi5I59IBNGkrO9JYpUBhgcDc6MAoPnv
8uvAwe9Ug43ExKb12sVSA0eq
=/GEb
-----END PGP SIGNATURE-----