[rbridge] it's time to summarize things

[gibanez at it.uc3m.es ( Guillermo Ibáñez )]

Radia,
        

Radia Perlman wrote:

>I just got back from a bunch of travel, and was trying to catch
>up on the mailing list, and it's really so long.
>
>It looks like the thread of whether RBridges participate
>in spanning tree popped up again. I thought that had been
>resolved.
>
>RBridges should NOT participate in spanning tree, which means
>they should DROP spanning tree messages.
>
>An RBridge should NOT merge spanning trees. It should terminate
>spanning trees, just like routers do.
>
>However things have
>to work properly if two of an RBridge's ports are in the same
>broadcast domain (either because they are the same
>physical link or because a path of bridges connects those
>two ports of the RBridge. Just like routers handle this case just
>fine, RBridges will handle the case just fine.
>
>One person (I forget who) brought up a case ahile ago where they thought
>it would be advantageous for an RBridge to participate in
>spanning tree (so that it could cause itself to be
>elected Root).
>
I am the person you refer.

> I'm not convinced this is an important
>feature, but it can be handled by having the RBridge
>pretend to be two boxes glued together: an ordinary bridge,
>directly connected to the port, with a point-to-point imaginary
>link to an RBridge. The person agreed this idea could be
>built, and would give any advantages that might be gained
>by having RBridges particpate in spanning tree, while
>still maintaining the simple premise that RBridges,
>like routers, operate above spanning tree, and do nothing
>with spanning tree other than recognize that layer 2
>multicast address and drop packets sent to that address.
>  
>
I do agree

>If this (i.e., RBridges drop spanning tree messages)
>is not the understanding at this point, can someone
>summarize (succinctly, without cutting and
>pasting from zillions of email messages, which I find
>hard to follow) what the problem with this is?
>
>  
>
There is a lot of discussion going on . I make here some fast comments 
to state my position.
The point is that in my opinion DR election among Rbridges connected to 
same "link" (stp bridged area)
may be performed by the Root bridge election mechanism or a combined 
mechanism of both(DR and root election) , to be designed. I see 
advantages in this use of integration with the frame forwarding 
mechanism of stp (root bridge is the best position for it and for 
ingressing traffic into the Rbridge campus)
The current discussion on alternative modes (BLOCK, PARTICIPATE, etc) 
reflects the dilemma that derives from the need  Rbridges have to 
*control the tree connected to them*, to ingress and egrees traffic 
from/to them.
I see two options for predecibility of network.
1.-If only one Rbridge is allowed to become DR (i.e.root) of its link, 
some Rbridges (those not being elected) will not forward traffic of some 
ot the links they are connected to, because other connected Rbridge does 
the forwarding.
2.- If we allow any Rbridge to ingress/egress traffic to the Rbridge 
campus  we need to allow to split the link spanning tree in to 
independent segments, each one connected to an Rbridge (acting as 
independent root bridge or something equivalent). This goes a bit 
against the "unique" spanning tree dogma, but can be safe in an Rbridge 
controlled environment, provided each Rbridge acts as Root bridge to 
inject traffic to core network.
In my opinion, much of the complexitiy and confusion derives from the 
decision to allow bridges to interpose between Rbridges.
This makes many  links internal (whenever there is another Rbridge 
heard) and external (whenever they have an end system connected) at the 
same time. Using this term  in this way is  only confusing.
This flexibility of allowing standard bridges betwen Rbridges, as you 
know well, implies also the need to rewrite the destination Rbridge in 
the frame header at each hop with the next hop, a not very nice feature 
of the protocol proposed.  I find excesive in this case the price paid 
for  full compatibility with standard bridges.
In my recently submitted I-D draft   
(http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt)  
I  propose, among other variants to Rbridges,  the topological 
restriction of  Rbridges being connected directly  by point to point 
links (which make sense talking of  campus network cores, oriented to 
performance).  By using an automatic compatibility mechanism like the 
one used in 802.1D for compatibility between STP and RSTP protocols, a 
port will set itself as "internal"  (core port in the draft) if it hears 
Rbridge hellos (or Rbridge related BPDUs) and  as "external" port 
("access" port) port mode. In this way the "external" links are excluded 
from the Rbridge core and the obtained core is fully composed of 
interconnected Rbridges.
In RSTP, a port hearing STP BPDUs in its link, switches to STP mode. It 
initializes to RSTP mode if it hears RSTP BPDUs upon initialization. 
(Protocol migration state machine).

As a summary I would say that it is difficult to ignore completely stp 
and links, Rbridges must PARTICIPATE in stp only as Root bridges or end 
nodes.
The compatibility clause (B-RB implementation) is acceptable, although 
is not perfect in my opinion  because I see the participation as Root as 
important for controlling the tree below Rbridge and to perform the DR 
function.
Guillermo

>Radia
>
>_______________________________________________
>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