[rbridge] MUST not send spanning tree BPDUs?

Donald Eastlake d3e3e3 at gmail.com
Sun Dec 14 20:07:23 PST 2008


Hi,

I'll go ahead and change the draft, since that seems to be what most
people want. But I don't consider it that big a deal for the following
reason:
       If you wanted to send BPDUs despite the current prohibition,
you would just say that you are implementing a virtual bridge
connected between the RBridge port and the link. That way of thinking
about it makes it crystal clear that RBridges don't participate as a
single node in spanning tree.

Saying that RBridges never forward BPDUs is good but a greater risk
would be that once someone has their RBridge ports participating in
spanning tree they might be tempted to connect the ports together so
that the RBridge as a whole participated in spanning tree. This would
result in a bigger spanning tree causing an increase in blocked ports,
which would thereby become unavailable for use by TRILL, as well as
longer spanning tree settling times, etc.

Donald

On Sun, Nov 30, 2008 at 12:00 AM, Dinesh G Dutt <ddutt at cisco.com> wrote:
> I strongly agree with dropping the sentence and adding the "MUST NOT
> forward" piece,
>
> Dinesh
> Radia Perlman wrote:
>>
>> Yeah. I think we should either drop the sentence, or say "MAY generate
>> BPDUs,
>> but MUST NOT forward BPDUs from
>> one link to another".
>>
>> Radia
>>
>> Donald Eastlake wrote:
>>
>>>
>>> Hi Radia,
>>>
>>> See below...
>>>
>>> On Fri, Nov 28, 2008 at 6:31 PM, Radia Perlman <Radia.Perlman at sun.com>
>>> wrote:
>>>
>>>>
>>>> The spec currently says (in section 4.7.3.3 Transmission of BPDUs)
>>>>
>>>>  RBridges MAY support a capability for sending spanning tree BPDUs for
>>>>  the purpose of attempting to force a bridged LAN to partition as
>>>>  discussed in Section A.3.3.  Except for this optional capability,
>>>>  RBridges MUST NOT send spanning tree BPDUs.
>>>>
>>>>
>>>> I don't remember any discussion on saying that RBridges MUST NOT send
>>>> BPDUs. I remember
>>>> at one point requiring it, and saying that an RBridge is DRB if and only
>>>> if it is the Spanning tree Root.
>>>> (I still would prefer that, by the way -- makes all the controversial
>>>> per VLAN Hellos
>>>> unnecessary).
>>>>
>>>> I remember it being removed from the spec (because of complexity with n
>>>> versions of
>>>> spanning tree, and links with no bridges, perhaps, where the spanning
>>>> tree messages would
>>>> be unnecessary overhead), but I don't remember any reason to say
>>>> RBridges MUST NOT sent
>>>> BPDUs.
>>>>
>>>
>>> I suspect it used to say "do not" in the sense that there is no
>>> RBridge reason for an RBridge port to send spanning tree BPDUs except
>>> for the optional bridge LAN partitioning feature described in Section
>>> A.3.3. In some pass to upgrade to IETF implementation key words, it
>>> probably got changed when it didn't necessarily need to be. The only
>>> problem I can see with dropping this is that it might marginally
>>> increase the chance someone would erroneously try to build spanning
>>> trees through an RBridge.
>>>
>>> Donald
>>>
>>>
>>>>
>>>> Anyone else remember?
>>>>
>>>> Thanks,
>>>>
>>>> Radia
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> rbridge at postel.org
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>> =============================
>>>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>>>  155 Beaver Street
>>>  Milford, MA 01757 USA
>>>  d3e3e3 at gmail.com
>>> _______________________________________________
>>> rbridge mailing list
>>> rbridge at postel.org
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
> We make our world significant by the courage of our questions and by the
> depth of our answers.                               - Carl Sagan
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com


More information about the rbridge mailing list