[rbridge] Separating DRB election from encapsulator/decapsulator
Eastlake III Donald-LDE008
Donald.Eastlake at motorola.com
Fri Nov 2 21:02:38 PDT 2007
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
More information about the rbridge
mailing list