MPLS VPNs or not?

Christian,

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.

That would be a rational position, but it can't be accepted by the
folks who have a fairly irrational attitude about the subject. These
folks are of firm opinion that they know how things should be
done, and moreover, their way of doing things is the one, and *only*
one way of doing this.

In the absence of any rational arguments (like the case we
have at hand), the only thing these folks could use to justify
their dogmas is generic bashing and FUD.

Yakov.

That would be a rational position, but it can't be accepted by the
folks who have a fairly irrational attitude about the subject.

love those ad hominem arguments by the desperate in the defense of clearly
non-scalable technology. will ad homina be part of 2547bis?

Nice shot, Randy! :wink:

If it is so clear, how about engaging in a discussion and providing a rationale
and reply to those who say it ain't so? If you can provide solid arguments
disproving the arguments of those who think it is scalable, I think it would
be very easily put to rest.

2547bis may not be a fit for your vision/problem. However, that's entirely
seperate argument from whether or not it is scalable.

Cheers,
Chris

The sad thing here is, you repeated what the complaints are about
in your reply: specifically, you keep telling us it is "clearly
non-scalable," but you also fail to tell us why.

So:

1) 2547bis requires configuration at the ends only, just like any
   other IP service in a properly configured network.

2) The routing descriptor space is larger than the IP space, so it
   does not present a limiting factor.

3) The BGP mesh requirements are the same as for any other BGP-aware
   network (barring implementation issues, which are not a problem
   with the protocol itself.) The additional configuration can be
   as static or as dynamic as any other IP service.

4) The memory requirements for the additional routes are the same
   as for any other IP routes, plus a little overhead for tracking
   the routing table. This additional overhead does not appear
   to be significant.

Therefore, I would say that 2547bis is clearly scalable, or at least,
as scalable as internet IP service.

-Dave

If it is so clear, how about engaging in a discussion and providing a
rationale and reply to those who say it ain't so? If you can provide
solid arguments disproving the arguments of those who think it is
scalable, I think it would be very easily put to rest.

are you running it on the same routers as your main backbone? is it
simpler or (someday please, oh godded) less code? tell your bean
counters how scalable it is.

and don't give me the bumph about provisioning costs. any transit
and/or vpn vendor that is not completely auto-configured knows the
deepest, darkest, most horrid, and expensive truth about non-
scalability.

randy

Randy rants:

> If it is so clear, how about engaging in a discussion and providing a
> rationale and reply to those who say it ain't so? If you can provide
> solid arguments disproving the arguments of those who think it is
> scalable, I think it would be very easily put to rest.

are you running it on the same routers as your main backbone? is it
simpler or (someday please, oh godded) less code? tell your bean
counters how scalable it is.

and don't give me the bumph about provisioning costs. any transit
and/or vpn vendor that is not completely auto-configured knows the
deepest, darkest, most horrid, and expensive truth about non-
scalability.

Ch vs R: 2:0

Randy, still no arguments,

-- Arnold

are you running it on the same routers as your main backbone? is it
simpler or (someday please, oh godded) less code? tell your bean
counters how scalable it is.

and don't give me the bumph about provisioning costs. any transit
and/or vpn vendor that is not completely auto-configured knows the
deepest, darkest, most horrid, and expensive truth about non-
scalability.

Ch vs R: 2:0

Randy, still no arguments,

the depth of your argument is impressive

>
> Ch vs R: 2:0
>
> Randy, still no arguments,

the depth of your argument is impressive

still same to you. Maybe I know less about MPLS than you. Sure I know less
about MPLS than Christian. But Christian was more impressive than you!
That's it!

-- Arnold

Is someone running this? pls resond privately,

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. "Intelligent networks" is a _bad_ idea.

Also note that in the backbone world, no operator is protected from
other's stupid decisions. That's why promoting good practices is a
necessity, not just a religious argument. Otherwise wily Randy would
heartily advise everyone else to switch to X.25 running on top of ATM :slight_smile:

--vadim

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.

It is all right. Eventually they will get a correlation between their errors
and missed earnings.

Alex

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. "Intelligent networks" is a _bad_ idea.

Not entirely.. Keeping the features and misc. cruft on the edges of
the network is a good thing. However, as the edge becomes more
intelligent, the core has to adapt to service it. This often cannot be
done without adding intelligence into the core. This does not mean
that the core should be a participant of the newest and greatest
feature but should know about the established features in order to
optomize overall function. (eg, multicast.. the core knows about it,
but makes no decisions other than routing and replicating
packets... It does what it is told. All the rest is handled at the
edge and at the RP.)

Also note that in the backbone world, no operator is protected from
other's stupid decisions. That's why promoting good practices is a
necessity, not just a religious argument. Otherwise wily Randy would
heartily advise everyone else to switch to X.25 running on top of ATM :slight_smile:

--vadim

These good practices, of course, have to start at the vendors. This is
an area that has been lacking in recent years. (silly defaults, code
that gets pushed into production before its ready because of marketing
schedules, etc.)

-Wayne

However, as the edge becomes more
intelligent, the core has to adapt to service it. This often cannot be
done without adding intelligence into the core. This does not mean
that the core should be a participant of the newest and greatest
feature but should know about the established features in order to
optomize overall function. (eg, multicast.. the core knows about it,
but makes no decisions other than routing and replicating
packets... It does what it is told. All the rest is handled at the
edge and at the RP.)

Funny that you choose multicast as an example. I always thought that it
is a very rotten idea, and a security nightmare, too.

Distributed transparent caching does not require injection of any routing
information from customers into the core routing, and is a lot more
efficient than multicasting (i.e. you can always think of multicasting as
a caching with cache retention time set to nearly zero).

These good practices, of course, have to start at the vendors. This is
an area that has been lacking in recent years. (silly defaults, code
that gets pushed into production before its ready because of marketing
schedules, etc.)

Recent years? :slight_smile: ROFL :slight_smile:

--vadim