[rbridge] it's time to summarize things

[Gray, Eric]

--> Gray, Eric wrote:
--> > 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.
-->
--> The TTL is still there, but does NOT (and cannot) affect the L3 TTL. If
--> it does, IP all 1's broadcast will fail. I was speaking only about the
--> effect on the L3 TTL.

Well, then, what's the problem?  If the concern is about
potentially (probably short term) looping of L2 traffic
(especially L2 broadcast/multicast) traffic, and there is
a loop mitigation technique in the works, then this is a
"fairie" problem.

In that case, I think the case for dropping BPDUs is even
stronger.

-->
--> > ----> > 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.
--> 
--> Or, along Guillermo's line, that the rbridge cannot ensure that it is
--> the root of the external spanning trees.

The task of "[ensuring] that [the RBridge) is the root of the external
spanning [tree]" is orthogonal to specification of RBridge functionality.
It is handled - within implementations - by colocation of logical bridge
functionality.  As it is orthogonal, we need do no more than mention it
and get on with the (already plentiful) work at hand.  Since I believe
we have pretty much universal agreement that we should mention it, then
why are we still discussing it?

--> 
--> > 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.
--> 
--> bridges expect that of other L2 devices, yet we're deciding to drop
--> BPDUs. Is it paranoid for a burgler to expect to be burgled?

I think the term is "burglar", but we don't need to make that
an architectural issue...  :-)

Bridges are a reasonably well understood technology that has
been around for quite a while.

When RBridges are an equally well understood technology, that
has been around approximately the same amount of time, I am
sure that this issue will come up.

In the meantime, it is paranoid to assume that any existing 
forwarding devices will arbitrarily decide to junk RBridge
control PDUs.  

If it ever becomes a problem, deal with it when it comes up.

-->
--> > 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
--> > ----> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > rbridge at postel.org
--> > http://www.postel.org/mailman/listinfo/rbridge
--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
--> Sent: Thursday, December 15, 2005 11:07 AM
--> To: Developing a hybrid router/bridge.
--> Cc: 'Radia.Perlman at Sun.COM'
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->