Subject: Re: [rbridge] Break 4096 VLAN limit

From: Caitlin Bestler <[email-masked]>
Date: Mon, 13 Sep 2010 11:42:15 PDT

>On Mon Sep 13 9:07 , Joe Touch <[email-masked]> wrote:

>Hi, Benson,

>On 9/12/2010 9:40 PM, Benson Schliesser wrote:
>> Hi, Joe.
>>
>> On 12 Sep 10, at 11:08 PM, Joe Touch wrote:
>>> See RFC 5556 - this is outside the scope of this WG:
>>>
>>> Solutions to TRILL need not support deployment of larger scales of
>>> Ethernet link subnets than current broadcast domains can support
>>> (e.g., around 1,000 end-hosts in a single bridged LAN of 100 bridges,
>>> or 100,000 end-hosts inside 1,000 VLANs served by 10,000 bridges).
>>>
>>> I.e., this can't be a problem if the base network supports the number of
>>> VLANs. If it is, TRILL isn't intended to fix it.
>>
>> Regardless, scale in datacenter networks needs improving. The
>> problem could reasonably be divided into multiple aspects, one of
>> which is the size of broadcast segment namespace. Do you object to
>> the TRILL WG addressing this topic, if re-chartered to do so? Where
>> would you suggest is a more appropriate forum, and how would that
>> work eventually integrate with a TRILL deployment?

>That would need to start with an understanding of whether rbridges help 
>scale, esp. of the broadcast domain. For reasons why they would probably 
>not, see the LISP WG.

>I don't think we need to different WGs trying to solve this (IMO) 
>unsolvable problem. At best, I'd say take this over to LISP.

>Joe

It shouldn't be handled by an IETF WG at all.

Any solution to the 4096 VLAN limit needs to come from IEEE 802.1
Unlike TRILL there is nothing even vaguely L3-like about this.

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Sep 2010 12:24:40 -0700

On 9/13/2010 11:42 AM, Caitlin Bestler wrote:
>
>
>> On Mon Sep 13 9:07 , Joe Touch<[email-masked]>  wrote:
>
>
>> Hi, Benson,
>

Sure; either way, it's not a TRILL issue, IMO either.

Joe

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 14 Sep 2010 06:21:54 -0500

> Sure; either way, it's not a TRILL issue, IMO either.

The IEEE has already developed a number of namespaces that scale better than 4096 domains.  We should leverage their work, not ignore it.

Cheers,
-Benson

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Sep 2010 07:05:12 -0700

> The IEEE has already developed a number of namespaces that scale better than 4096 domains.  We should leverage their work, not ignore it.

I'm not sure what you're suggesting. On the one hand, you're saying we 
have something to offer that the IEEE does not; here, you're saying the 
IEEE already has a solution.

The key question here is whether TRILL helps solve anything. At the 
ethernet packet origin, there are 4096 domains (VLANs). We can shuffle 
them around, and map them around, but ultimately we can't create more 
independent domains because that requires inter-domain (i.e., 
cross-VLAN) discovery, so it won't strictly isolate the domains from 
broadcast.

This sounds like a research issue. Or do you have a specific solution 
that has been understood that you want TRILL to use?

Joe

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 14 Sep 2010 09:42:53 -0500

Joe -

On 14 Sep 10, at 9:05 AM, Joe Touch wrote:

> I'm not sure what you're suggesting. On the one hand, you're saying we have something to offer that the IEEE does not; here, you're saying the IEEE already has a solution.

You're conflating two topics.  TRILL provides a control plane and forwarding paradigm, using the existing 802.1q namespace to identify broadcast segments.  The IEEE has other namespaces that are larger than 802.1q, used for instance in PBB and SPB.

I'm not prepared to recommend specific details (i.e I-SID versus whatever) at this time, but I am recommending that we examine how the TRILL framework can be extended with a larger namespace based on existing IEEE work.  Feedback on this question from the other WG participants would be valuable.

> The key question here is whether TRILL helps solve anything. At the ethernet packet origin, there are 4096 domains (VLANs). We can shuffle them around, and map them around, but ultimately we can't create more independent domains because that requires inter-domain (i.e., cross-VLAN) discovery, so it won't strictly isolate the domains from broadcast.
> 
> This sounds like a research issue. Or do you have a specific solution that has been understood that you want TRILL to use?

I suspect you're thinking too narrowly about the problem.  I'm completely certain that there are interesting research issues, including issues related to broadcast scoping, and I hope that you and others spend energy investigating them.  In the meantime, there is also an engineering problem that's relatively straight-forward.  If you still don't understand what I'm talking about, please contact me off-list and I'll continue to explain.

Cheers,
-Benson

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Sep 2010 07:56:05 -0700

On 9/14/2010 7:42 AM, Benson Schliesser wrote:
> You're conflating two topics. TRILL provides a control plane and
> forwarding paradigm, using the existing 802.1q namespace to identify
> broadcast segments. The IEEE has other namespaces that are larger than
> 802.1q, used for instance in PBB and SPB.

The topics are closely related - TRILL relies on the scalability of the
broadcast domains in order to provide its control/forwarding plane benefits.

They key question is:

	- have these increase namespaces been applied to q-in-q?

TRILL doesn't really create its own broadcast domains; it tries to use 
domains that match the ones of its incoming traffic, or to merge 
incoming domains to its own. Yes, it'd be useful to have broadcast 
domains that TRILL uses that the base traffic doesn't (to avoid overlap) 
- so TRILL could use, basically, up to a doubling of the number of domains.

However, if the number of incoming domains is N, TRILL can't make that 
some new M that's larger without dealing with cross-domain (cross-VLAN) 
discovery, which requires functions we typically deploy in an IP router.

So my concern is:

- what is the reason for needing a larger namespace?

	is it to fix a problem TRILL creates?
	this is useful, but only (IMO) marginally)

	is it to fix a problem in the base network using TRILL?
	You'd need to explain what that approach is, i.e.,
	do you have an approach that works, or are you asking for
	the WG to solve this as an open research problem?

If you believe there is a non-research solution here, can you provide a 
brief description so we can at least understand what you're asking the 
WG to do?

(FWIW, this would be a fine opportunity to write an I-D. the charter 
doesn't need to change for an individual I-D)

Joe