x
<<   <   Page 2 / 4   >   >>
bbasmdc 12/5/2012 | 2:58:10 PM
re: PBT Cost Claims Questioned metroman's right.

Whatever "mess" a pseudowire implementation makes will be inherited by any carrier that tries to use PBT end to end. Because it's the operational procedures that are broken, not the transport technology.

The scope of PBT in BT's network is strictly limited for the moment. So the damage it can do (as a transport technology with no control plane) is also limited.
sdmitriev 12/5/2012 | 2:58:09 PM
re: PBT Cost Claims Questioned I've been in Warsaw yesterday (it took only 9 hours to drive across three borders through quite heavy snowstorm). And I'm not a vendor. Actually, I'm working as CTO for Carrier Ethernet SP.
Seminar was very interesting and quite useful for us (thanks, Light Reading).
I have asked a question "Why we need to deploy PBB-TE (PBT) if we can join MPLS/VPLS with PBB to achieve both scalability (PBB, mac-in-mac) and reliability/manageability (MPLS, fast-reroute, VPLS)?" panelists: Jan Hof (Extreme Networks) and Phil Tilley (Alcatel-Lucent).
IMHO, Jan's answer wasn't really convincing. A lot of words about "cost advantage and savings". Phil's answer was "Yeah right, why not to join?". I would like to compare their solutions, but Extreme do support 802.1ah (PBB) only on BlackDiamonds 10808, 1280xR series and these boxes aren't dirty cheap. Alcatel-Lucent 7450s (especially, ESS-1 and ESS-6) very comparable to them but do support full-blown MPLS/VPLS feature set, plus ALU just came with 7705 SAR for small site PW aggregation. If Alcatel-Lucent will show us PBB integrated into their MPLS/VPLS offer within next few months (why not, Phil?), than I'm asking myself: "why we need, as service provider, PBT at all?".
P.S. Unfortunately, I haven't seen Nortel, Cisco and Juniper guys in Warsaw. So, it was, mostly, ALU vs. EXTR.

bbasmdc 12/5/2012 | 2:58:08 PM
re: PBT Cost Claims Questioned Hey Light Reading!

Why doesn't this thread show on the Hot Talk list on the homepage?

The Sycamore story appears there with 2 posts, and yet here we are with 12 posts and we're being hidden!
Ryan Lawler 12/5/2012 | 2:58:08 PM
re: PBT Cost Claims Questioned That's due to the fact that this is an LR Europe story, and so it appears on the LR Europe page as the #1 Hot Talk thread. (Actually, it's the ONLY LR Europe Hot Talk thread.)
Ryan Lawler 12/5/2012 | 2:58:08 PM
re: PBT Cost Claims Questioned That's due to the fact that this is an LR Europe story, and so it appears on the LR Europe page as the #1 Hot Talk thread. (Actually, it's the ONLY LR Europe Hot Talk thread.)
LEDzeppelin 12/5/2012 | 2:58:07 PM
re: PBT Cost Claims Questioned According to the proponents, PBT supposedly works with any existing Ethernet switch hardware so it can be implemented on just about anyone's Ethernet switch. Does this not mean that the vendor with the largest installed base of Ethernet switch gear has the largest competitive advantage as soon as the PBT standards are eventually ratified? Why would I not simply wait for the PBT standards to be ratified and then software upgrade my existing network to PBT assuming the cost advantages are actually real and tangible?
LightCycle 12/5/2012 | 2:58:07 PM
re: PBT Cost Claims Questioned > The point being made is that the statements
> about the "low cost" of PBT are a bit wide of
> the mark when it comes to making it work in
> the real world. I hear that PBT is a money
> making machine when implemented in Excel and
> ppt.

I would imagine that the cost model around managing PBTs are well understood and accepted since it appears to be pretty much identical to how SONET circuits are managed... Whats the big f'n deal? Its been done for decades.

Any wonder why operators are still choosing to use SONET/MSPPs for transport?!
bbasmdc 12/5/2012 | 2:58:07 PM
re: PBT Cost Claims Questioned Hmmm. That seems broken.

Given that the story was on the LR homepage it seems wrong to marginalise the comments resulting from that story.
metroman 12/5/2012 | 2:58:06 PM
re: PBT Cost Claims Questioned PBT data can be carried across any ethernet switch but it will not interact with the operations. The forwarding tables need to be adapted and they need to interact with the OAM data. There is a requirement to adopt some parts of the model otherwise you start breaking bridging rules.

One other thing - you do need to have a hardware platform that is robust enough for the job. redundant components etc are not in every Ethernet switch. The thing you really don't need is the control plain engine.... or do you....?

Metroman
metroman 12/5/2012 | 2:58:06 PM
re: PBT Cost Claims Questioned So what I suggest you do is, go and replace all your SONET infrastructure with PBT tonight and see how it operates in the morning....

Does your team know how to manage a packet based network? Do they understand MAC addresses? Can they troubleshoot the network? Does it scale now that they cannot control the actual amout of bandwidth each customer uses (did you forget to teach them about policing in Packet based networks?) Prove to me as a subscriber of the service that you are billing me correctly? etc. etc.

The view that "the operating model is the same as SONET" is so narrow as to be laughable. Just think it through - what would it REALLY be like. This is about people, customers, contracts and responsibility, not sound bytes. Show me (read: Prove)that my customers will not be affected and that it will cost me the same as it does today with all the same controls and I might be interested. Otherwise it is a marginal technology with marginal benefit for those who have commoditized, low value businesses. (Oh, and I can use my SONET circuit for multicast.)

Metroman
<<   <   Page 2 / 4   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE