Subject: [rbridge] loops in trill networks

From: michsmit at cisco.com (Michael Smith (michsmit))
Date: Thu, 13 Oct 2005 09:35:45 -0700

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> 
> Dino,
> 
> 	The argument that an RBridge network provides a layer 2 
> service therefore any frames that are presented should be 
> forwarded is a non sequitur.
> 
> 	This is not even true of bridges now.  Conditions under 
> which a bridge "should" forward frames are somewhat 
> restricted, even if those conditions are typically satisfied 
> under steady-state conditions, for most frames.  There are 
> plenty of examples of situations in which a bridge must not 
> forward frames and other in which a bridge should not forward frames.

For the most part, bridges only terminate their own control protocols,
link layer protocols, and local management traffic.  Since the rbridge
doesn't participate in STP, I see a valid argument that this protocol
should be passed.  This is basically what an 802.1ad bridge does, it
doesn't participate in the customer STP and simply passes the customer
BPDUs through and everything works fine.  On the other hand, since the
goal is to provide an alternative to spanning tree, this would imply
that the entire network will run both rbridging control plane and STP
until it is fully upgraded to rbridges.  If STP is terminated at the
rbridge, there would be incremental benefit of upgrading the network
with rbridges by localizing STP as rbridges are incrementally deployed.
Personally, I feel passing or terminating STP can be equally justified
(and if this is used in the Metro space, we could end up doing both).

Michael

> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: rbridge-bounces at postel.org
> --> [mailto:rbridge-bounces at postel.org]On
> --> Behalf Of Dino Farinacci
> --> Sent: Wednesday, October 12, 2005 5:46 PM
> --> To: rbridge at postel.org
> --> Cc: rbridge at postel.org
> --> Subject: Re: [rbridge] loops in trill networks
> --> 
> --> 
> --> >> 	No, actually, it is not like saying that.
> --> 
> -->     I think the fundamental question that needs to be answered is 
> --> does an
> -->     RBridge network proivde a layer-2 serivce. And I think the 
> --> answer should
> -->     be yes. Therefore any frames that are sent on such a network 
> --> should be
> -->     forwarded.
> --> 
> -->     Two bridges connected via a cable or an RBridge-based network 
> --> should
> -->     look no different. The two bridges should be able to run STP 
> --> over it and
> -->     decide if the ports leading to such a network are in 
> Blocked or 
> --> Forward
> -->     state.
> --> 
> -->     The RBridges should forward such packets like any 
> other frames. 
> --> The only
> -->     frames that RBridges will consume and process are 
> IS-IS packets 
> --> (which
> -->     will be multicasted on a *new MAC group address*).
> --> 
> --> Dino
> --> _______________________________________________
> --> rbridge mailing list
> --> rbridge at postel.org
> --> http://www.postel.org/mailman/listinfo/rbridge
> --> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 13 Oct 2005 13:06:17 -0700

I'm travelling and not necessarily following this whole thread.

However...I think it actually would work to have RBridges forwarding 
spanning tree messages. It would
result in lots of little trees, partitioned because data traffic must 
not be forwarded mindlessly along
that super-tree, but all the little trees would think the same ID was 
Root bridge.

I think this is suboptimal, since the larger the spanning tree, the 
slower convergence would be.
So I think it's a lot better to have RBridges not forward spanning tree 
messages, and keep the
bridge spanning trees really separate.

We could think of it as RBridges "participating" in 802.1d spanning tree 
by simply consuming
the messages (and not doing anything other than dropping them).

Radia

---

From: dino at cisco.com (Dino Farinacci)
Date: Thu, 13 Oct 2005 17:16:48 -0700

>> slower convergence would be.

    So that's a good point we should also decide on. If the introduction of
    RBridges causes traditional bridged networks to get larger, we could
    introduce a scaling problem by making STP work harder than it was
    originally designed for. 

    Now, yes, anyone could tunnel over any infrastructure and create an
    overlay topology (i.e. VPLS and L2 metro networks) but do we want to make 
    it more inherent in the architecture.

>> bridge spanning trees really separate.

    I think I can go along with this too but we need to state that an RBridge
    network is not a traditional L2-based subnet. I think there are other
    reasons to claim this already (i.e. low incident forwarding loops and
    duplicate packets) so we wouldn't be setting a precedent for this case.

>> the messages (and not doing anything other than dropping them).

    Sure, makes sense.

Dino