[rbridge] Orphaned endnodes with partitioned VLANs on a cloud(Example 1)

[Anoop Ghanwani]

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Russ White
> Sent: Thursday, December 06, 2007 6:20 PM
> To: rbridge at postel.org
> Subject: [rbridge] Orphaned endnodes with partitioned VLANs 
> on a cloud(Example 1)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Suppose we have a simple network, where A, B, and C are all 
> connected to a single link, a broadcast of some type:
> 
> A--+
>    |
>    +--B
>    |
> C--+
> 
> Now, assume all three are members of VLANs 1, 2, and 3 on 
> this link. All three are properly configured to use VLAN 1 as 
> the rbridge vlans. A is designated as the DRB.
> 
> Now, things are running along fine, but, for some reason, A 
> malfunctions, or some such, and can no longer send multicast 
> packets on VLAN 1. The result is that B and C detect they've 
> lost their connection to A, but they won't elect a new DRB at 
> all. Why? Because they are still receiving hello's with A 
> claiming to be the DRB, and with A's original priority and 
> ID, on the other two VLANs.

I don't understand what kind of failure would prevent
sending of multicast packets on VLAN 1.  And if a failure
should happen, the correct thing is for the network
operator to fix the failure. 

> Now the link is completely out of the SPF tree, and not used 
> at all--because of a partial failure on the DRB. This is 
> broken, and unexpected behavior.

 I'm almost certain I will find
scenarios that break even if the hellos are sent per VLAN
(once I see that proposal).  One of the things oft mentioned
on this list is partial connectivity on different VLANs
and the handling of multicast traffic when that happens.
There has been no good solution to that problem.

> The IS-IS hellos are there to find per link bidirectional 
> reachability.
> When you take that away, and assume reachability on one 
> logical link because you have reachability on another logical 
> link, you wind up in a mess that's harder to fix than the 
> original problem you were trying to fix.

I totally understand the need for this, but we also
have to concern ourselves with scalability, or nobody
is going to be able to build this technology at
a price that would make sense to deploy it.

Anoop