x
Page 1 / 2   >   >>
chechaco 12/5/2012 | 3:10:26 PM
re: BT Pressures Vendors Over PBT It is strange that LR tries to explain visible absence of these companies among early supporters of PBT by existence of T-MPLS. Does it imply that all or some of these companies are promoting T-MPLS? Even though T-MPLS has nothing new if compared with combination of specific modes of 802.1ah, MPLS label distribution and PWE3.
torivar 12/5/2012 | 3:10:25 PM
re: BT Pressures Vendors Over PBT Alcatel has no current products that support T-MPLS, afaik, but they are pushing T-MPLS in the ITU and are its biggest proponent. Their business in the US for Ethernet delivery is around the 7750/7450 platform and using PWE3-based VPLS and Ethernet private line. Which can be done on their gear using an MPLS core or GRE tunneling.

At this point, there is a large installed base of MPLS based Ethernet services and large carriers doing Ethernet transport using MPLS, like Verizon, ATT, Level3, etc and they are using Alcatel, Cisco, and Juniper gear. They already have the MPLS networks. Alcatel and Cisco already make Metro devices that support MPLS...

I don't think PBT has the same appeal to choose it over MPLS that going to MPLS from ATM/Frame networks did. That's why they aren't on board.
sgan201 12/5/2012 | 3:10:24 PM
re: BT Pressures Vendors Over PBT << 1. Yes, if you mean optimized multicast in VPLS. But PBT/PBB-TE does not address these issues.
2. PBT as of now defined for point-to-point services EPL and EVPL. It's only advantage when used over Eth PHY.
3. One can PCE to offload path computation from switches onto route servers. Besides, PBT is exploring GMPLS for signaling.>>

1) No. I do not mean multicast.

2) point-to-point EPL and EVPL is what I refer to.

3) Even with G-MPLS, the signaling is sent to the OSS system. It is not process by the network element.

<<one can="" computation="" from="" offload="" onto="" path="" pce="" route="" servers.="" switches="" to="">>

Yes. But, why do that to begin with?? With PBT, the path routing is done on OSS to begin with.

Dreamer

</one>
sgan201 12/5/2012 | 3:10:24 PM
re: BT Pressures Vendors Over PBT 1) MPLS and VPLS have issues in providing Ethernet services.

2) PBT may solve some particular Ethernet service problems in a simplistic fashion.

3) There is a philosophical battle here too. Where should the intelligence of network resides?? Under PBT like model, it is in the OSS system. For T-MPLS and MPLS, it is in the network device.

Intelligence = $$$$. So, is the most of $$$ going to be spent on OSS or network devices?

Dreamer
gigeguy 12/5/2012 | 3:10:24 PM
re: BT Pressures Vendors Over PBT It's still a mystery why BT is so willing to bet the farm on new and untested technology. Other carriers are happy to sit and watch to see if BT succeeds or falls flat on its face. Meanwhile, they can use tried and tested MPLS & VPLS for their Ethernet services.
chechaco 12/5/2012 | 3:10:24 PM
re: BT Pressures Vendors Over PBT 1.If you only need static p2p tunnel then PBT might fit the bill. But, once again, I would point that as of now PBT addresses only part of scenarios addressed by MPLS-based technologies. And I believe that if PBT to be expanded to p2mp, mp2mp tunnels and provide path or segment protection it would not be much simpler then GMPLS/MPLS.
2.OSS would not compute routes for PBT it can include an application that does CSPF to do that. PCE only defines control protocol between Path Computation Element (PCE) and Path Computation Client (PCC)or another PCE. Thus OSS can use its own.
chechaco 12/5/2012 | 3:10:24 PM
re: BT Pressures Vendors Over PBT Dreamer wrote:
"1) MPLS and VPLS have issues in providing Ethernet services.

2) PBT may solve some particular Ethernet service problems in a simplistic fashion.

3) There is a philosophical battle here too. Where should the intelligence of network resides?? Under PBT like model, it is in the OSS system. For T-MPLS and MPLS, it is in the network device."

1. Yes, if you mean optimized multicast in VPLS. But PBT/PBB-TE does not address these issues.
2. PBT as of now defined for point-to-point services EPL and EVPL. It's only advantage when used over Eth PHY.
3. One can PCE to offload path computation from switches onto route servers. Besides, PBT is exploring GMPLS for signaling.
metroether 12/5/2012 | 3:10:23 PM
re: BT Pressures Vendors Over PBT
>>2. PBT as of now defined for point-to-point services EPL and EVPL. It's only advantage when used over Eth PHY.


PBT doesn't really have any advantage, even over an Ethernet PHY. Both protocols (MPLS, PBT) use a shim consisting of a MAC header and a demultiplexing field. Whether you call it a tag or a label is pretty immaterial.

If someone wants to put the provisioning aspects into an OSS, it can be done equally with either. There's not really anything that can be done with PBT that cant be done with MPLS, so all one can argue is cost. And its not that MPLS can't be made cheaper, its that carriers demand high-performing, resilient, and reliable implementations with many features.

BT is off in the weeds.
sgan201 12/5/2012 | 3:10:23 PM
re: BT Pressures Vendors Over PBT 1) Yes. PBT does not address p2mp or mp2mp. But, does it has to? I do not think so.

2) And, that application that do CSPF can be running on a pair of centralized computers. Centralized approach. Not distributed.

Dreamer
pschurr 12/5/2012 | 3:10:22 PM
re: BT Pressures Vendors Over PBT Are we ignoring the age-old arbiter in religous wars? Money. The 'incumbents' don't want to spend a lot of development cash to develop something they don't have, and the PBT guys want to differentiate themselves from the incumbents. It isn't a 'this is better than that' issue.

I'd bet that BT is hell-bent on PBT because it provides a handy distraction from their project delay problems - and a reasonable excuse for them too.


peter
Page 1 / 2   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE