[rbridge] Final outcome of outer VLAN tags on RBridge-RBridgepackets?
anoop at brocade.com
Mon Oct 22 11:01:17 PDT 2007
If we want to make implementations work with
only a single Hello for all VLANs than the
option is (a). I think that is what it should be.
Basically, as a part of RBridge configuration
there should be a "RBridge Control VLAN" configuration
that applies to the whole device. It should default
to VLAN 1, but an operator can choose to change it.
A RBridge only emits Hellos on that VLAN. If it
receives Hellos on any other VLAN that should
be detected as an error condition and reported.
There have been some problem corner cases that
have been pointed out previously on the list
that may result in temporary duplication of
traffic when there is misconfiguration. Those
should be documented.
> -----Original Message-----
> From: rbridge-bounces at postel.org
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Saturday, October 20, 2007 9:47 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Final outcome of outer VLAN tags on
> I'm not sure I understood the final consensus on what we
> should do for outer VLAN tags on inter-RBridge packets.
> The possibilities I think the consensus might have been are:
> a) only use VLAN 1, explicit tag, no configuration possible.
> b) default is VLAN 1, explicit tag, configuration is possible
> to change sending with VLAN tag(s) something other than 1. If
> this is what was decided, I don't believe we've worked out
> the design details. I'd assume this would mean RBridges
> should be willing to receive packets from other RBridges
> regardless of outer VLAN tag. Would we then mark in the
> Hellos what VLAN tag(s) you've heard from what other RBridges
> with? What do we do with multicast if there isn't a single
> VLAN tag that seems to work to send to everyone? Would we
> allow configuration to send on a set of VLAN tags, or just on
> one at a time (and we allow configuration to say which one it is)?
> Certainly a) is simpler. If the consensus was b), we'd better
> work out the details.
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge