[rbridge] it's time to summarize things

[Gray, Eric]

Radia and all, 

	I've included some detailed responses below, but the 
short answer is that I completely agree with Radia...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Thursday, December 15, 2005 1:02 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> 
--> 
--> Joe Touch wrote On 12/14/05 21:33,:
--> > 
--> 
--> > Routers terminate L2 broadcasts. Rbridges cannot. Routers decrement L3
--> > TTLs. Rbridges cannot. So the assertion that an rbridge campus should
--> > drop BPDUs - just like routers - doesn't follow.
--> 
--> I really don't understand what you're saying. RBridges can
--> terminate some L2 broadcasts, in particular, spanning tree messages.
--> True, RBridges will not decrement L3 TTLs.

At one point, we were talking about a TTL field in the encapsulation
for RBridge to RBridge tunneled packets.  I am not sure what happened
to that idea.

--> And perhaps the assertion that RBridges should drop BPDUs does not
--> follow from the previous two sentences, but regardless, they
--> should drop BPDUs because that's what works, that's what is
--> simple, that's what makes the combination of bridging and RBridging
--> more robust than bridging alone, that's what preserves transparency
--> to layer 3 and yet increases robustness.

Clearly I completely agree with this argument.

--> > 
--> > So at the very least we need to explain the reason for this behavior
--> > more clearly, in a way that does not refer to routers as equivalent.
--> 
--> Hopefully the above explains why it has to work this way. We want
--> to break up the spanning tree into smaller and smaller spanning
--> trees, hopefully eventually getting rid of them entirely and
--> just having one big link state routed zero configuration 
--> infrastructure.
--> 

I believe this is consistent with the WG's charatered objectives.

--> 
--> > 
--> > AFAICT, having an rbridge campus drop BPDUs makes sense only by
--> > effectively considering the rbridge campus as the root of all trees,
but
--> > that presumes it is always _the_ root (that there is only one 'drops
--> > BPDU' system per bridged LAN). Since there's no way to enforce that
--> > assertion, it seems problematic.
--> > 
--> > Joe
--> 
--> The above paragraph makes absolutely no sense to me.
--> 
--> Routers drop spanning tree messages, and the world winds up with
--> lots of isolated spanning trees. The same thing happens with
--> RBridges. If there were a problem with doing it this way,
--> IP mixed with bridges would not work.
--> 

The argument that edge RBridges should do something about BPDUs
(other than drop them) proceeds from a suspicion that RBridges 
will not always be able to detect a loop that is external to the
RBridge campus.  This implies that <something> - out of either
malicious design or accident - will consistently drop RBridge 
hello/discovery PDUs.

Unless we decide to use BPDUs, this is a paranoid suspicion.
Bridges do not consistenly drop any kind of frames unless this
is part of the specified behavior for bridges.  The same will
also apply to other technologies.

There is a possibility that RBridge interactions may interfere
with propagation of RBridge hello/discovery PDUs, but we are in
the process of defining how RBridges work - so we can finesse
that as we go along, by either prohibiting anti-social behviors
or by specifying how such interactions can work.

So, as Radia says, there is no reason what-so-ever to encourage
RBridges to particpate in STP/RSTP.

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