Market Leader Programs
5G Transport - A 2023 Heavy Reading Survey
2023 Open RAN Operator Survey
Coherent Optics at 100G, 400G, and Beyond
Open RAN Platforms and Architectures Operator Survey
Cloud Native 5G Core Operator Survey
Bridging the Digital Divide
5G Network Slicing Operator Survey
Open, Automated & Programmable Transport
The Journey to Cloud Native
Good firm assertions, care to substantiate this with fact?
D
1) Enable significant cost savings compared to existing infrastructure (considering "whole life costs" - ie. captial, maintenance, installation, OSS, etc..). Cost savings must be significant enough to overcome the cost of introducing the technology into the carrier.
and/or:
2) Enable some significant new revenue stream from a new service that can't be provided on existing infrastrucutre.
PBT doesn't accomplish either of these. It neither enables a new service nor provides significant enough cost savings to justify change.
I can only say what I know with respect to competitive analysis we've done on CAPEX, OPEX, power consumption, and sustainable differentiation (as in there is less than one product development cycle's difference). IMO it is substantial, and of course all of it subject to question by anyone who rightly questioned my objectivity...
Rather than make explicit claims which simply trots out the "don't confuse cost and price" argument (one that is truly amusing), what I can suggest is open your next RFP to Provider Ethernet and see what kind of response you get from ALL your vendors! That would be my proof...where the rubber hit the road.
Well, part of the problem for the PBT camp is that they have to bring the evidence, not the opponents.
Right now, if you are an undecided vendor or operator, why would you spend money on PBT without proof? NokiaSiemens and BT have as long experience as anyone can have, yet they still decided to give it up. What message does that send to the undecided?
Well, many may not like the results of that rhetoric (discussed below.)
I suspect the majority of flowers that will bloom will be the users of the infrastructure rather than the infrastructure itself. Right now what we have is the equivalent of a pygmy forest which is hampering innovation and growth.
http://en.wikipedia.org/wiki/P...
Debating if a tangential problem is solved or not doesn't seem all that useful if progress is the goal.
Let a thousand flowers bloom is a common misquotation of Chairman Mao Zedong's "Let a hundred flowers bloom; let a hundred schools of thought contend". This slogan was used during the period of approximately six weeks in the summer of 1957 when the Chinese intelligentsia were invited to criticize the political system then obtaining in Communist China.
It is sometimes suggested that the initiative was a deliberate attempt to flush out dissidents by encouraging them to show themselves as critical of the regime. Whether or not it was a deliberate trap isn't clear but it is the case that many of those who put forward views that were unwelcome to Mao were executed.
Whatever stance carriers take on PBT, 98% of them still need to offer 2547 services, as it is the mainstream IP VPN service. They need the testing, the competence, the OSS, etc, in their organisation. So, PBT can only remove the alleged complexity of MPLS in certain parts of the network. And even if PBT was very simple, it's still something new that's added ON TOP of the mandatory MPLS technology.
1) On services: Right now PBT offers (at most) point-to-point Ethernet services. In the future, via PLSB, PBT might offer any-to-any L2 services (though I am not sure I would call that PBT any longer).
Service providers can (and have for many years) offer point-to-point Ethernet services over many technologies including: Fiber, WDM, TDM (via x.86, GFP-F, GFP-T), ATM, MPLS PWE, IP, and FR.. just to name a few. PBT offers no new service to the industry for P2P Ethernet. You might argue that PBT somehow does it technically "better", but all of these arguments depend on the design of the service providers' network and what they are trying to accomplish. In the end, the "better" argumnet is not very compelling.
For any-to-any L2 LAN-like services, again, service providers have been offering these services via plain L2 switching, VLANs, Q-in-Q, PBB, VPLS, HVPLS, and even ATM LANE. This is not a new service either and PLSB will not make much of a difference.
2) Cost: "Carrier" Ethernet switches have no fundamental cost/reliability advantage over Ethernet optimised MPLS switches. While the market has historically prices these switches differently, markets tend to sort this artificial pricing difference out over time. Inevitably,if PBT survives, all Ethernet switches will have hardware to switch/encapsulate with MAC, Q-in-Q, MAC-in-MAC, IPv4, IPv6, and MPLS. This is already happening as commodity chip vendors build new silicon. It is inevitable as there is little extra cost to build hardware to support all switching modes. After all, what difference does it make as to which field is examined and what address field is looked-up for forwarding at the hardware level?
Operationally, there is little difference in running L2 service networks built on any of these forwarding mechanisms. The idea the MPLS is "more difficult" top operate come from offering L3 VPN services over MPLS (ie 2547), which is certainly a complicated services. However, if all you offered was TE'd point-to-point L2 services over an MPLS infrastructure, MPLS would be comparable to PBT, TDM, or any other TE'd point-to-point technology.
If there were some dramatic whole life cost savings for PBT, I suspect carriers would be jumping all over PBT versus running away from it.
I have been involved, am well informed, and there are no significant cost differences between MPLS and PBT capable equipment.
Speaking of die areas on chips doesn't really address the point (even if I agreed with the quoted numbers). Once the chip is built, there is minimal incremental cost to produce/maintain that design. Thus, a forwarding chip with PBT or with PBT+MPLS will not have significantly different production costs. It follows that a large Ethernet switch will not change in cost to produce whether it forwards at the MAC layer, MPLS layer, or IP layer (or is capable of all of the above). This has *already* happened in the industry! Saying that PBT somehow makes the switch hardware cheaper is simply not consistent with the current pricing on commercially available switches from many vendors.
I agree with you that MPLS (and IP) have many more options/features than just PBT. And of course that gives it much more functionality. Much of this functionality does not require significant (or any) hardware support. While developing the software for a full-function MPLS implementation is a daunting and expensive task for a vendor, software is a one-time development cost (per feature) with some ongoing support cost, all of which is spread over the units of hardware shipped. There is no significant per-hardware-unit software cost for the vendor. Again, the vendor suppport costs of recent bears this out.
Additionally, comparing MPLS to full-function L2 switches (including STP, VLAN, Q-in-Q, QoS, RSTP, MSTP, PBB, PBB-TE, LAG, MCLAG, 802.1AG, SNMP, PLSB, etc...) it is difficult to say which has a more complex software stack.
If one wants to stay in a narrow myopic view of restricting a discussion to how MPLS and PBT can be compared while just supporting point-to-point Ethernet services, you might convince me that PBT has an advantage. However, what carrier wants to build stand-alone single-purpose infrastructures that only provide one service? Integration of many carrier services onto common technologies is the key to reducing capex and opex across all services.
It will always be cheaper to build an optimised technology that does one thing really well versus a technology that is targeted at supporting many things. However, it is almost never cheaper to build complex networks that must support many services by implementing many "stove pipes" of those optimised purpose-built technologies. Trying to do so ignores the fact that all of the services are significantly intertwined with each other and the stove pipes rarely integrate well.