[rbridge] it's time to summarize things

Joe Touch touch at ISI.EDU
Thu Dec 15 09:33:01 PST 2005 


Gray, Eric wrote:
>  
> 
> 
> --> 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.

OK - if the idea is:
	- drop BPDUs
	- *assume* the rbridge campus is root
	- allow loops and broadcast storms
Sure. ;-(

> -->
> --> > ----> > 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.

Not everyone is assuming that. If we do assume that, then it's hard to
assert that the rbridge campus (rbridges + logical bridge function)
'blocks' anything.

> 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?

I'm not sure we're all on that page.

We do have other work: in particular, my impression has always been that
the rbridge is invisible to external hosts - it should be, and it must
be. Radia's recent posts hint otherwise, which would require
*substantial* changes to a number of protocols at both L2 and L3 to
preserve L2 functionality through the rbridge+stub system.


> --> > 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.

Why let it be a floating problem? Making the campus the root will do the
same thing, and we know it has no remaining issues. And we also know
what to do *when* an rbridge campus loses root election -  regardless of
the reason. Robustness was a requirement, right?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051215/4febb077/signature.bin

More information about the rbridge mailing list