Subject: [rbridge] loops in trill networks

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

Larry,

	I don't think we're disagreeing.  The trouble is in the 
phrase "spanning tree".  What I am trying to say is that how
frames are forwarded between RBridges (e.g. - RB3 and RB4) is
determined by a different protocol than is used to make the
same determination for frame forwarding between bridges.

	Yes, the effect is similar to a "spanning tree" as will
be determined by STP between bridges, but it is not the same.
For RBridges RB1, RB2, RB3 and RB4, the topology you posit is
going to be marginally simpler:

      A--RB1----+--RB2--B
          |     |
          |     |
      D--RB4---RB3--C

All of the RBridges see the topology this same way. I assume
that the difference between this and any other form of link
state routing is that routers aren't _normally_ concerned
with broadcast. However, routers will have to deal with IP
multicast, and the difference between broadcast and multicast
is not important, as the same topology issues arise in IP 
multicast routing - especially if you assume a majority of
routers in any locality might be serving the same multicast
group.

	We don't want to use STP to determine how to avoid loops
and duplicate transmissions because using a link-state routing
protocol allows us to make clever use of redundant connections.
This is the important logical distinction.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Larry Kreeger (kreeger)
--> Sent: Tuesday, October 11, 2005 7:42 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> Eric,
--> 
--> Notice that in my example below, I am only talking about broadcast
--> connectivity - not unicast.  There is not MAC advertisements for
--> broadcast.  A broadcast must go to every edge port.  In this case, a
--> spanning tree must exist (across both the RBridge and 802.1d bridged
--> network) or a broadcast loop will occur.
--> 
-->  - Larry
--> 
--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On
--> Behalf Of Gray, Eric
--> Sent: Tuesday, October 11, 2005 3:45 PM
--> To: 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> Larry,
--> 
--> 	You have to think of bridges and RBridges as existing at two
--> layers.  How frames are forwarded between RBridges will be 
--> determined by
--> shortest path computation based on MAC advertisements in IS-IS.  How
--> frames are forwarded across
--> 802.1 bridges between RBridges is based on STP.
--> 
--> --
--> E
--> 
--> --> -----Original Message-----
--> --> From: rbridge-bounces at postel.org
--> --> [mailto:rbridge-bounces at postel.org]On
--> --> Behalf Of Larry Kreeger (kreeger)
--> --> Sent: Tuesday, October 11, 2005 5:08 PM
--> --> To: Developing a hybrid router/bridge.
--> --> Subject: Re: [rbridge] loops in trill networks
--> --> 
--> --> 
--> --> Radia,
--> --> 
--> --> How about the case where the two ports connected to the 
--> same bridged
--> 
--> --> domain are on different RBridges?
--> --> 
--> --> Consider, the following topology where A,B,C are hosts.
--> --> 
--> --> A--RB1--Bridged-Domain--RB2--B
--> -->               |
--> -->               |
--> -->              RB3--C
--> --> 
--> --> In this case, would all RB's forward a L2 broadcast to their 
--> --> respective edge ports?  I was assuming, yes.  If so, 
--> then RB1,RB2 
--> --> and
--> --> RB3 are all
--> --> designated RBs in order to have broadcast connectivity between 
--> --> A,B,C.
--> --> 
--> --> Now a new RB4 is added to the topology which connects 
--> RB1 and RB3,
--> --> 
--> --> A--RB1--Bridged-Domain--RB2--B
--> -->     |         |
--> -->     |         |
--> --> D--RB4-------RB3--C
--> --> 
--> --> Are you saying that RB1 and RB3 detect that they now have new 
--> --> connectivity and battle to be a Designated RB to serve 
--> their side of
--> 
--> --> the network?  Assuming RB3 wins, all broadcasts must 
--> enter and leave
--> 
--> --> the Bridged-Domain via RB3 to get between hosts A,C,D and B.
--> --> RB2 must still
--> --> be the Designated RB for traffic to reach B.
--> --> 
--> --> I didn't think routers needed to deal with this since 
--> they don't 
--> --> forward broadcasts.  Are you saying that routing 
--> protocols already 
--> --> deal with these types of scenarios?
--> --> 
--> --> Thanks, Larry
--> --> 
--> --> -----Original Message-----
--> --> From: rbridge-bounces at postel.org
--> --> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> --> Sent: Tuesday, October 11, 2005 12:46 PM
--> --> To: Developing a hybrid router/bridge.
--> --> Subject: Re: [rbridge] loops in trill networks
--> --> 
--> --> The intention is that deployment not have to be 
--> careful. If two of 
--> --> an RBridge's ports are connected to the same bridged broadcast 
--> --> domain (i.e., there is a bridge-connected path between the two 
--> --> ports), then the RBridge will think it has two ports 
--> connected to 
--> --> the same link. Which is OK.
--> --> It won't forward any packets, including not BPDUs, 
--> between those 
--> --> ports.
--> --> At most one of
--> --> its ports will become "designated" for sourcing/sinking 
--> --> unencapsulated traffic to/from that link.
--> --> 
--> --> It would be just like a router having two ports 
--> connected to the 
--> --> same link, which should work with no problem.
--> --> 
--> --> Radia
--> --> 
--> --> 
--> --> 
--> --> Gray, Eric wrote:
--> --> 
--> --> >Radia,
--> --> >
--> --> >	If I am understanding what you are saying 
--> correctly, there are
--> --> some
--> --> >deployment issues with Rbridges into a 802.1 bridged 
--> environment.
--> --> >
--> --> >	The deployment issues arise when individual RBridges are
--> --> installed, if
--> --> >this is not carefully planned in advance.
--> --> >If an Rbridge is installed on a link where it is connected
--> --> to two or
--> --> >more 802.1 bridges and there is another L2 path 
--> between those two 
--> --> >bridges, the RBridge will either have to forward BPDUs 
--> or - like a 
--> --> >router - recognize that multiple ports are connected to
--> --> the same LAN.
--> --> >
--> --> >	Is there an intention that the latter would be 
--> the default case
--> --> until
--> --> >and unless the installed RBridge is able to discover a 
--> connected 
--> --> >RBridge peer?
--> --> >
--> --> >--
--> --> >Eric Gray
--> --> >
--> --> >--> -----Original Message-----
--> --> >--> From: rbridge-bounces at postel.org 
--> --> >--> [mailto:rbridge-bounces at postel.org]On
--> --> >--> Behalf Of Radia Perlman
--> --> >--> Sent: Tuesday, October 11, 2005 12:44 PM
--> --> >--> To: Developing a hybrid router/bridge.
--> --> >--> Subject: Re: [rbridge] loops in trill networks
--> --> >--> 
--> --> >--> 
--> --> >--> There's nothing an RBridge can do about loops
--> --> consisting of just
--> --> >--> bridges.
--> --> >--> Which is why it's good to partition the spanning trees
--> --> formed by
--> --> >--> the bridges so that the remaining spanning trees are
--> --> as small, and
--> --> >--> therefore as stable, as possible.
--> --> >--> 
--> --> >--> RBridges are like routers. They sit at a layer above
--> --> bridges. The
--> --> >--> bridges form what looks like a single link to the 
--> RBridges. If 
--> --> >--> there are a bunch of bridges connecting a bunch of
--> --> segments, all
--> --> >--> the RBridges attached to that portion of the 
--> network see that 
--> --> >--> bridged segment as a single link.
--> --> >--> 
--> --> >--> Radia
--> --> >--> 
--> --> >--> Loa Andersson wrote:
--> --> >--> 
--> --> >--> >Oh, yes it is true ...
--> --> >--> >
--> --> >--> >but I thought that a trill network could consist of a
--> --> mixed of
--> --> >--> >rbridges and the type of bridges that exist today, if
--> --> that is the
--> --> >--> >case you can possibly form the loop over only non-rbridges
--> --> >--> >
--> --> >--> >but I'm not up to speed on this, there might be a way
--> --> to handle
--> --> >--> >this also
--> --> >--> >
--> --> >--> >/Loa
--> --> >--> >
--> --> >--> >Joe Touch wrote:
--> --> >--> >  
--> --> >--> >
--> --> >--> >>There is, and that's what it's there for.
--> --> >--> >>
--> --> >--> >>Joe
--> --> >--> >>
--> --> >--> >>Mike Hughes wrote:
--> --> >--> >>
--> --> >--> >>    
--> --> >--> >>
--> --> >--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson 
--> <loa at pi.se>
--> --> wrote:
--> --> >--> >>>
--> --> >--> >>>
--> --> >--> >>>
--> --> >--> >>>      
--> --> >--> >>>
--> --> >--> >>>>this might be an old discussion, but it is some
--> --> time since it
--> --> >--> >>>>look at it. What do we do in trill networks about
--> --> transient
--> --> >--> >>>>loops, i.e. if use link state protocols there is a
--> --> possibility
--> --> >--> >>>>that we have transient loops. With no TTL mechanisms
--> --> >--> those looping
--> --> >--> >>>>frames could cause quite a bit of problem.
--> --> >--> >>>>        
--> --> >--> >>>>
--> --> >--> >>>Unless I've missed something, or things have changed
--> --> >--> overnight, there is a
--> --> >--> >>>TTL provided in the SHIM header.
--> --> >--> >>>
--> --> >--> >>>Mike
--> --> >--> >>>
--> --> >--> >>>
--> --> >--> 
--> >>>---------------------------------------------------------
--> --> >--> ---------------
--> --> >--> >>>
--> --> >--> >>>_______________________________________________
--> --> >--> >>>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
--> --> >  
--> --> >
--> --> 
--> --> _______________________________________________
--> --> 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
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->