Re: [dc] comments and suggestions to draft-narten-nv03-overlay-problem-statment-01

[Thomas Narten <[e-mail]>]

Paul Unbehagen <[e-mail]> writes:

> On Jan 26, 2012, at 5:22 PM, Linda Dunbar <[e-mail]> wrote:

> > Since IEEE802.1 defined VLAN separation is mentioned, it would be
> > appropriate to mention PBB’s ISID separation.

> Agreed, clear service separation and the 16 million services should
> be clearly explained, additionally the ease of edge provisioning
> over STP's per hop configuration.

Will do.

> > The limitation for PBB and VLAN should include that MAC addresses
> > can't be aggregated, therefore forwarding table can be very large
> > for large data centers.

> Disagree, this isn't what we see in live deployments. Since the Mac
> learning of the host stations only happens at the edge switches and
> the services are distributed across many edge switches the ISID
> service Mac table sizes don't end up being that large on any given
> node. Additionally the core never sees any macs but the nodes
> participating in the backbone from edge switch to edge switch.

I think we need to distinguish between PBB-V and PBB-M.

With PBB-M, you get mac-in-mac encapsulation, so the PBB Bridge nodes
(as part of forwarding) only look at (and build tables for) the MACs
in the outer header. Consequently, you don't get MAC table explosion
here as your core network gets bigger. Is this what you mean above?

For PBB-V, the PBB bridges are routing on client MAC addrs (C-MACs),
so you presumably will run into issues with table size as your network
core increases in size.

Agreed?

Thomas