Subject: Re: [rbridge] Break 4096 VLAN limit

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Tue, 14 Sep 2010 03:45:20 -0500

Donald

I'm not sure why SPB became a topic for this thread but if you are going to compare lets get the facts right.

Part of SPB's scale comes from the data plane that use MAC in MAC encapsulation PBB (SPBM).  SPBV using a normal VLAN encapsulation scales like normal bridges using VLANS or QinQ.  

Scaling is a complex subject that cannot be captured by simply by comparisons of n*(log n) are or n*n (log n) etc. There is more to control plane and system scaling than simply routing computation. Your statements are superficial and misleading.

The 4096 VLAN limit is a data plane issue. Please stick to relevant facts.

For those who want more information we have a wiki page at: http://en.wikipedia.org/wiki/IEEE_802.1aq 

Regards,
Don 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Monday, September 13, 2010 7:13 PM
To: [email-masked]
Subject: Re: [rbridge] Break 4096 VLAN limit

Hi Joe,

On Mon, Sep 13, 2010 at 3:33 PM, Joe Touch <[email-masked]> wrote:
>
> On 9/13/2010 10:46 AM, Donald Eastlake wrote:
>>
>> On Mon, Sep 13, 2010 at 12:08 AM, Joe Touch<[email-masked]>  wrote:
>>>
>>> ...
>>
>> First, there are no network size restriction in any version of the 
>> TRILL Charter that I am aware of.
>
> Not in the charter, but we agreed on limiting the scope to avoid 
> issues of scale during the early work of the WG, as documented in 
> RFC5556. This is at least partly because there's nothing about the 
> TRILL architecture that supports increased number of devices per se; 
> it's intended to support increased node-node capacity and better routing protocols, but not scale.

I don't think "to avoid issues of scale" is accurate. Lots of things have some influence on scale and we would certainly have avoided anything that caused bad scaling that would have limited TRILL to small networks. We just didn't want to tackle increased scaling at the same time we were getting the basic TRILL protocol under control.

Of course TRILL scales somewhat better than bridges do. Just the reduction in the forwarding tables at the transit RBridges does that.
(And if you are going to complain that SPB has now copied enough from TRILL that it has that same advantage, I would point out that routing calculations in TRILL scale as n*(log n) while in SPB they scale as n*n*(log n).)

>> Second, "need not" in the words above means only that a solution 
>> which does not address larger networks, in some dimension, still 
>> meets the requirements of the RFC 5556 Problem Statement, not that 
>> features which make TRILL more capable and happen to to be 
>> particularly beneficial for larger networks are somehow prohibited.
>
> "happen to be" is different from "focused on". This has come up many 
> times in the WG, and we've basically said that such enhancements would 
> be considered only if optional (e.g., as with cached ARP responses).

"Many times"? The mailing list is on line. I'll believe you as soon as you provide me with pointers to three different cases where there was WG decision as you have described. (Note: postings by you do not constitute a WG decision.)

But as for enhancements being options, I would say, of course. Once you have specified a protocol and lots of people are implementing it, you want to be careful about mandatory changes and generally make them only with consensus of the implementors. Where did you get the impression that extensions would be some sort of mandatory upgrade?

>> Third, RFC 5556 was mostly put together in 2008. I think the view 
>> then was to try to get to a decent base TRILL standard and people 
>> didn't want to try to take on too much. Now that has been 
>> accomplished, in the TRILL base protocol standard. It does not seem 
>> unreasonable to think now about extensions. In fact, some extensions 
>> already exist in draft form.
>>
>> What seems important to me for some work to be taken on is (1) that 
>> it be allowed by the Charter, (2) the WG wants to take it on, and (3) 
>> there are people willing to do the work. There seems to be 
>> considerable interest in the topic in question. One reason I 
>> suggested people write drafts is to see if there were people willing 
>> to do the work
>
> It's also important that the work in question be engineering, not research.
> There's simply no evidence that rbridges support increased number of 
> edge devices where existing ethernet devices would fail. That would 
> suggest a scalable solution to map-encap systems in general, and, as 
> the LISP WG is discovering, no such solution exists yet.

Well Joe, perhaps the future will surprise you on some points. In the mean time, I do not agree with you that thinking about greater scaling should be classified as thought-crime.

> Joe

Thanks,
Donald

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge