<<   <   Page 3 / 3
CoreRouterBuilder 12/5/2012 | 3:01:15 PM
re: Vendors Clash Over PBT where is the traffic engineering here ?
mvissers 12/5/2012 | 3:01:15 PM
re: Vendors Clash Over PBT MSTP: Multiple Spanning Tree Protocol; see clause 13/802.1Q-2005.

802.1D networks include a single VLAN. 802.1Q networks include multiple VLANs, still within one layer.

802.1ad networks introduce a single layer network in the provider domain, able to carry customer VLAN signals.

802.1ah introduces two layers in the provider network. When applied UNI-to-UNI, there are only those two layers in the provider domain. When applied between PB networks, then you will have three layers in the provider domain; that is one more than necessary.
macster 12/5/2012 | 3:01:14 PM
re: Vendors Clash Over PBT PBB requires a lot of configuration to get any service up and running. PBB is the first ethernet network with two layers: backbone service and B-VLAN (i.e. a tunnel layer).

Provider layers - yes.
t.bogataj 12/5/2012 | 3:01:13 PM
re: Vendors Clash Over PBT M. Vissers,

Thank you for clarification of technical aspects. Indisputably, it cannot be questioned.

I was not saying that PBBNs required no configuration. They do. The point I was making was elsewhere: it was in the difference between configuration, and embedded control plane mechanisms -- like, for example, active MAC-learning and active topology protocols (xSTP).

Let's take it step by step. 802.1Q bridges require configuration (VIDs, port membership, tagging, etc.). But they actively learn MACs by flooding, and are able to resolve loops. No path provisioning through bridge network required.

802.1ad bridges require configuration as well. Unlike .1Q bridges, they also need multiple-tag configuration (C- and P-VIDs). But only on edge bridges: core bridges may be .1Q-compatible. No path provisioning through bridge network required.

802.1ah bridges require even more configuration (C-VIDs, S-VIDs, etc.). But again, only edge bridges (BEBs) need this configuration: core bridges (BCBs) may be .1Q-compatible. No path provisioning through bridge network required.

Therefore, in PBNs (.1ad) and PBBNs (.1ah), no path provisioning is required. Only edge bridges (edge meaning service edge) require a bit more complex configuration. Core bridges require only .1Q-like configuration. All forwarding through PBN or PBBN is learned actively using .1Q mechanisms. All loops within PBN or PBBN are resolved using, say, xSTP.

PBB-TE, on the other hand, requires manual path set-up. All learning mechanisms within transport equipment are disabled. Transport equipment becomes dumb. And path provisioning is moved to external control/management plane equipment. For which GMPLS is the most likely (if not the only) candidate.

In terms of cost, how does PBB compare to PBB-TE? PBB requires BCBs to support nothing more but 802.1Q. PBB-TE requires *all* BCBs to support PBB-TE. And PBB-TE enabled networks require costly GMPLS control plane.

And comparison to T-MPLS? Again: T-MPLS comes with control plane. PBB has it built-in. With PBT -- pay a bit more for PBB-TE enabled BCBs, and pay a lot more for GMPLS.


franco_mv 12/5/2012 | 3:01:12 PM
re: Vendors Clash Over PBT I would like to put some light on the CAPEX discussions so far.

I've seen lot of claims about PBB/PBT being cheaper, just because it's simple technology.
When we look at existing MPLS solutions - ALU (ESS/SR), CSCO (7600) and JNPR (MX) - I understand that their hw cost is related to do wirespeed filter, classification and queueing (thousand's of queues per port) and this is not related to control plane. If this is the case PBB/PBT boxes
will sit at same cost level as the QoS requirements are still demanded, but nobody is talking about this.

Btw, there's people in our industry comparing PBB/PBT switches against core routers, putting power consumption and manuals in the table.
What a shame!
<<   <   Page 3 / 3
Sign In