Subject: [rbridge] Separating DRB election from encapsulator/decapsulator

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 3 Nov 2007 00:02:38 -0400

That seems like a good idea and should simplify the Hellos.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Thursday, November 01, 2007 12:01 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Separating DRB election from
encapsulator/decapsulator

When trying to carefully write up all the rules with respect to RBridges

and VLANs, it occurs
to me that one place in which things can be simplified is to separate 
the function of the DRB on
a layer 2 cloud from the selection of data packet 
encapsulator/decapsulator for each VLAN.

What I mean is that instead of having n different DRB elections with 
different priorities for
different, possibly overlapping sets of VLANs for that cloud, we instead

have a single
DRB election for that cloud, and as a result, a single pseudonode
associated with the cloud that would be visible to
any RBridges not on the cloud. The DRB on a cloud has the following
duties:

a) names the pseudonode associated with the cloud
b) reports an LSP on behalf of the pseudonode
c) issues IS-IS CSNPs (a way of acknowledging LSPs that have been
sent on the cloud)
d) specifies, for each VLAN supported on that cloud, which RBridge on
the
cloud will be doing encapsulation/decapsulation for that VLAN
e) chooses a VLAN tag with which all RBridge-RBridge communication on
that cloud will be tagged in the outer header (explanation of this will 
be in a future email).

For now, does anyone see any problem with this? It's unfortunately a bit

entwined with
the other hairy discussion going on, but I think that we're going to 
converge for that.

Radia
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge