[rbridge] potential L2 forwarding loop issue in RBridges

[Anoop Ghanwani]

I am not going to argue about whether or not this
is a real problem since you have actually run into it.
It may not be one that would happen to an informed
user (per Eric's response), but then there is always
an ill-informed implementer/deployer out there and if
you run things according to spec, then such problems 
are a no-no. 

>   A.  Require TRILL IS-IS implementations to send very small Hello
>       messages, not MTU-padded, and with as little information as we
>       can manage.  (If we need "large" Hellos, then send small ones
>       occasionally as well.)  This allows the loop avoidance part to
>       do its work.
> 
>       (Or perhaps the MTU that IS-IS uses should not be the actual MTU
>       needed along the path with TRILL overhead, but the MTU for data
>       packets, since IS-IS is now going unencapsulated.  But then this
>       means that MTU-restricted paths are unprotected and cannot be
>       detected by normal IS-IS operation.  We end up with the black
>       hole problem.)

This is certainly doable, but I'm not sure it's
robust enough.  It almost falls in the category of
what Eric said.

>   B.  Require RBridge implementations to include STP as well.
>       However, the STP portion in this solution has (by design) no
>       effect on TRILL itself.  Instead, we use STP's link "forwarding"
>       state to gate the AF behavior in the following ways:
> 
> 	i.  When STP reports that the link is not in "forwarding"
> 	    state, we refuse to become AF for any VLAN.  We become AF
> 	    only if STP reports "forwarding" for the link *and* the
> 	    DRB appoints us to do it.
> 
> 	ii. When encapsulating from or decapsulating to native format,
> 	    examine both the AF flag and the STP state.  Discard the
> 	    packet if not AF or if STP state is not "forwarding."

The problem I have with this is that thus far we have been
assuming we terminate STP at RBridges.  If we are to require
that RBridges participate in STP, then are the different ports
considered different instances or the same instance?  If they
are the same instance, we risk creating a giant spanning tree
that goes across RBridges.

Or maybe I'm missing something...perhaps you can provide
more detail on what you meant.

Anoop