Subject: [rbridge] RBridge/bridge interaction

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 24 Oct 2005 12:44:27 -0300

I think we should leave that sort of determination to the
supposed wisdom of the successful implementer. But I won't
object to text along these lines if someone else wants to
write it...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Radia Perlman
--> Sent: Saturday, October 22, 2005 4:59 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> And another thought. Although I don't think we should 
--> include the notion of
--> a combined bridge/RBridge in the spec for RBridges,
--> just a suggestion for anyone that wants to build this beast...
--> 
--> It would be nice to minimize configuration, so especially 
--> if the reason 
--> for making a
--> bridge/RBridge is to
--> make an RBridge have higher priority for being bridge spanning tree 
--> Root, have the priority for
--> bridge Root be a function of the RBridge IS-IS DR priority, 
--> so you only 
--> have to set one
--> of them.
--> 
--> We don't have to debate this, since this if it's not in the RBridge 
--> spec, vendors can
--> do whatever they want. But it's perhaps good to have 
--> suggestions posted 
--> publicly.
--> 
--> Radia
--> 
--> 
--> 
--> Peter Ashwood-Smith wrote:
--> 
--> >Likewise.
--> >
--> >  
--> >
--> >>-----Original Message-----
--> >>From: rbridge-bounces at postel.org 
--> >>[mailto:rbridge-bounces at postel.org] On Behalf Of Gray, Eric
--> >>Sent: Friday, October 21, 2005 6:16 PM
--> >>To: 'Developing a hybrid router/bridge.'
--> >>Subject: Re: [rbridge] RBridge/bridge interaction
--> >>
--> >>
--> >>I also agree that this is a quite feasible approach.
--> >>
--> >>--
--> >>Eric
--> >>
--> >>--> -----Original Message-----
--> >>--> From: rbridge-bounces at postel.org
--> >>--> [mailto:rbridge-bounces at postel.org]On
--> >>--> Behalf Of Guillermo Ib??ez
--> >>--> Sent: Friday, October 21, 2005 6:01 PM
--> >>--> To: Developing a hybrid router/bridge.
--> >>--> Subject: Re: [rbridge] RBridge/bridge interaction
--> >>--> 
--> >>--> 
--> >>--> Right. In this way both views are covered. I fully agree. 
--> >>Guillermo
--> >>--> 
--> >>--> Radia Perlman wrote:
--> >>--> 
--> >>--> >Actually, here's a suggestion that may make us all happy.
--> >>--> >
--> >>--> >Keep the design of RBridge independent of bridges. 
--> >>RBridges do not
--> >>--> >participate
--> >>--> >in spanning tree (other than throwing away BPDUs).
--> >>--> >
--> >>--> >However, to get the functionality that Guillermo
--> >>--> wants....allow someone
--> >>--> >to build a device that's logically the
--> >>--> >same as a bridge glued onto an RBridge. To the rest of the
--> >>--> world it
--> >>--> >would look
--> >>--> >like this:
--> >>--> >
--> >>--> >bridged island----B1----RB1
--> >>--> >
--> >>--> >where B1 is a bridge with two ports...a pt-to-pt link to
--> >>--> RBRidge RB1,
--> >>--> >and a link to the
--> >>--> >bridged LAN.
--> >>--> >
--> >>--> >The "RB1" portion of this box does what the architecture
--> >>--> of an RBridge
--> >>--> >does...it neither
--> >>--> >forwards, nor initiates spanning tree messages.
--> >>--> >
--> >>--> >However, the "B1" portion of the box acts like a vanilla
--> >>--> bridge, and
--> >>--> >does participate in
--> >>--> >spanning tree. And it can be configured to have whatever
--> >>--> priority people
--> >>--> >want.
--> >>--> >
--> >>--> >If it's commercially important for RBridges to have the
--> >>--> capability of
--> >>--> >participating in
--> >>--> >the bridge protocol, it can be done this way without
--> >>--> defining it into
--> >>--> >either the RBridge
--> >>--> >or bridge functionality.
--> >>--> >
--> >>--> >Radia
--> >>--> >
--> >>--> >
--> >>--> >
--> >>--> >Guillermo Ib??ez wrote:
--> >>--> >
--> >>--> >  
--> >>--> >
--> >>--> >>Root bridge planning is something required in campus
--> >>--> networks, it just
--> >>--> >>means configure the 16 bit priority of the preffered root
--> >>--> bridge (and
--> >>--> >>perhaps a root reserve) with a low enough value under the
--> >>--> default value.
--> >>--> >>
--> >>--> >>    
--> >>--> >>
--> >>--> >
--> >>--> >
--> >>--> >_______________________________________________
--> >>--> >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
--> >>--> 
--> >>_______________________________________________
--> >>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
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 25 Oct 2005 11:55:38 +0200

Eric,  Radia :

According to Eric suggestion to include text, I have used Radia?s text 
(as clarifying as usual) to describe it and added a final sentence (not 
mandatory) on the default value for RBridges. Feel free to "improve" it.
Guillermo

RBridge indirect participation in bridged island spanning tree. 
---------------------------------------------------------------
RBridges by default do not participate in spanning tree in other way than ignoring received BPDUs. It is an objective of RBridge specification to be independent of bridges specifications as much as possible.   
 However it may be convenient for RBridges in some circumstances to participate in the spanning tree and contend to be root bridge of the spanning tree formed in the bridged island they are attached to. In these cases it is possible to build a device that's logically the same as a bridge glued onto an RBridge. The following schema applies:

                        ?-----------?
       bridged island-----B1----RB1 ?
                        ?-----------?

                        RBridge/bridge box

where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1, and a link to the bridged LAN. The "RB1" portion of this box acts as an standard RBridge, it neither forwards, nor initiates spanning tree messages. The "B1" portion acts as two-port standard 802.1D bridge, and does participate in spanning tree. Its priority for root election can be set in the standard way. To minimize configurafion, it may be convenient in some implementations to make the standard B1 bridge priority a function of the configurable RBridge priority for IS-IS Designated RBridge election. In this way Designated RBridge will participate and contend (as B1) to be elected also as root bridge of the bridged island and only one priority configuration is required. 

If (in environments using such implementations) the default bridge priority for B1 is lower than standard bridge priority, by default RBridges/bridges like B1 shown will become roots of their bridged islands, contending only with other RBridges connected to same island for root election. 

Gray, Eric wrote:

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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 25 Oct 2005 11:59:21 +0200

Eric,  Radia :

I have use Radia?s text as much as possible to describe it as a first 
proposal  and added a final sentence on the default value for RBridges. 
Feel free to correct english expressions.
Guillermo

                        ?-----------?

                        RBridge/bridge box

In environments using such implementations, if the default bridge priority for B1 is lower than standard bridges priority, RBridges/bridges like B1 will become roots of their bridged islands, contending only with other RBridges connected to same island for root election.

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 25 Oct 2005 12:13:40 -0700

No objection to inclusion of the text proposed by Guillermo, as long as 
it's clear it's not mandatory for all RBridges to
be combined bridge/RBridges.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20051025/4ce68aaf/attachment.html

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 25 Oct 2005 12:15:59 -0700

Another interesting question....exactly how should an RBridge recognize 
a BPDU in order to
discard it? If I remember correctly, the layer 2 multicast address used 
for BPDUs (including
"topology change notifications") is only used for bridge messages. If 
that's true, then
is that the criteria RBridges should use, i.e., discard any messages 
sent to that layer 2
multicast address?

It's conceivable that there is some management thing that might be sent 
to "all bridges". In
that case, it's possible we'd want such messages forwarded across the 
RBridges, and treated
like other layer 2 multicasts within what I was calling the "campus". Or 
a case could be
made that such a message should go only to the bridged island, just as 
such messages would
not be forwarded through routers.

But if that layer 2 address is only used for spanning tree (including 
topology change notifications),
then it's safe for RBridges to look no further than the layer 2 
destination address, in terms
of what should be discarded.

If not (if that layer 2 address is used both for spanning tree messages 
which RBridges should
discard, and for other messages that RBridges should forward), then we 
should specify
which fields other than the layer 2 header destination address that 
RBridges would need to
look at in order to know what to discard.

Radia

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 26 Oct 2005 08:42:42 +0200

Radia Perlman wrote:

> No objection to inclusion of the text proposed by Guillermo, as long 
> as it's clear it's not mandatory for all RBridges to
OK. Add this sentence explicitly: "It is not mandatory for RBridges be 
combined bridge/RBridges".
Guillermo

>------------------------------------------------------------------------
>

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 26 Oct 2005 15:14:22 +0200

See below current related addresses and usage according *my 
interpretation* of bridges standard:

>is that the criteria RBridges should use, i.e., discard any messages 

Bridge Group Address 01-80-C2-00-00-00 , used for frames transporting 
BPDUs (they are confined by bridges to same LAN segment). Bridges DO NOT 
forward these frames. Neither should RBridges !
It seems that any messages to that address should be discarded because 
even bridges do not  forward them (they process them).
However, I would recommend to ask the IEEE.

>to "all bridges".
I see this in the standard:
All LANs Bridge Management group address : 01-80-C2-00-00-10.  I think 
they should be forwarded.

>not be forwarded through routers.
I think that not forwarding multicast addresses by RBridges should be 
exceptional. The bridged domain should be kept manageable at campus 
level without fragmentation. in bridged islands.

>of what should be discarded.
It seems safe (asking the IEEE).

>look at in order to know what to discard.
If no confirmation from IEEE regarding Bridge Group Address usage, it 
might be safer if RBridges look also at the protocol ID (0).
Guillermo

>Radia
Other addresses:
GMRP group address : 01-80-C2-00-00-20 (used by GARP  PDUs) .
GVRP group address: 01-80-C2-00-00-21 (used by GARP PDUs).
I did not follow the multicast discusion entirely so I am not aware of 
the position regarding this. Bridges that do not support GMRP or GVRP 
forward these frames. Bridges that support terminate and process them.
______________________________________________