[rbridge] Per-VLAN DRB elections?

[Radia.Perlman@sun.com]

I think we haven't discussed this one on the list yet.

Bridges can be configured to not forward certain VLANs on certain links.
So, a "level 2 cloud" (a bunch of links connected with bridges) can be partitioned
with respect to various VLANs. So, for instance, RBridges R1 and R2 can be
neighbors on a cloud with respect to VLAN A, but not with VLAN B. In other
words, a packet tagged with "VLAN A" will get from R1 to R2, but one tagged
with "VLAN B" will not...even if both R1 and R2 think they are connected to VLAN B.

Oh...this is somewhat related to listening instead of participating in
the bridge spanning tree, which I will clarify in a separate thread.


Some issues with bridges not forwarding all VLANs:

a) If the IS-IS DRB (Designated RBridge)
election messages are tagged with VLAN B, then we will wind up
with two DRBs for the link (scary)

b) if R1 is selected DRB for the link, it may not be able to serve all endnodes (since
R1 might not be able to reach certain endnodes on some VLANs

c) in theory, DRB election should be separately carried out for each possible VLAN tag
(4000 of them). That would be too much.

d) there was a suggestion that it might be a feature to allow load sharing off a layer 2
cloud by having separate DRBs for different VLANs

So...here's a first strawman proposal, partially based on my memory of hallway conversations:

a) for the zero configuration case, assume that without configuration, the DRB election
is carried out once, tagged with VLAN 1. Whoever gets elected DRB in the DRB election
tagged with VLAN 1 is DRB for all VLANs on that link.

b) RBridges may be configured with other VLAN tags to also, on the same port, participate
in an IS-IS election with. DRB priority may be configured to be different for different VLANs, so
R1 might be configured, on port a, to participate in a DRB election for VLAN A with priority 7,
and VLAN B with priority 9

c) In the core instance of IS-IS, R1 announces not just which VLANs it is attached to, but
the Root bridge ID for that VLAN. That way, if R1 finds out (by seeing R2's link state packets)
that R2 claims to be DRB for VLAN A, with root bridge 89, and R1 thinks that it is DRB for VLAN A,
root bridge 89, then one of them should back off (using system ID as a tie breaker), where
"back off" means "stop acting as DRB", i.e., don't encapsulate/decapsulate data packets
to/from that port with respect to that VLAN

d) it is absolutely gross misconfiguration, and a disaster, if within the layer 2 cloud, a VLAN tag
can turn into another VLAN tag, because this could cause R1, who is DRB for
that link for VLAN A, to decapsulate a frame onto the link, which might pop out to
R2, who is DRB for that link for VLAN B, to see the packet as "VLAN B"

I *think* my proposal above has the following properties:

1) if a link is genuinely partitioned with respect to VLAN A, then there will be two DRBs elected
for that link, and all endnodes on that link in VLAN A will be reachable via one or the other
DRBs, and no link will be formed

2) as long as a VLAN tag can't get converted to another VLAN tag within the layer 2
cloud there will not be loops formed by having two DRBs on the same layer 2 cloud

3) we can do load sharing (R1 will be DRB for VLAN A and R2 will be for VLAN B)

4) if R1 and R2 wind up both elected as DRB for VLAN A and VLAN A is not actually
partitioned (but R1 can't reach R2), then they'll discover this through the core instance
IS-IS announcements

5) the common case can still be zero configuration

Comments?

Radia