[rbridge] Orphaned endnodes with partitioned VLANs on a cloud

[Russ White]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Russ, I think a way of thinking about it that might be clearer is first to pretend there are no VLANs.
> We want there to be just a single RBridge that forwards traffic to/from the link. 

What you're talking about here is edge ports, though, not links in the
middle of the cloud--I think there's a radical difference between the
two. The edge case can be solved more easily than what you describe
below--I'm waiting on some validation from some other folks before
sending out a list of ideas to the list.

As for the link in the cloud, I don't think this is a case that we
should worry about.

> But anyway, now let's look at VLANs on the link. Because of bridges, any VLAN might be partitioned with
> respect to data traffic, for various reasons.  The WG discussed this at length, and it looked to me, and I strongly
> agree with this -- that TRILL should consider partitioned VLANs on a link as a misconfiguration, and should
> make sure they are defensive against it (not creating loops), but should not worry about healing
> all the partitions.

The current proposal heals partitioned VLANs, from what I understand of
it, intentionally--at least on the links in the cloud. This is what I
specifically think we should avoid doing.

Let's begin with this: rbridges don't care about the state of the links
between rbridges, they only care to solve possible loops for edge ports.

> The RBridges have to stick some VLAN tag on packets when they
> talk to each other.  

Actually, the don't, from what I understand. They could talk native on
the media, or they could use a vlan, depend on how they're configured.

> a) Hellos on every possible VLAN by every RBridge. DRB elections on each possible VLAN. Different pseudonodes per link for each
> possible VLAN (with some attempt to consolidate when possible). Not being able to be conservative about loops
> (since the "report the root bridge" will not work). Multicast traffic might traverse the traffic multiple times (because
> each pseudonode is logically a different node in the topology).

> b) DRB sends lots of Hellos (to be as robust as possible about preventing multiple forwarders within the cloud,
> although if that doesn't work, the next level of safety -- seeing the root bridge in the LSP), but all other RBridges
> just send a single Hello. Single pseudonode. Only downside -- if the cloud is configured to have a particular VLAN
> partitioned, then endnodes get orphaned.

There are a number of other options, but again, I'm waiting on someone
else to look at them before sending them to the list.


> Personally, I think we should leave the spec the way it is. It was a careful balancing act between overhead and
> safety, plus supporting features such as load splitting based on VLANs.

The problems with the current mechanism are:

1. It doesn't solve what it was intended to solve.
2. When it does work, it has unintended side effects.

Again, things are much too mixed up right now--solve one problem, and
one problem, only. Ignore links between rbridges that are designed to be
host free, or transit only. Only worry about edge ports. Don't worry
about misconfigurations, in terms of trying to find a path when
something is misconfigured, etc.

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHXEGaER27sUhU9OQRAit0AJ4zRD1EejlVx9NM7jZ6bhBQD2vPZgCfTfyS
lvpIcJiZ+uuzkFaFuObga9Y=
=xJTQ
-----END PGP SIGNATURE-----