Subject: [rbridge] loops in trill networks

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 12 Oct 2005 18:35:35 -0300

Peter,

	With some exceptions (already discussed between
Dino and Radia), we don't want an STP based spanning
tree being setup across RBridges.

	There are a lot of potential interaction models
between bridges and RBridges. RBridges could be made
to appear transparent to bridges, but this is not the
reason why RBridges are being defined, nor would we
need to define - or use - an encapsulation between 
pairs of RBridges if this is all we wanted to do.

	Instead, the normal case should be for RBridges
to terminate the local broadcast domain and the local
STP-based spanning tree. To do this, RBridges should
act as if they were hosts to STP and ignore it.

	If they do not, then there may be scenarios in
which a bridge - thinking that an RBridge is another
bridge - will make an incorrect assumption about the
forwarding state of the local port of that "bridge".
There are doubtless many ways we could finesse this,
but what would we gain from doing so other than a lot
of needless complexity?

	For specific exceptions, it is possible to use
tunneling to create additional "virtual link(s)" -
between a broadcast domain on one side (RBridge port)
and one or more other broadcast domains on (an)other
side (RBridge port).  In this case, the RBridges that
are involved would absolutely pass all traffic between
each such broadcast domains - including flooded and
BPDU frames - most likely without looking at them.
In this sense, such exceptions would appear to the 
broadcast domains (and any directly attached bridges)
as a Hub - i.e. - they would be transparent except to
the extent that they would make multiple connections
possible.

	Because RBridges in this case would appear as a
Hub, it would then be up to the STP between bridges
in each connected broadcast domain to ensure that a
loop-free STP exists.  This works today, and we have 
no reason to suspect that it should not work in the
future.

	Another model that has been suggested is that
the RBridges in this case would act like an aggregate
bridge.  This could be done, but it cannot be done as
the default because - as has been indicated previously 
- it is not possible for RBridges to distinguish LANs
that are "outside" the RBridge domain from LANs that 
are "inside" the RBridge domain except by configuration.

	If the RBridges are configured to act as a bridge
in the aggregate, then the IS-IS MAC reachability will
need to provide sufficient information to those RBridges
to allow them to effectively populate filtering database
information for the "outward" facing RBridge ports, and 
those ports will have to collectively participate in STP 
across the "outside" collective broadcast domains - to 
include managing port forwarding state.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Peter Ashwood-Smith
--> Sent: Wednesday, October 12, 2005 4:20 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> 
--> What 'precisely' is the problem with a BPDU getting through 
--> an Rbriged
--> network ? It certainly does not break Rbridge so how does 
--> it break STP?
--> 
--> The designated Rbridge pretty much ensures that the STP on each side
--> only sees one link to it, the STP protocol should continue 
--> normally on
--> either side of the Rbridge. No?
--> 
--> 
--> Peter
--> 
--> 
--> 
--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On
--> Behalf Of Gray, Eric
--> Sent: Wednesday, October 12, 2005 3:46 PM
--> To: 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> Dino,
--> 
--> 	No, actually, it is not like saying that.
--> 
--> 	Given that we expect to have bridges between Rbridges
--> (though they're supposed to be invisible to RBridges), and
--> the fact that we expect to have Rbridges connected to each 
--> other, it is
--> not at all bizarre to expect that we might end up with a bridge
--> connected to an RBridge on the same port that the RBridge 
--> is connected
--> to another RBridge.  Like this:
--> 
--> 
--> 	RB-1 ---+--- RB-2
-->               |
-->               |
-->              B-3
-->               |
-->               |
-->       RB-4 ---+
--> 
--> Moreover, there should be nothing problematic about this 
--> topology either as it will look to the RBridges like this:
--> 
-->       RB-1 ---+--- RB-2
-->               |
-->               |
-->             RB-4
--> 
--> And to B-3 like this:
--> 
-->        H-1 ---+--- H-2
-->               |
-->               |
-->              B-3
-->               |
-->               |
-->              H-4
--> 
--> As you implied, the normal case is that enclosing RBridges
--> - like routers - will look to enclosed bridges like hosts.
--> I merely stated that RBridges - like hosts - can ignore any 
--> BPDUs they
--> receive.
--> 
--> --
--> 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 3:08 PM
--> --> To: rbridge at postel.org
--> --> Cc: rbridge at postel.org
--> --> Subject: Re: [rbridge] loops in trill networks
--> --> 
--> --> 
--> --> >> 	I believe that many of today's bridges can be 
--> configured to not 
--> --> >> send BPDUs on specific ports, but we do _not_ want 
--> to rely on 
--> --> >> this.  For example, what do we do if both a bridge 
--> and an RBridge
--> 
--> --> >> are connected to the same port of the bridge we are 
--> talking about
--> 
--> --> >> (imagine a simple Hub between three+ devices)?
--> --> 
--> -->     This is like saying if you run IS-IS on an interface
--> --> you should not run
--> -->     OSPF on the interface. And to make sure you don't the 
--> --> IS-IS standard
--> -->     states you must drop all other protocol messages. Which 
--> --> it does not!
--> --> 
--> --> 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

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 12 Oct 2005 19:35:02 -0700

> act as if they were hosts to STP and ignore it.

Eric,
I'm not sure we have a useful definition for "local broadcast domain" - 
we have a broadcast domain which spans the whole rbridged network so 
that IP broadcast continues to work as before.

I think that having rbridges act as if they are hosts is a good starting 
point to think about the problem. But the desire to attach the local 
(bridged) segment to multiple rbridges for redundancy makes things a bit 
more complex. Take this picture:

	   H4
             |
	( Rest of rbridged network )
	 |                       |
	RB1                     RB2
          |                       |
	( bridged cloud at edge    )
          |      |          |
	H1     H2         H3

Suppose RB1 has been elected as the forwarder to/from the bridged cloud.
This means that the bridges have learned (from received packets) that 
packets to MAC addresses in the rest of the network (e.g., H4) should be 
sent towards RB1.

What happens when RB1 fails? RB2 would take over, and the routing 
protocol would quickly cause the other rbridges to find out.
But packets from H1 to H4 will continue to be forwarded by the bridges 
towards RB1 until those learning tables time out, or until a packet from 
H4 arrives via RB2.

If we want to ensure that the bridges more quickly find out that they 
should use RB2, it would seem like we need to add something in the 
interaction at the edge. Effectively we want RB2 to be able to tell the 
bridges in the cloud either
  - that they should discard their learning tables, or
  - that they should switch to use RB2.

I haven't looked at the options in detail, but perhaps we can do the 
first by RB2 injecting a toplogy change BPDU?
For the second approach, one could envision the RBs at the edge 
presenting themselves as a bridge with a low cost to an imaginary root 
bridge (which represents the rbridge core)? Of course, we can't ensure 
that the imaginary becomes the root bridge; the best we can do is to 
have it have a high probability of becoming the root bridge from the 
perspective of the bridged cloud at this part of the edge.
I don't think this requires that BPDUs be carried across the rbridged 
cloud - each bridged cloud at the edges can be treated as separate.

I don't know how fancy we need to be here, but waiting for the learning 
tables to time out when there is an RB failures seems a bid bad.

    Erik