Experts call MPLS bad for 'Net
http://www.nwfusion.com/news/2001/0806mpls.html
Intersting read. This should start a nice long thread 
-Hank
I think its pretty well known that multiple routing tables, ala 2547-bis,
is not scalable. Apparently the author was fed the story and doesn't have
a clear understanding of the protocols of MPLS. To say MPLS is bad and write
a story about 2547-bis is a bit short sited. No mention of martini or any
other vendors besides the two exemplifies this even more.
andy
Randy and Vijay are completely correct - 2547 is nothing but bad news. The
comments about MPLS VPN security seem a little out of place - they could
easily apply to Frame relay, for that matter. And nothing is stopping folks
from encrypting anything they want. The story is quite good, though - the
vendors are pushing 2547, some in the service provider community are
listening, and they will end up regreting it. L2 MPLS VPNs, like CCC and
Martini will one day provide a very nice alternative to Frame and ATM, but
there is neither a market for, nor a scalable, safe way to deliver 2547.
- Dan
I agree that the article sorts of wanders a bit, but seems to
try and focus on the RFC2547 style of L3VPNs. While it seems clear that
the author does not have a firm grasp of the topic at hand, do you
honestly look for that in mass media? (I refer you to most publications
your typical "upper management" reads, if so).
  The remarks about RFC2547 is certainly salient. Most people are
trying to figure out how to deal with BGP routing - why multiply and
obfuscate the problem unnecessarily? Often I find myself in a position
where I fight to avoid implementing every trade-rag product/technology
du-jour on our network that well-meaning executives read about.
Particularly ones that seem to be unmanageable (don't go into debugging)
for even your smarter-than-average operator.
  MPLS is falling into the same traps that ATM did. Remember
those heated discussions of how IP was going to be made obsolete because
everyone was going to be running ATM to everywhere? As I remember, MPLS
was originally done as a performance enhancement - controlling MPLS
wound up with the side-effect of being able to manage bandwidth. The
telephone execs that control large portions of the Internet seem
hell-bent on re-implementing what they know and are familiar
with (circuit switching). Ultimately it fails, because it is a flawed
model for data communications.
  We did not, however, throw out ATM altogether because the
Internet did not become a cross-stitch of ATM SVCs - we do, however, use
it where applicable. The article fails miserably in that it appears to
condemn MPLS along with the L3VPN model proposed under RFC2547 (and its
successor). I believe that RFC2547 and its ilk will ultimately collapse
under it's own lumbering weight - however I do remain a fan of MPLS when
used appropriately.
  In the meantime it remains an irksome fact of life that I have
to continue to "explain" to people that L3VPNs (a la 2547) are a bad
idea to people that don't understand packet switching. Too bad, I
would've liked to have used this article as part of that ammunition.
  To date, my best ammunition has been vendor's "seminars" on how
to implement L3VPNs -- when they spend four hours giving "a brief
overview" of it, even the most clueless have to have concerns about the
operational aspects.
              - Tom
>
> Experts call MPLS bad for 'Net
>
> http://www.nwfusion.com/news/2001/0806mpls.html
>I think its pretty well known that multiple routing tables, ala 2547-bis,
is not scalable. Apparently the author was fed the story and doesn't have
a clear understanding of the protocols of MPLS. To say MPLS is bad and write
a story about 2547-bis is a bit short sited. No mention of martini or any
other vendors besides the two exemplifies this even more.andy
-- --
Thomas P. Brisco tbrisco@globix.net
Senior Network Architect 212-625-7073
Globix Corp.
   Q: A priest, a rabbi, and RFC2547bis are on an airplane. During
the flight, the plane encounters a storm and crashes. How many people
die?
Randy and Vijay are completely correct - 2547 is nothing but bad news.
Right.
The
comments about MPLS VPN security seem a little out of place - they could
easily apply to Frame relay, for that matter. And nothing is stopping folks
from encrypting anything they want. The story is quite good, though - the
vendors are pushing 2547, some in the service provider community are
listening, and they will end up regreting it.
Why?
L2 MPLS VPNs, like CCC and
Martini will one day provide a very nice alternative to Frame and ATM, but
there is neither a market for, nor a scalable, safe way to deliver 2547.
Really. Based on what sort of market research and backup material?
[..]
I think it's pretty well known that the point you mention is FUD. Besides,
it's not really intended to be 'multiple tables' with multiple instances of
routing processes.. it's an indexed table run by the same routing process.
Take a look at the mpls@uu.net archives for a rather exhaustive and exhausting
discussion of this very subject, or provide facts as to what specifically
doesn't scale.
Logic says that not seeing the routes at all, a la layer-2 tunnels, is
going to scale *better* then having your routers deal with them at all.
Less routes/resources=greater scalability.
andy
Take a look at the mpls@uu.net archives for a rather exhaustive and
exhausting discussion of this very subject, or provide facts as to what
specifically doesn't scale.
to paraphrase vijay, if dealing with one rib is a major discussion in the
operator and ietf communities, how many thousands of them do you think a
prudent operator wants to deal with in 2547?
did you notice all those extra *e routers with 2547? do you wonder why
router vendors push 2547?
randy
I really wanted to reply... "Logic says you need to check the facts before
posting such nonsense." .. but that would be a flame. Let's try this instead:
In an RFC2547(bis) MPLS-VPN, the edge doesn't neccessarily need to see all the
routes at all. All the PE does need to know is enough for the two CE's to
communicate with each other. This can be a static route, this can be a summary
route. So, if you get another, say 3000 routes for 1000 customers, this is
really going to be that much of a scaling problem? In fact, if your customers
build BGP sessions etc between their CE's, the routes carried by the PE's are
very skinny.
So, you're going to try to tell us next that n^2 tunnels scale better and are
less of an operational nightmare at scale than the connectivity provided
inside of an MPLS-VPN?
Have you ever actually used the code yourself?
> Take a look at the mpls@uu.net archives for a rather exhaustive and
> exhausting discussion of this very subject, or provide facts as to what
> specifically doesn't scale.to paraphrase vijay, if dealing with one rib is a major discussion in the
operator and ietf communities, how many thousands of them do you think a
prudent operator wants to deal with in 2547?
I think you're blowing this completely out of proportion like it has happened
on mpls@uu.net before.
A PE carries only the routes needed at a specific PE depending on the VPNs
present at a specific PE. The routes aren't kept in a seperate rib, what
happens is that a meta rib is created which indexes all rib entries based on
their origin. Sounds a lot more complicated but it is in essence something
like this:
128.10.0.1.0
129.10.0.1.0
129.10.0.2.0
130.10.0.1.0
130.10.0.2.0
130.10.0.3.0
They're called VPNv4 routes, consisting of IPv4 routes and the index (with
128, 129, 130 being the index.. ). It's still just one rib. Provided all
those RD's are present at the same PE.
So, how many thousands of suitable MPLS VPN customers do you have for this
to amount to much?
Again, there has been an exhaustive discussion of this on mpls@uu.net many
moons ago, and for you specifically to rehash this issue in another forum
again is rather curious to me.
You couldn't win the argument in IETF MPLS, and now it's being dragged to
NANOG?
did you notice all those extra *e routers with 2547? do you wonder why
router vendors push 2547?
If the shoe fits, why not?
MPLS VPNs solve a very specific set of problems. If you don't like because it
doesn't fit your operational model, don't use it. But this sort of generic
bashing and FUD leads nowhere.
A PE carries only the routes needed at a specific PE depending on the VPNs
present at a specific PE.
and five years out, what percentage of my O(10-^6) vpn customers will have a
branch in each of (chicago|nyc|sf|.*)?
randy
Randy,
and how should I know? ;-).. I'm a) lacking a functional crystal ball (a magic
8 ball is my only ball shaped engineering tool) and b) they'll presumably be
still your customers and not mine! 
Seriously, what point are you trying to make? There are several ways to
interpret the statement.
Thanks,
Chris
You couldn't win the argument in IETF MPLS, and now it's being dragged to
NANOG?
(....)
I really wanted to reply... "Logic says you need to check the facts
before posting such nonsense." .. but that would be a flame.
Life would be much better if grocery stores didn't exist.
Men could obtain the power, gratification and recognition they need thru
killing something, rathing than sending email.
Randy,
5 years from now you will see routers from multiple vedors allowing you
to store & process orders of mangnitute of more routes. As a matter of
fact if you have so much routes - you as an opertator should only be
happy - as it means you are selling your new service and erning more
money.
Besides for those individuals who have problems with maintaining a
sinlge RIB with IGP routes I would higly advise a caution in deploying
an mpls-vpn service or even touching the routers :).
R.
I really wanted to reply... "Logic says you need to check the facts before
posting such nonsense." .. but that would be a flame. Let's try this instead:
So good of you to show restraint. Your awfully assuming that no one else
has as much MPLS knowledge and experience as you. Try to maintain the
conversation without "asserting yourself" at the beginning of each
response.
In an RFC2547(bis) MPLS-VPN, the edge doesn't neccessarily need to see
all the routes at all. All the PE does need to know is enough for the
two CE's to communicate with each other. This can be a static route,
this can be a summary route. So, if you get another, say 3000 routes
for 1000 customers, this is really going to be that much of a scaling
problem? In fact, if your customers build BGP sessions etc between
their CE's, the routes carried by the PE's are very skinny.
"Doesn't neccessarily"..."if"...
Scaling is looking ahead and considering how it could grow. Your going to
have to do *something* on each PE, I think signalling a tunnel and being
done with it is better.
So, you're going to try to tell us next that n^2 tunnels scale better
and are less of an operational nightmare at scale than the connectivity
provided inside of an MPLS-VPN?
I think so. I'm sure either will work in its element. Obviously you don't
agree, we can leave it at that.
Have you ever actually used the code yourself?
"the code"? Assuming you mean have I setup L3 VPNs, yes, but you can
refer to my first comment.
andy
It isn't quite the individuals who are having problems maintaining a single RIB with IGP routes, it looks like the software is having trouble keeping its sanity. Seeing that it took ~ 12 months to track down some iBGP withdrawl bugs and a single fence post error in an AS path sanity check took down a significant portion of the internet, I suggest perhaps one must first put ones own house in order before going out and throwing stones at others.
thanks
/vijay
Vijay,
I am not defending IOS bugs or any particular implementation - I am
defending the architecture.
R.
> I really wanted to reply... "Logic says you need to check the facts before
> posting such nonsense." .. but that would be a flame. Let's try this instead:So good of you to show restraint. Your awfully assuming that no one else
has as much MPLS knowledge and experience as you. Try to maintain the
conversation without "asserting yourself" at the beginning of each
response.
There is such a thing as sarcasm. Geez.
Scaling is looking ahead and considering how it could grow. Your going to
have to do *something* on each PE, I think signalling a tunnel and being
done with it is better.
If all you're building is a small amount of point to point VPNs, sure.. At a
large number of VPNs and complex VPN topologies (better than p2p), I think
there are some very distinct advantages.
> So, you're going to try to tell us next that n^2 tunnels scale better
> and are less of an operational nightmare at scale than the connectivity
> provided inside of an MPLS-VPN?I think so. I'm sure either will work in its element. Obviously you don't
agree, we can leave it at that.
I think the point I'm trying to make is this. People keep saying that
RFC2547(bis) implementations won't scale, when the funny part is that they
really don't become terribly useful unless used at scale. Many of the
advantages aren't realized at small scale.
And, I'd rather have a thousand prefixes than a thousand tunnels across my
network. But, that's also with the premise that I'm working on building a
very large, complex customer topology VPN infrastructure from the outset.
But, the point you're hitting on is absolutely appropriate. MPLS-VPNs aren't
a solution for everything, and neither are tunnels. It very much depends on
your customer's needs, on your topology etc. Global bashing of either is
inappropriate.
And at very large SP scale, I think the overhead and inflexibility of tunnels
isn't acceptable. If that's all I want, I might just as well buy tons of
FR/ATM.
Tunnels will always happen. It's something any customer can do on their own.
In my opinion, if what they're looking for is a large scale managed VPN, the
options of topology & traffic management in MPLS-VPNs outweigh those of
tunnels.
> Have you ever actually used the code yourself?
"the code"? Assuming you mean have I setup L3 VPNs, yes, but you can
refer to my first comment.
Please don't be ridiculous. The point was that it is incomprehensible to
me how some of the statements are made about MPLS-VPNs if you've actually
touched the stuff and worked with it. All too many people comment on this
stuff with mere book knowledge. That was the point, and no more.
Cheers,
Chris
Randy,
For me you can complain to vedors that they make crappy boxes which
don't do what you need. That is fine and I will not say a one bad word
against it.
On the other hand I (helping to deploy mpls-vpns around the world for a
few years in a number of networks including these days even your ATT)
just can't watch stating that the arcitecture of 2547 is screwed only
because current platforms don't scale 5 years ahead.
R.
And on some agricultural list somewhere, they're discussing the proper
way to raise a sheep. If there's all that discussion about how to
raise one sheep, who wants to deal with a flock? Once you know how to
deal with one big table, dealing with a bunch of tiny, simple tables
is pretty easy, especially since, once you build them, they mainly
take care of themselves.
This really isn't that much to it, folks. If you're very brave and
very careful, you can let your customers handle their routes.
Otherwise, you can statically route to them. If you don't want to
handle all those routes in your VPN networks, how many more plain IP
customers are you going to handle? Configuring routing for an RFC
2547 MPLS VPN is not really much harder than configuring a plain IP
customer. It can certainly be automated just as easily.
Perhaps the issue here is, the folks arguing against the complexity
are targeting their arguments on the people who really don't need to
worry about it: the small network operators, who have a small support
staff trying to run a BGP-enabled network. These guys might be MPLS
VPN customers, but there's no need for them to be providers. To leech
another person's metaphor here, the argument is that a 747 is too hard
for your average pilot to fly. Fortunately, your average pilot
doesn't have to fly it.
-Dave