x
<<   <   Page 2 / 4   >   >>
digits 12/5/2012 | 3:47:02 PM
re: AlcaLu's Alwan: PBT Will Lose Its Shine Munster
Reliable delivery of packets from A to B.... that appears to be the end goal.

But you appear to have hit the nail on the head with your comment - you said:

"Perhaps the need is just for a reliable transport, like SONET/SDH..."

Indeed - *like* SONET/SDH, but *not* SONET/SDH, it seems.
That's why PBT is being touted as the carrier Ethernet equivalent (theoretically) of SONET/SDH in terms of its management capabilities.

That's why this debate is rumbling on and on -- there's a battle for the next gen transport $$$.

Ray
CardinalX 12/5/2012 | 3:46:58 PM
re: AlcaLu's Alwan: PBT Will Lose Its Shine A dose of lactobacillus acidophilus isn't going to change MPLS. Its strength as a general purpose packet forwarding mechanism is also its weakness, that is it uses a label with variable semantics. Where as PBB-TE does not claim to be general purpose and uses labels with fixed semantics.
We are all used to the trade offs between using general purpose mechanisms and specialist mechanisms. If MPLS was so good it would have replaced Ethernet by now, just like ATM nearly didn't.
delphi 12/5/2012 | 3:46:58 PM
re: AlcaLu's Alwan: PBT Will Lose Its Shine Geoff,

Sorry for the late reply to you very good post. Air travel on the east coast---

Any way you have very valid points. However, MPLS is as you have pointed out developed for layer 3 and above for packet routing and switching to handle a variety of packet formats and protocols. What makes it good for Layer 3 makes it cumbersome, complex, and expensive to implement and operate for layer 2 transport.

If you believe carrier ethernet will become the standard for layer 2 transport then what you need is a control layer which is connection oriented and flow friendly vs. connectionless and packet. PBT works at the MAC layer to establish connections across a transport layer and already has the features required for layer 2 switching and transport. MPLS , T-MPLS, G-MPLS all are incredibily difficult to set up and operate at the layer 2. Most of the carriers I work with have come to this conclusion on their own. The majority have concluded that MPLS and its derivatives increase the overall cost of operations without any tangible value add benefit to offset those additional costs.

Ethernet has been around longer than any other technology and PBT and its derivatives offer the most robust and cheapest layer 2 switching and transport solution. I believe that a IP/MPLS layer 3 services network interoperating with a PBT/Ethernet Layer 2 transport network architecture is the best of both worlds.

I have always been cautious with a one size fits all solution. Just as when everyone said IP uber alles because bandwdith would be free (John Chambers in the 90s), and prior to that it would be CMIP/CMISE/ATM.

When all you have is a hammer, everything must be a nail.

leue 12/5/2012 | 3:46:57 PM
re: AlcaLu's Alwan: PBT Will Lose Its Shine HI Delphi,

Quote "I believe that a IP/MPLS layer 3 services network interoperating with a PBT/Ethernet Layer 2 transport network architecture is the best of both worlds."

What do you think about the OPEX if you are running both world's - PBT and IP/MPLS together?
You have to deploy and maintain
(QoS-Domains, TE, OSS/FCAPS, Staff) for both worlds - means the OPEX will be doubled?

And whats about if you want enable new futures in your network - you have to ensure that both architecture will fullfill all the requirements (proof of concept, testing, rollout). So the intial cost for the deployment of new services may be doubled as well?

Some providers will eliminate the Transport-Layer (SDH/SONET) for their IP/MPLS-Traffic to reduce their OPEX costs. Then they replace the SDH/SONET-layer with PBT - have you really then decreased the OPEX?

just my 2 cent,
marcel

delphi 12/5/2012 | 3:46:56 PM
re: AlcaLu's Alwan: PBT Will Lose Its Shine I believe it is better to have 2 discrete network service and control architectures vs. the 3 to 5, and sometimes more in place today. Trying to get one to cover all will be more difficult and expensive, both in development and ongoing opex. If you had one architecture for layer 0 to 2; and another doing layer 3 and above it would allow for focus and innovation for services (IP/packet) solutions and for transport (Ethernet/connections) solutions without trying to boil the ocean.

Just getting down to two solutions will take time and a lot of effort. Once down to two solutions you can also develop each part of the network with some level of separation. That is you can develop your IP services separate from you Ethernet transport network. I believe this has a lot of value for future services and network design and deployment.

As you said it is an opinion and mine may not worth 2 cents!! It just seems that many of the large carriers are going this way.
gbennett 12/5/2012 | 3:46:49 PM
re: AlcaLu's Alwan: PBT Will Lose Its Shine Hi CardinalX,

You said: "If MPLS was so good it would have replaced Ethernet by now, just like ATM nearly didn't."

Disclosure. I worked at Proteon (Token Ring vs Ethernet), and at FORE (ATM vs Ethernet) and so I have first hand experience of trying to pitch a competing technology against Ethernet's ubiquity, longevity, adaptability and simplicity. Having tried to market against Ethernet (not because I wanted to, but because the companies I worked for had that as their strategy) I'm very aware of the advantages of Ethernet and I'm a strong believer in its future.

But why do you see the argument as "MPLS vs Ethernet"? MPLS can't displace Ethernet because MPLS isn't a Layer 1/2 technology. My PC doesn't have an "MPLS port". MPLS is just a shim header inserted between Layers 2 and 3. I think this is one of the reasons why Layer 2 folks have such a problem with MPLS, while they seem to be quite happy to extend the Ethernet labelling scheme using MAC-in-MAC stacking.

MPLS labels don't really have "variable semantics" - rather they have "context-dependent semantics". In other words, when an LSR receives a labelled packet it knows based on the label value what to do with that packet. It knows if this packet is part of a Layer 2 VPN, a Layer 3 VPN, a provider-provider tunnel, an internal TE tunnel, etc. Within a given context - like a Layer 2 VPN - the semantics of the label are locally administered (ie. exactly the same as PBT).

So in that respect both MPLS and PBT have context-dependent label semantics.

By the way, I also have a problem with arguments that begin "Ethernet vs IP". You have to have both. In fact, in any siginificant service provider network you need Ethernet, MPLS and IP all working together.

Cheers,
Geoff

leue 12/5/2012 | 3:46:49 PM
re: AlcaLu's Alwan: PBT Will Lose Its Shine Hi Delphi,

I agree with you that for large carriers it should be better to go to 2 discrete network architectures.
As you pointed out correctly many of LARGE carriers are going this way.

But what's happen if you are a smaller Service Provider (e.g. in Switzerland) - so "the size matters" as well the services the SP is providing matters. Then you may have more CAPES/OPEX if you are running 2 networks. Means each SP or Carrier have to choosen the network architecture and technology for itself.

But it seems that the manufactores are not aware of that - the spend more energy in the MPLS vs PBT war instead of make the integration and interop of both world easier.

regards,
marcel







gbennett 12/5/2012 | 3:46:48 PM
re: AlcaLu's Alwan: PBT Will Lose Its Shine Hi delphi,

I totally agree with you. For most service providers the problem is to collapse 4 or 5 legacy infrastructures onto "a smaller number".

Where I start to disagree with you is that the idea of having an "Ethernet infrastructure" and an "MPLS infrastructure" is, ipso facto, a lower cost solution.

Ethernet is a great service offering for carriers. It works in the enterprise, and it's increasingly displacing ATM from the DSLAM "inwards" in the residential broadband network. That's great news because, apart from anything else, Ethernet is getting faster (in contrast to, say ATM, which isn't) and faster is very, very good!

If you look at the way carriers are architecting these "smaller number of network infrastructures" you see that the two or three infrastructures they choose are:

- An MPLS network for private data
- An MPLS network for residential broadband
- An MPLS network for VoIP

Some carriers are dabbling with the idea of managing local, Ethernet-delivered circuits using "something simpler than MPLS". But ultimately those circuits have to be transported over an MPLS core.

I don't think the problem with MPLS is complexity at all. I think the problem is that the major MPLS vendors retain huge margins on their MPLS kit - and that makes it expensive.

If PBT serves to drive down the cost of MPLS equipment then that's good enough for me. It's about time the carriers took a look at the margins that some of their MPLS suppliers are raking in.

Calling it "Transport" MPLS gives those suppliers an excuse to charge less for those specific boxes while retaining most of the codebase, and the high margins on the "core MPLS" boxes.

Cheers,
Geoff
gbennett 12/5/2012 | 3:46:48 PM
re: AlcaLu's Alwan: PBT Will Lose Its Shine Hi Delphi,

Just wanted to come back on this point:

"What makes it [MPLS] good for Layer 3 makes it cumbersome, complex, and expensive to implement and operate for layer 2 transport."

When MPLS was first touted, the "problems" it was trying to address were mostly based on adding scalability and control to IP networks.

Remember IP (like Ethernet) was never designed as a carrier technology, so some adaptation were needed. Two examples:

Traffic Engineering
Back in the late 90s carriers were fretting that they could actually control where IP packets were going in their network. They needed a way to guide IP traffic explicitly - and that's what Traffic Engineering is. MPLS allowed carriers to slap one label onto the traffic from a whole bunch of IP "interfaces", and to route that traffic explicitly across their IP backbone - overriding IP routing if necessary.

It's interesting that we now have pretty much the same requirement for carrier Ethernet services.

VPNs
In my mind this was the big breakthrough for MPLS because while TE helps carriers save money, VPNs help them make money and grow their business. But VPNs need an encapsulation scheme, and MPLS gives us the flexibility and simplicity we need.

And sure enough, this is exactly what we need for Ethernet too. 802.1q only gives us 12 bits of VLAN ID. So let's use MPLS labels as the Layer 2 VPN hierarchy and let VLAN tags be accessible by the local Enterprise user.

My point is that MPLS was "adapted" to be helpful at Layer 3, but it's not specifically a Layer 3 technology.

Similarly I believe MPLS can be "adapted" to suit Layer 2 services without having to re-invent the wheel.

If MPLS is carrying baggage from those Layer 3 functions then ditch the baggage.

Cheers,
Geoff
lamdaswavelength 12/5/2012 | 3:46:48 PM
re: AlcaLu's Alwan: PBT Will Lose Its Shine Talking of graveyards

The stockprices look like shit are you lazy or something? Do some work!!!
<<   <   Page 2 / 4   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE