Subject: [rbridge] it's time to summarize things

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 19 Dec 2005 11:45:04 -0500

Guillermo (or anybody else),

	Could somebody either provide a pointer to earlier
discussion/summary, or provide a brief summary of what we
would use a Designated RBridge for and how it would work?

	I think a lot of questions have come up recently 
that have some bearing on the applicability of designated 
RBridges...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Saikat Ray
--> Sent: Saturday, December 17, 2005 10:53 AM
--> To: Guillermo Ib??ez
--> Cc: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> This was also discussed :) I raised precisely the same 
--> issues. Please see
--> 
--> http://www.postel.org/pipermail/rbridge/2005-October/000687.html
--> 
--> Radia had sent a reply, which I couldn't find in the list. 
--> Anyway, it is
--> sufficient that RBridges see the BPDU's to stop packet 
--> forwarding when a
--> legacy spanning tree starts to change, they do not need to 
--> be a part of
--> the spanning tree for this purpose. But I agree that 
--> merging the spanning
--> tree root bridge selection process with DR selection seems 
--> to be a nice
--> idea.
--> 
--> On Sat, 17 Dec 2005, [ISO-8859-1] Guillermo Ib??ez wrote:
--> 
--> >
--> > Saikat, see below
--> > Guillermo
--> >
--> >
--> > Saikat Ray wrote:
--> >
--> > >>Saikat Ray wrote:
--> > >>
--> > >>
--> > >>
--> > >>>The simplest, if not the most rigorous, explanation is 
--> as follows. Replace
--> > >>>each legacy part of the network by a hub (i.e., first 
--> remove all RBridges
--> > >>>
--> > >>>
--> > >>>from the topology. Then choose a legacy bridge and 
--> replace this bridge and
--> > >>
--> > >>
--> > >>>all legacy bridges that have a path to it by a single 
--> hub, and let all
--> > >>>end-hosts served by those legacy bridges be connected 
--> to this hub. Repeat
--> > >>>this procedure until all legacy bridges are replaced. 
--> Then finally put the
--> > >>>RBridges back.). Now, one and only one RBridge 
--> forwards and receives
--> > >>>unencapsulated packets from each hub (through 
--> designated RBridge).
--> > >>>
--> > >>>
--> > >>>
--> > >>But what happens when two separate hubs with separate RBridges
--> > >>forwarding each one traffic are connected
--> > >>by a link restoration between them?. A single "hub" 
--> will be created with
--> > >>two Designated RBridges till the
--> > >>detect the situation. How (and how fast), the DR 
--> election mechanims
--> > >>should work in this situation?
--> > >>Guillermo
--> > >>
--> > >>
--> > >
--> > >This was discussed long before. The frequency of RBridge 
--> hello messages
--> > >will determine the length of transience (once a hello is 
--> sent, the
--> > >presence of two RBridges on the same "hub" will be 
--> detected). Radia had
--> > >some comments about the numerical value of the 
--> frequency, which I do not
--> > >remember; it is in one of the emails on the list :)
--> > >
--> > >
--> > >
--> > Well, it seems then that we can have loops for all that time.  If
--> > subsecond intervals are needed, Hello Time must be
--> > lower than 1 second. I find this mechanism more costly 
--> than using RSTP,
--> > (already used by the bridges in the hub) to detect the double DR
--> > situation.  By using the Root bridge election mechanism of
--> > RSTP (via colocated bridge), the process uses the 
--> standard RSTP BPDUs
--> > and selects in a reliable form a unique Root bridge and 
--> DR, assuming the
--> > default bridge priority of bridges for election is worse than the
--> > default priority of Rbridges (this can be defined at 
--> will).  Although it
--> > means a small dependency on the 802.1D standard, it seems 
--> more advisable
--> > to rely in a standard mechanism to act in a consistent way than
--> > duplicate the mechanism and ignore RSTP protocol to obtain full
--> > independency.
--> > Rbridges ignoring fully RSTP BPDUs means all that means 
--> for knowing
--> > "link" and tree status are dropped, the risk for malfunction is
--> > increased as  long as Rbridges ignore BPDU information as useless.
--> > One difference is that if DR Hello messages are not received, or
--> > messages from new bridges appear, Rbridges might use 
--> received RSTP BPDU
--> > information to confirm the cause and motivation of messages, so
--> > decisions more consistent with RSTP can be taken.
--> > Perhaps the main argument is that Root bridge election 
--> stops inmediatly
--> > the frame forwarding in link (hub) blocking the loop, 
--> while via DR, the
--> > stopping is done by Rbridges election. That is not the 
--> case if spanning
--> > tree remains active while two DRs coexist on the link 
--> reinjecting the
--> > traffic in the link through the Rbridge campus. The 
--> process requires
--> > full communication between Rbridges through the link 
--> while there is a
--> > loop on it.  Root bridge election does not.
--> > Guillermo
--> >
--> > >> Thus for
--> > >>
--> > >>
--> > >>
--> > >>>a loop formation, a packet must loop back to a 
--> designated RBridge, which is
--> > >>>not possible since RBridges use their own spanning 
--> tree for sending
--> > >>>(encapsulated) broadcast traffic.
--> > >>>
--> > >>>Hope this helps.
--> > >>>
--> > >>>
--> > >>>
--> > >>>
--> > >>>
--> > >>>>-----Original Message-----
--> > >>>>From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On
--> > >>>>Behalf Of Tim Shepard
--> > >>>>Sent: Thursday, December 15, 2005 6:42 PM
--> > >>>>To: Developing a hybrid router/bridge.
--> > >>>>Cc: Radia.Perlman at Sun.COM; 'Joe Touch'
--> > >>>>Subject: Re: [rbridge] it's time to summarize things
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>>Let us suppose that an RBridge is connected to a 
--> legacy bridge's port
--> > >>>>>directly, and all RBridges block BPDUs. Then the 
--> RBridge looks like,
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>from
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>>the perspective of the legacy brige, either (i) a 
--> single end-host (with
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>the
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>>MAC address that of the RBridge) if the RBridge is 
--> not the designated
--> > >>>>>RBridge, or (ii) a shared media (like a hub; is the 
--> standard term
--> > >>>>>"segment"?) with potentially a lot of MAC addresses 
--> attached to it (in
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>fact,
--> > >>>>[....]
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>
--> > >>>>>So what exactly do you think is the problem with ARP?
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>>
--> > >>>>I'm not sure I follow all of the postings on this issue.
--> > >>>>
--> > >>>>But after reading through this thread, I'm still left 
--> wondering what
--> > >>>>is supposed to make sure packets don't loop forever 
--> when there are a
--> > >>>>mix of bridges and rbridges plugged together (in some 
--> crazy accidental
--> > >>>>way, creating whatever kind of loop involving bridges 
--> and rbridges
--> > >>>>that causes the most trouble).
--> > >>>>
--> > >>>>It seems to me that if rbridges block the spanning 
--> tree forming
--> > >>>>packets, but do forward (e.g.) ARP traffic, then 
--> there could be loops
--> > >>>>that are not broken by either the rbridge system or 
--> the usual bridge
--> > >>>>spanning-tree-forming algorithm.
--> > >>>>
--> > >>>>Could someone explain succinctly (for someone who is 
--> just barely
--> > >>>>following this thread) how a system (of mixed bridges 
--> and rbridges,
--> > >>>>plugged together by some Byzantine net admin) will 
--> ensure that packets
--> > >>>>are not forwarded in a loop?
--> > >>>>
--> > >>>>(And ARP is a good example, since it is supposed to 
--> go everywhere, but
--> > >>>>not loop.)
--> > >>>>
--> > >>>>
--> > >>>>Or will there be configuration rules that forbid some 
--> ways of plugging
--> > >>>>together bridges and rbridges?
--> > >>>>
--> > >>>>			-Tim Shepard
--> > >>>>			 shep at alum.mit.edu
--> > >>>>_______________________________________________
--> > >>>>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
--> > >>>
--> > >>>
--> > >>>
--> > >>>
--> > >>>
--> > >>--
--> > >>Guillermo Ib??ez
--> > >>Departamento de Ingenier?a Telem?tica
--> > >>Universidad Carlos III de Madrid
--> > >>1.1.B.11 Colmenarejo 91-6241393
--> > >>4.1.F.13 Legan?s 91-6248794
--> > >>
--> > >>
--> > >>
--> > >
--> > >
--> > >
--> >
--> > --
--> > Guillermo Ib??ez
--> > Departamento de Ingenier?a Telem?tica
--> > Universidad Carlos III de Madrid
--> > 1.1.B.11 Colmenarejo 91-6241393
--> > 4.1.F.13 Legan?s 91-6248794
--> >
--> >
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 20 Dec 2005 18:39:07 +0100

This is from Radia's draft may 2005:

I would add explicitely that Designated RBridge forward and receives all 
trafic from/to the link.

Guillermo

"2.3. Designated RBridge 

   It is useful for one RBridge on each link to have special duties. 
   Thus one RBridge per link should be elected Designated RBridge. IS-IS 
   already holds such an election. 

   The Designated RBridge is the one on the link that will learn the 
   identities of attached endnodes, initiate a distributed ARP when an 
   ARP query is received for an unknown destination, and answer ARP 
   queries when the target node is known. 

 
Perlman                Expires November 2, 2005                [Page 7] "

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794