AlcaLu's Alwan: PBT Will Lose Its Shine

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 4 / 4

gbennett 12/5/2012 | 3:46:36 PM

re: AlcaLu's Alwan: PBT Will Lose Its Shine Hi desiEngineer,
I hear what you're saying. And no offence taken.

And you raise a couple of good points. If MPLS supporters like me are appearing to give ammo to the PBT cause I must be doing something wrong :-)

I like your reference to the cost of computing power. I remember the days when we thought OSPF would suck a CPU dry - or that a link state database would fill all the RAM on a router.

Of course Moore's Law - as it applies to both CPUs and to RAM chips - takes care of the problem faster than we can optimise code.

But when that's taken to extremes we end up with something like Windows - which is REALLY bloated :-)

MPLS as a data plane is as lightweight on a CPU as Ethernet switching. It's making the same one-pass decision vs longest prefix match for IP routing.

Yet Layer 3 switches cost more when they have MPLS on them! That, in my opinion, is a pricing decision.

Cheers,
Geoff

Reply | Post Message | MESSAGES LIST | START A BOARD

desiEngineer 12/5/2012 | 3:46:36 PM

re: AlcaLu's Alwan: PBT Will Lose Its Shine Geoff: "It's not for me to say what should be trimmed or even removed from MPLS to make it become a cost-effective transport technology."

Why not? You've got an opinion that it is bloated. You should say why.

Anyway, did you buy the first CD player ever to come to market? Or the first HD TV? If you did, you paid a spitload for it.

Likewise MPLS. MPLS is still a newbie in the provider world (the consumer world moves much faster). It's only been a couple of years since providers decided to move en masse to an IP/MPLS backbone with converged services (whatever that means). Actual implementation takes years.

The costs will come down. I mean, if you're lucky, you can buy a 10/100 NIC card for what it costs to buy a Kit-Kat bar. How'd that happen - Metcalfe's baby costs less than candy bar? (I think Kit-Kat is bloated - mebbe if you take out the chocolate and the creamy filling, it would cost a penny, be less fattening, and, ... oh wait, who wants to buy a candy bar that isn't sweet and fattening?)

I'm calling you on the Bloat argument for a reason. Bloat is the all-powerful argument for PBT (I eschew the term PBB-TE because that's just escapism).

I bet you could get a pathetic 800Mhz PC for next to nothing. Wait, I've got one and I'll give it to you for the cost of gas to my place. Nobody wants to go back in time.

Yeah it costs less, but PBT is one small step for Nortel, one giant step backwards for mankind.

Don't tell me all the excitement in the ccamp working group on who's going to be in the design team for signaled PBT isn't about to bring back the bloat you renounce.

Sorry, not trying to rip you, Geoff. You usually make good comments. Just want to clarify that the "loaded" bloat-that-isn't isn't going to give PBT-ers more ammo.

-desi

Reply | Post Message | MESSAGES LIST | START A BOARD

delphi 12/5/2012 | 3:46:34 PM

re: AlcaLu's Alwan: PBT Will Lose Its Shine Interesting dynamic on the thread. In my opinion bloatware has driven Moore's law. CPUs and memory had to become better because of bad coding practices. When you had 1K of memory on the switch card you made your code fit. When people believed that CPU and memory would always be unlimited they bloated.

It is just not MSFT that is guilty of this practice. MPLS is not a lump of clay. It is a code base just like DOS or any other platform. As much as you try to mould it there are still several pounds of clay at the base. It is that base that drags it down. Just like DOS anchored Windows, so does Windows anchor XP and Vista.

When the problem statement was multi-protocol routing over a commen infrastructure MPLS was the answer. When the probelm statement is setting up and tearing down connections based on dynamic traffic flows at a sub-lambda mux granularity what does MPLS offer?

There is no optical component to MPLS and the derivatives are incredibly poor.

desi -- you need to focus on the issues not on what your company is selling.

Reply | Post Message | MESSAGES LIST | START A BOARD

desiEngineer 12/5/2012 | 3:46:33 PM

re: AlcaLu's Alwan: PBT Will Lose Its Shine Delphi,

I'll focus on where I think I can solve the problems that I'm presented with, thank you very much. Oh, and I don't have a reaction to PBT just because my company pays me to - it's visceral.

It's easy to say that when you have a hammer, everything looks like a nail. But without some kind of reasonable plasticity of protocols, you're gonna have a bunch of lttle hammers, one for each nail.

I think MPLS has been remarkably malleable in adapting to the needs of providing a multi-protocol layer, a VPN infrastructure, a traffic engineered core, etc.

In fact, every one of those apps requires complementary protocols and algorithms to support the fundamental mechanism of labels. Basic OS theory: mechanism vs. policy. (Not that labels is a brand new invention.)

Case in point: the mechanism of labels is good for PWs and PBT doesn't need to invent a new mechanism. The policy (how the mechanism is deployed) is governed by the application and its associated protocols.

Sure, everyone knows carriers are taking a huge risk by moving to an all-IP/MPLS model, but they don't want to hammer away with little hammers.

There are clearly problems that MPLS isn't the answer to. But as long as I can reasonably solve the problems with MPLS, I will delight in using MPLS to solve them, and not because I was paid to do so, as you so crassly put it.

And then I'll move on to the next generation of protocols to solve the next generation of problems (which are the same problems we have now, but amped up). Hopefully, the level of elegance in the solutions will be upped (something profoundly lacking in PBT).

As the Wise One said:
What has been will be again,
what has been done will be done again;
there is nothing new under the sun.

BTW, I implemented IP/UDP/RIP/PPP/ethernet driver/and a bit more in 4K, so I know a little bit about confined spaces.

-desi
"I think I'll go to bed now." - Don Knotts

Reply | Post Message | MESSAGES LIST | START A BOARD

Mark Seery 12/5/2012 | 3:46:33 PM

re: AlcaLu's Alwan: PBT Will Lose Its Shine Geoff,

>> I see what you're saying about the "Ethernet address is always an Ethernet address", but I'm trying to imagine a situation where it would be advantageous. <<

IP/MPLS vendors are working on ways to address some of the currently identified issues, and may be able to do so [not clear to me yet - but they are looking in to it and engineers are talented people...] Anyway, some of the issues are embedded discussed on slide 24 on my presentation at this link:

http://www.ipmplsforum.org/pre...

>> Since Ethernet addresses have no structure (beyond the OUI) surely they're as abstract as a label? <<

An Ethernet address is more like a name than a topology address that you would pressumably get by what you are referring to. However, a name is as different to an abstact label as is a topology address (IMO). names are desireable for some things, topology addresses are desireable for some things, labels are good for other things (partitioning address spaces, service end points, links, etc). And as stated perviously, labels have another attribute that could be generically described as flexibility. There are many positive statements that provide insights before getting in to normative statements...pros and cons...would be interesting to work with protocols that had a mixture of capabilities(all things being equal like infinite processing capability etc...)

>> In fact they're not even guaranteed to be unique because they could be locally administered, just like a label. <<

Hmmm. If you operate your own network I would think there might be some control over that.

>> They could also be deliberately duplicated if there was a reason to do that. Most like a DoS situation I suspect. <<

Well would be prudent to consider that. If you are doing MAC-in-MAC how would this happen?

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 4 / 4