[rbridge] VLAN Scoping / MAC Uniqueness

[Caitlin Bestler]

Erik Nordmark wrote:
> Caitlin Bestler wrote:
> 
>> My reading of Appendix B is that Shared Learning is allowed, where
>> VID is not a key field (i.e, there is only one FID supported).
>> Appendix B details some of the problems this creates. I believe the
>> problems for RBridges are even greater than for simple Bridges. This
>> probably justifies restricting RBridges to the Independent Learning
>> model, but any such additional restriction should be explicitly
>> stated. 
> 
> My understanding is is that shared learning is useless when
> VLANs are used for isolation/security. With shared learning a
> host on VLAN A can trivially cause a DoS attack VLAN B by
> just sending packets with the source MAC address being the
> MAC address of another host on another VLAN.
> 
> Thus I'd be surprised if it is used much in practice with bridges.
> 
> I don't see it being a reasonable default for RBridges.
> 
>     Erik


It's a perfectly reasonable behavior, as long as the VID is at
least checked (i.e., it is an attribute, not a key field). A set
of RBridges that *all* used this approach would work perfectly fine.

The real issue is whether RBridges that will realistically tend to
use Independent Learning can easily accommodate some of their peers
doing Shared Learning, and if so, how.

For example, the rule could be that you can use Shared Learning as
long as no other RBridge can detect that you aren't using Independent
Learning. Or Shared/Independent Learning could be a flag that each
RBridge advertises. Or each RBridge could advertise it's VID->FID map.

All of these work, the question is which are justified. As much as I
dislike increasing the key size I can certainly see the advantages to
maintaining a distributed database of requiring all RBridges to use
Independent Learning. So I'd lean toward simply standardizing on
Independent Learning. But any new requirement is best explicitly
stated, not inferred from the data descriptions.