Subject: [rbridge] I-D ACTION:draft-ietf-trill-routing-reqs-02.txt

From: Internet-Drafts at ietf.org ([email-masked])
Date: Thu, 01 Feb 2007 15:50:02 -0500

ENCODING mime
FILE /internet-drafts/draft-ietf-trill-routing-reqs-02.txt
-------------- next part --------------

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Thu, 1 Feb 2007 15:01:23 -0800

I'm going to try to distill the MAC uniqueness issue down
to the RBridge specific issue of RBridge information
sharing, and whether any new wrinkles are being introduced
or whether RBridges as specified are compatible with
current VLAN practices.

The potential issue revolves around this statement:

   Station information need only be delivered to RBridges supporting
   the VLAN in which the station resides. So, for instance, if station
   E is discovered through a VLAN A frame, then E's location need only
   be delivered to other RBridges that are attached to VLAN A links.

That's from section 3 of the routing requirements, but the 
same requirement is expressed elsewhere.

Now consider the following scenario, which is admittedly
highly unconventional and almost certainly the result of
bad network administration):

	RBridge A has access to VLANs 1 and 2.
	RBridge B has access to VLANs 2 and 3.
	RBridge C has access to VLAN 3.

	RBridge A detects MAC Address X on VLAN 2.
	RBridge A informs RBridge B that it has Address X on VLAN 2.

	RBridge C detects MAC Address X on VLAN 3.
	RBRidge C informs RBridge B that it has Address X on VLAN 3.

Now, if RBridge B considers VLANs 2 and 3 to be distinct trees
for the purposes of learning addresses there are no problems
with this scenario.

But if RBridge B handles VLANs 2 and 3 in the same learning
tree, then "X is on VLAN 3 handled by RBridge C" replaces
"X is on VLAN 2 handle by RBriddge A". But that update
is only made on RBridge B -- it is NOT made on RBridge A.

One resolution is to require that RBridges treat each
each VLAN as a distinct instance and organize their
data accordingly. My current reading is that the protocol
document does in fact make this requirement, but perhaps
is not as explicit about it as desirable.

If that requirement is understood by ALL RBridges, it
is indeed safe to only share data about VLAN 3 with
RBridges that support VLAN 3.

On the other hand, if RBridges are allowed to do shared
tree learning (just as conventional bridges are allowed
currently) then the real requirement would be:

	Station information need only be delivered to RBridges
supporting
	the naming scope of the VLAN in which the state resides. So, for
	instance, if station E is discovered through a VLAN A frame, and
	VLAN A is part of naming scope X, then E's location need only
	be delivered to other RBridges that are attached to VLANs that
	are part of naming scope X.

That would of course beg the issue, how does an RBridge know what
naming scopes other RBridges use? It would increase the complexity
of information shared through discovery.

Further, if only a single RBridge used global/single-tree learning
then all other RBridges would have to send it *all* updates. So the
value of attempting to track the naming scopes of each RBridge seems
minimal to me.

This suggests three options:

	1) Require all RBridges to scope on a per-VLAN basis.
	   The only real flaw in this is that it is a RBridge
	   requirement that does not apply to conventional bridges.

	2) Allow all RBridges to have whatever scoping rules they
	   want, but require that all updates go to all RBridgges.
	   Each RBridge can judge for itself it the information is
	   relevant to it, and organize that data however it wants.

	3) Punt: require the network adminstrator to ensure that naming
	   scopes enforced by RBRidges are "consistent" and provide
	   only text-based suggestions on how to achieve this.

What I would not suggest is actually mapping this complexity to
achieve zero configuration no matter how deranged the VLAN
deployment is. Anyone using "global" MAC addreses that have
less than "global" scope should be responsible for doing at
least a little bit of planning and not rely on run-time systems
to catch their mistakes.