Subject: [rbridge] How should RBridges recognize spanning tree messages?

From: Vishwas at sinett.com (Vishwas Manral)
Date: Wed, 26 Oct 2005 07:06:47 -0700

Hi Guillermo,

One address you may have missed out is the Pause Frame address 01-80-C2-00-00-01. 

Besides I am not sure but addresses 01-80-C2-00-00-00 to 01-80-C2-00-00-0F I think are not forwarded by switches (layer-2 devices).

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Guillermo Ib??ez
Sent: Wednesday, October 26, 2005 6:44 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] How should RBridges recognize spanning tree messages?

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

Radia Perlman wrote:

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

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.

>It's conceivable that there is some management thing that might be sent 
>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.

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

>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.
>
>  
>
It seems safe (asking the IEEE).

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

---

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

>One address you may have missed out is the Pause Frame address 01-80-C2-00-00-01. 
Right. I did not try to be exhaustive. Pause are for full duplex 
control, link local.

>Besides I am not sure but addresses 01-80-C2-00-00-00 to 01-80-C2-00-00-0F I think are not forwarded by switches (layer-2 devices).
So do I.
Guillermo

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

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Fri, 28 Oct 2005 05:26:30 +0200

--On 26. oktober 2005 07:06 -0700 Vishwas Manral <Vishwas at sinett.com> wrote:

> Besides I am not sure but addresses 01-80-C2-00-00-00 to
> 01-80-C2-00-00-0F I think are not forwarded by switches (layer-2 devices).
>

one prayer from us less clued-in to the specifications:
could people try to mention "chapter and verse" of the IEEE specifications 
when they come up with these nuggets of information?

It helps those of us who are still learning figure out which documents we 
have to read for which context....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/rbridge/attachments/20051028/5d549049/attachment.bin

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 28 Oct 2005 12:40:22 +0200

Harald Tveit Alvestrand wrote:

> could people try to mention "chapter and verse" of the IEEE 
> specifications when they come up with these nuggets of information?
>
 (IEEE 802.1D-2004,  7.12.3)
Guillermo

> It helps those of us who are still learning figure out which documents 
> we have to read for which context....
>
>
>------------------------------------------------------------------------
>

Date: Fri, 28 Oct 2005 12:40:22 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Plea for references (Re:  How should...)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 955

Harald Tveit Alvestrand wrote:

>
>
> --On 26. oktober 2005 07:06 -0700 Vishwas Manral <[email-masked]> 
> wrote:
>
>>
>> Hi Guillermo,
>>
> could people try to mention "chapter and verse" of the IEEE 
> specifications when they come up with these nuggets of information?
>
 (IEEE 802.1D-2004,  7.12.3)
Guillermo

> It helps those of us who are still learning figure out which documents 
> we have to read for which context....
>
>
>------------------------------------------------------------------------
>
>[email-masked]

Date: Fri, 28 Oct 2005 05:26:30 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Plea for references (Re:  How should...)
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1158

--==========A77A90DAA87DA9E4F41A==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 26. oktober 2005 07:06 -0700 Vishwas Manral <[email-masked]> =
wrote:

> 01-80-C2-00-00-0F I think are not forwarded by switches (layer-2 =
devices).

one prayer from us less clued-in to the specifications:
could people try to mention "chapter and verse" of the IEEE specifications=20
when they come up with these nuggets of information?

It helps those of us who are still learning figure out which documents we=20
have to read for which context....

--==========A77A90DAA87DA9E4F41A==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========A77A90DAA87DA9E4F41A==========--

Date: Fri, 28 Oct 2005 11:09:29 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Subcase for RBridges?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1499

I have a question regarding next-hop destination RBridge addressing. It 
could be avoided whitin campus cores.
One objection that can be made to RBridges and other proposals that keep 
compatibility with bridged islands  is that  the double-encapsulated 
frame is addressed to next-hop RBridge instead of to destination 
RBridge. This is necessary as, if not, the frame could be duplicated by 
intermediate RBridges that receive  copies of  the frame.
As in some cases it is foreseable that RBridges will form the core of 
the campus network due to their advantages regarding segmentation, links 
usage, etc, I wonder whether it is worth to consider the subcase of 
confined RBridges whithin a core area formed by RBridges linked by point 
to point links. Point to point links are an standard requirement for 
RSTP protocol (required for fast convergence) and common practice in 
campus networks by performance and security reasons.
Ports of RBridges linked to RBridges ( core ports) execute RBridges 
protocol with double encapsulation and ports connected to standard 
bridges islands (sbridge ports) act as the "B1" standard bridge as 
proposed by Radia for RBridge/Bridge optional implementation.
Assuming an scenario like this, RBridges might address directly the 
encapsulated frame to destination RBridge and only the TTL field would 
need to be changed at each RBridge.
It is not the general and standard scenario, but it could be in practice 
quite common, given their advantages.
Guillermo

Date: Wed, 26 Oct 2005 16:18:10 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How should RBridges recognize spanning tree messages?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3757

So do I.
Guillermo

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Guillermo Ib??ez
>[email-masked]

Date: Wed, 26 Oct 2005 16:09:00 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10858

OK
GI

Gray, Eric wrote:

>Guillermo,
>
>	Thanks!  By the way, it is not absolutely necessary 
>to give explicit directions on how to insert or modify the
>text you propose.  Trust me, I probably can get the intent
>right, once I've seen proposed text and minor corrections
>on the mailing list...  :-)
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: [email-masked] 
>--> [mailto:[email-masked]]On
>--> Behalf Of Guillermo Ib??ez
>--> Sent: Wednesday, October 26, 2005 2:43 AM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] RBridge/bridge interaction
>--> 
>--> 
>--> 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
>--> > be combined bridge/RBridges.
>--> >
>--> >
>--> OK. Add this sentence explicitly: "It is not mandatory for 
>--> RBridges be 
>--> combined bridge/RBridges".
>--> Guillermo
>--> 
>--> >
>--> > Guillermo Ib??ez wrote:
>--> >
>--> >>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 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. 
>--> >>
>--> >>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. 
>--> >>
>--> >>
>--> >>
>--> >> 
>--> >>
>--> >>
>--> >>Gray, Eric wrote:
>--> >>
>--> >>  
>--> >>
>--> >>>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: [email-masked] 
>--> >>>--> [mailto:[email-masked]]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: [email-masked] 
>--> >>>--> >>[mailto:[email-masked]] 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: [email-masked]
>--> >>>--> >>--> [mailto:[email-masked]]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
>--> >>>--> >>--> >[email-masked] 
>--> >>>--> http://www.postel.org/mailman/listinfo/rbridge
>--> >>>--> >>--> >
>--> >>>--> >>--> >  
>--> >>>--> >>--> >
>--> >>>--> >>--> _______________________________________________
>--> >>>--> >>--> rbridge mailing list
>--> >>>--> >>--> [email-masked] 
>--> >>>--> http://www.postel.org/mailman/listinfo/rbridge
>--> >>>--> >>--> 
>--> >>>--> >>_______________________________________________
>--> >>>--> >>rbridge mailing list
>--> >>>--> >>[email-masked] 
>>>>--> >>
>>>>--> >>
>>>>--> >>    
>>>>--> >>
>>>>--> >_______________________________________________
>>>>--> >rbridge mailing list
>>>>--> >[email-masked]
>>>>--> >http://www.postel.org/mailman/listinfo/rbridge
>>>>--> >  
>>>>--> >
>>>>--> 
>>>>--> _______________________________________________
>>>>--> rbridge mailing list
>>>>--> [email-masked]
>>>>--> http://www.postel.org/mailman/listinfo/rbridge
>>>>--> 
>>>>[email-masked]
>>>[email-masked]
>>------------------------------------------------------------------------
>>
>>[email-masked]
>[email-masked]
>[email-masked]

Content-class: urn:content-classes:message
Date: Wed, 26 Oct 2005 07:06:47 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How should RBridges recognize spanning tree messages?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3279

Hi Guillermo,

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Guillermo Ib??ez
Sent: Wednesday, October 26, 2005 6:44 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] How should RBridges recognize spanning tree messages?

Other addresses:

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Wed, 26 Oct 2005 10:44:51 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10338

Guillermo,

	Thanks!  By the way, it is not absolutely necessary 
to give explicit directions on how to insert or modify the
text you propose.  Trust me, I probably can get the intent
right, once I've seen proposed text and minor corrections
on the mailing list...  :-)

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Wednesday, October 26, 2005 2:43 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> 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
--> > be combined bridge/RBridges.
--> >
--> >
--> OK. Add this sentence explicitly: "It is not mandatory for 
--> RBridges be 
--> combined bridge/RBridges".
--> Guillermo
--> 
--> >
--> > Guillermo Ib??ez wrote:
--> >
--> >>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 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. 
--> >>
--> >>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. 
--> >>
--> >>
--> >>
--> >> 
--> >>
--> >>
--> >>Gray, Eric wrote:
--> >>
--> >>  
--> >>
--> >>>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: [email-masked] 
--> >>>--> [mailto:[email-masked]]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: [email-masked] 
--> >>>--> >>[mailto:[email-masked]] 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: [email-masked]
--> >>>--> >>--> [mailto:[email-masked]]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
--> >>>--> >>--> >[email-masked] 
--> >>>--> http://www.postel.org/mailman/listinfo/rbridge
--> >>>--> >>--> >
--> >>>--> >>--> >  
--> >>>--> >>--> >
--> >>>--> >>--> _______________________________________________
--> >>>--> >>--> rbridge mailing list
--> >>>--> >>--> [email-masked] 
--> >>>--> http://www.postel.org/mailman/listinfo/rbridge
--> >>>--> >>--> 
--> >>>--> >>_______________________________________________
--> >>>--> >>rbridge mailing list
--> >>>--> >>[email-masked] 
http://www.postel.org/mailman/listinfo/rbridge
>>>--> >>
>>>--> >>
>>>--> >>    
>>>--> >>
>>>--> >_______________________________________________
>>>--> >rbridge mailing list
>>>--> >[email-masked]
>>>--> >http://www.postel.org/mailman/listinfo/rbridge
>>>--> >  
>>>--> >
>>>--> 
>>>--> _______________________________________________
>>>--> rbridge mailing list
>>>--> [email-masked]
>>>--> http://www.postel.org/mailman/listinfo/rbridge
>>>--> 
>>>[email-masked]
>>[email-masked]
>------------------------------------------------------------------------
>
>[email-masked]
[email-masked]

Date: Wed, 26 Oct 2005 15:14:22 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] How should RBridges recognize spanning tree messages?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2888

Other addresses:
______________________________________________

>[email-masked]

Date: Wed, 26 Oct 2005 08:42:42 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8630

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
> be combined bridge/RBridges.
>
>
OK. Add this sentence explicitly: "It is not mandatory for RBridges be 
combined bridge/RBridges".
Guillermo

>
> Guillermo Ib??ez wrote:
>
>>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 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. 
>>
>>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. 
>>
>>
>>
>> 
>>
>>
>>Gray, Eric wrote:
>>
>>  
>>
>>>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: [email-masked] 
>>>--> [mailto:[email-masked]]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: [email-masked] 
>>>--> >>[mailto:[email-masked]] 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: [email-masked]
>>>--> >>--> [mailto:[email-masked]]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
>>>--> >>--> >[email-masked] 
>>>--> http://www.postel.org/mailman/listinfo/rbridge
>>>--> >>--> >
>>>--> >>--> >  
>>>--> >>--> >
>>>--> >>--> _______________________________________________
>>>--> >>--> rbridge mailing list
>>>--> >>--> [email-masked] 
>>>--> http://www.postel.org/mailman/listinfo/rbridge
>>>--> >>--> 
>>>--> >>_______________________________________________
>>>--> >>rbridge mailing list
>>>--> >>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>>--> >>
>>>--> >>
>>>--> >>    
>>>--> >>
>>>--> >_______________________________________________
>>>--> >rbridge mailing list
>>>--> >[email-masked]
>>>--> >http://www.postel.org/mailman/listinfo/rbridge
>>>--> >  
>>>--> >
>>>--> 
>>>--> _______________________________________________
>>>--> rbridge mailing list
>>>--> [email-masked]
>>>--> http://www.postel.org/mailman/listinfo/rbridge
>>>--> 
>>>[email-masked]
>>[email-masked]
>------------------------------------------------------------------------
>
>[email-masked]

Date: Tue, 25 Oct 2005 12:15:59 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] How should RBridges recognize spanning tree messages?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1343

to "all bridges". In

Radia

Date: Tue, 25 Oct 2005 12:13:40 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 19763

This is a multi-part message in MIME format.

--Boundary_(ID_1cW9761bbl6Yh/fho+frXA)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT

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.

Guillermo Ib??ez wrote:

>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 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. 
>
>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. 
>
>
>
> 
>
>
>Gray, Eric wrote:
>
>  
>
>>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: [email-masked] 
>>--> [mailto:[email-masked]]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: [email-masked] 
>>--> >>[mailto:[email-masked]] 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: [email-masked]
>>--> >>--> [mailto:[email-masked]]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
>>--> >>--> >[email-masked] 
>>--> http://www.postel.org/mailman/listinfo/rbridge
>>--> >>--> >
>>--> >>--> >  
>>--> >>--> >
>>--> >>--> _______________________________________________
>>--> >>--> rbridge mailing list
>>--> >>--> [email-masked] 
>>--> http://www.postel.org/mailman/listinfo/rbridge
>>--> >>--> 
>>--> >>_______________________________________________
>>--> >>rbridge mailing list
>>--> >>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>--> >>
>>--> >>
>>--> >>    
>>--> >>
>>--> >_______________________________________________
>>--> >rbridge mailing list
>>--> >[email-masked]
>>--> >http://www.postel.org/mailman/listinfo/rbridge
>>--> >  
>>--> >
>>--> 
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [email-masked]
>>--> http://www.postel.org/mailman/listinfo/rbridge
>>--> 
>>[email-masked]
>[email-masked]

--Boundary_(ID_1cW9761bbl6Yh/fho+frXA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
No objection to inclusion of the text proposed by Guillermo, as long as
it's clear it's not mandatory for all RBridges to<br>
be combined bridge/RBridges.<br>
<br>
<br>
<br>
Guillermo Ib&aacute;&ntilde;ez wrote:<br>
<blockquote type="cite" cite="[email-masked]">
  <pre wrap="">Eric,  Radia :

I have use Radia&acute;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 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:

                        &iexcl;-----------&iexcl;
       bridged island-----B1----RB1 &iexcl;
                        &iexcl;-----------&iexcl;

                        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. 

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. 

Gray, Eric wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">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

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

    </pre>
  </blockquote>
  <pre wrap=""><!---->_______________________________________________
rbridge mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://www.postel.org/mailman/listinfo/rbridge">http://www.postel.org/mailman/listinfo/rbridge</a>
  </pre>
</blockquote>
</body>
</html>

--Boundary_(ID_1cW9761bbl6Yh/fho+frXA)--

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 25 Oct 2005 11:44:13 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9044

Guillermo,

	Thank-you for the suggested text!

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Tuesday, October 25, 2005 5:56 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> 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:
--> 
--> >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: [email-masked] 
--> >--> [mailto:[email-masked]]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: [email-masked] 
--> >--> >>[mailto:[email-masked]] 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: [email-masked]
--> >--> >>--> [mailto:[email-masked]]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
--> >--> >>--> >[email-masked] 
--> >--> http://www.postel.org/mailman/listinfo/rbridge
--> >--> >>--> >
--> >--> >>--> >  
--> >--> >>--> >
--> >--> >>--> _______________________________________________
--> >--> >>--> rbridge mailing list
--> >--> >>--> [email-masked] 
--> >--> http://www.postel.org/mailman/listinfo/rbridge
--> >--> >>--> 
--> >--> >>_______________________________________________
--> >--> >>rbridge mailing list
--> >--> >>[email-masked] 
--> http://www.postel.org/mailman/listinfo/rbridge
--> >--> >>
--> >--> >>
--> >--> >>    
--> >--> >>
--> >--> >_______________________________________________
--> >--> >rbridge mailing list
--> >--> >[email-masked]
--> >--> >http://www.postel.org/mailman/listinfo/rbridge
--> >--> >  
--> >--> >
--> >--> 
--> >--> _______________________________________________
--> >--> rbridge mailing list
--> >--> [email-masked]
--> >--> http://www.postel.org/mailman/listinfo/rbridge
--> >--> 
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >
--> >  
--> >
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 25 Oct 2005 11:02:58 -0300
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl	 e
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 6184

Guillermo,

	I am not sure where you get the statement "the goal now is
to get rid of IP address dependencies."  You assert this, but that
does not make it true.  As far as I know, the goal has been - and
yet remains - to make the solution as near "zero configuration" as
possible, including actual "zero configuration" in at least some
(possibly simplistic) deployment scenarios.

	If we look back over previous discussion(s), it seems clear
that one of the reasons for undertaking this effort is to merge
the at least near-zero configuration of bridges with efficient
link utilization typical of shortest path routing.

	Do people think that has changed?

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Tuesday, October 25, 2005 7:29 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now
--> availabl e
--> 
--> 
--> Eric,
--> 
--> Gray, Eric wrote:
--> 
--> >Guillermo,
--> >
--> >	We should talk - possibly off-line - about word-smithing
--> >the text around STP/RSTP.  I would prefer not to try to guess
--> >what people would like me to say about this (or other) issue(s).
--> >For one thing, it would be nice if you could provide detailed
--> >references (organization, authors - if listed - dates, etc.).
--> >  
--> >
--> >	Bearing in mind that this document is aimed at nailing
--> >down what the requirements are for routing protocol - extensions,
--> >compatibility, etc. - we should not spend to much time and energy
--> >on making sure that what this draft says on non-routing related
--> >reuirements.  
--> >
--> Agree
--> 
--> >Instead, I think we should make sure that the set
--> >of drafts/RFCs that the WG develops are consistent.  Admittedly,
--> >since the over-all requirements, framework and architecture IDs
--> >are not out yet, this is the current draft to address such issues
--> >with.  However, the wording in this draft reflects the original
--> >words in the draft cited in the WG charter.
--> >
--> >	As for "zero configuration", this is a goal.  If we cannot
--> >achieve it, that is one thing - but I do not think we want to 
--> >start by weasle-wording our goals. 
--> >
--> I was just trying to be precise, the goal  now is  get rid of IP 
--> addresses dependencies.
--> 
--> > I don't think anyone believes
--> >we're going to get by with zero-configuration in every case, but
--> >then we're not saying that this goal MUST be achieved in every 
--> >case.  So, I think we should not complicate our goals by overly
--> >qualifying them too much.  Down that way is a slippery slope...
--> >
--> >  
--> >
--> Well, I think that when zero configuration was stated, only 
--> referred to 
--> IP addresses and subnetting independency.
--> When VLAN configuration issue has been identified, it has 
--> been excluded 
--> from the WG (assume some external method or tool is used). As VLAN 
--> configuration is among the most significant efforts, it is 
--> misleading to 
--> continue using the general term
--> zero-configuration without precision of what is meant.
--> 
--> >--
--> >Eric
--> >
--> >--> -----Original Message-----
--> >--> From: [email-masked] 
--> >--> [mailto:[email-masked]]On
--> >--> Behalf Of Guillermo Ib??ez
--> >--> Sent: Monday, October 24, 2005 6:48 AM
--> >--> To: Developing a hybrid router/bridge.
--> >--> Subject: Re: [rbridge] R-Bridge Routing Requirements 
--> draft is now
--> >--> available
--> >--> 
--> >--> 
--> >--> Eric,
--> >--> Some comments on draft,
--> >--> - When mentioning Spanning Tree Protocol (STP), is 
--> convenient to 
--> >--> distinguish and/or mention both spanning tree protocols : 
--> >--> legacy STP and 
--> >--> Rapid Spanning Tree Protocol RSTP (802.1D). In general, I  
--> >--> recommend to 
--> >--> use the term RSTP for clarity whenever possible and add a 
--> >--> sentence like: 
--> >--> "...The current IEEE standard specifies RSTP, although both 
--> >--> STP and RSTP 
--> >--> bridges will exist and must be supported....
--> >--> - In the abstract,  "zero configuration" is mentioned. If 
--> >--> VLANs must be 
--> >--> configured, I do not think real zero configuration can be 
--> >--> claimed. May 
--> >--> be it should say "zero IP addresses/subnets configuration" 
--> >--> or something 
--> >--> like that.
--> >--> - Some name or acronym for the spanning trees between 
--> >--> Rbridges would 
--> >--> help to reduce the confusion created by two types of 
--> spanning trees 
--> >--> coexisting :  STP(RSTP) and between Rbridges.  A 
--> >--> possibility is to call 
--> >--> them  *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees).
--> >--> 
--> >--> Guillermo
--> >--> 
--> >--> 
--> >--> 
--> >--> Gray, Eric wrote:
--> >--> 
--> >--> >The draft "Routing Requirements in Support of R-Bridges" - 
--> >--> submitted last 
--> >--> >Friday - is now available at:
--> >--> >
--> >--> >http://www.ietf.org/internet-drafts/draft-gray-rbridge-rout
--> >ing-reqs-00.txt
--> >  
--> >
--> >>This draft borrows heavily from the earlier 
--> draft-perlman-rbridge-03.txt
--> >>and is very preliminary.  I am looking for input for the 
--> various sections
--> >>- particularly those that currently only contain "TBD" :-)
--> >>
--> >>This was one of the drafts that the working group felt 
--> would be required
--> >>at the last meeting.
--> >>
--> >>--
--> >>Eric Gray
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[email-masked]
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> >>
--> >> 
--> >>
--> >>    
--> >>
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >
--> >  
--> >
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 25 Oct 2005 10:28:13 -0300
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl	 e
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2720

Harald,

	The difference between flooding and broadcast is not
really small, nor is it necessarily a nit.

	Flooding is a bridge-local phenomena associated with
bridge learning, and not with explicitly multicast/broadcast
traffic.  People frequently equate it with broadcast because 
that is the worst-case for consideration in most bridging 
concerns.

	Flooding stops at each point along the spanning tree
where the destination address has already been learned, or
has not yet been aged out.

	That behavior is substantially different from either
multicast or broadcast distribution.

	Also, we need to be careful when classifying one thing
as a "special case" of another.  Some people once classified
VPN services as a "special case" of traffic engineering.  It
is altogether too easy to fall into a mental snare that way.

	For example, in this case (considering broadcast, multi-
cast and flooding), broadcast is the simplest thing to do and
multicast and flooding are both different variations of it.
In each case (multicast verses flooding), there is a method
(or circumstance) under which propagation terminates early in
comparison with broadcast.  To do broadcast, you need neither
of these two complications; to do either multicast or flooding, 
you need not include the capability to do the other.

	Consequently, we would be better off thinking of flooding
and multicast as distinct "special cases" of broadcast.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Harald Tveit Alvestrand
--> Sent: Monday, October 24, 2005 10:54 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now
--> availabl e
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier, you wrote:

--On 24. oktober 2005 13:28 -0300 "Gray, Eric" <[email-masked]> 
wrote:

> Harald,
>
> 	I am not sure that multicast distribution trees is going
> to be sufficiently unambiguous.  There will be both multicast
> and flooding to take into account and these are not the same.

I was thinking of broadcast ("flooding") as a special kind of 
multicast..... I don't know how, inside the rbridge cloud, distributing to 
the "all RBridges" multicast is different from distributing a broadcast. 
But that's a nit, and may be obvious once the drafts are out.

for the unicast stuff, I think it makes sense to abandon the "tree" term, 
just because using the term makes people think of the particular way in 
which the RSTP algorithm configures forwarding tables in bridges.....

Date: Tue, 25 Oct 2005 13:28:50 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl e
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4460

Eric,

Gray, Eric wrote:

>Guillermo,
>
>	We should talk - possibly off-line - about word-smithing
>the text around STP/RSTP.  I would prefer not to try to guess
>what people would like me to say about this (or other) issue(s).
>For one thing, it would be nice if you could provide detailed
>references (organization, authors - if listed - dates, etc.).
>  
>
>	Bearing in mind that this document is aimed at nailing
>down what the requirements are for routing protocol - extensions,
>compatibility, etc. - we should not spend to much time and energy
>on making sure that what this draft says on non-routing related
>reuirements.  
>
Agree

>Instead, I think we should make sure that the set
>of drafts/RFCs that the WG develops are consistent.  Admittedly,
>since the over-all requirements, framework and architecture IDs
>are not out yet, this is the current draft to address such issues
>with.  However, the wording in this draft reflects the original
>words in the draft cited in the WG charter.
>
>	As for "zero configuration", this is a goal.  If we cannot
>achieve it, that is one thing - but I do not think we want to 
>start by weasle-wording our goals. 
>
I was just trying to be precise, the goal  now is  get rid of IP 
addresses dependencies.

> I don't think anyone believes
>we're going to get by with zero-configuration in every case, but
>then we're not saying that this goal MUST be achieved in every 
>case.  So, I think we should not complicate our goals by overly
>qualifying them too much.  Down that way is a slippery slope...
>
>  
>
Well, I think that when zero configuration was stated, only referred to 
IP addresses and subnetting independency.
When VLAN configuration issue has been identified, it has been excluded 
from the WG (assume some external method or tool is used). As VLAN 
configuration is among the most significant efforts, it is misleading to 
continue using the general term
zero-configuration without precision of what is meant.

>--
>Eric
>
>--> -----Original Message-----
>--> From: [email-masked] 
>--> [mailto:[email-masked]]On
>--> Behalf Of Guillermo Ib??ez
>--> Sent: Monday, October 24, 2005 6:48 AM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now
>--> available
>--> 
>--> 
>--> Eric,
>--> Some comments on draft,
>--> - When mentioning Spanning Tree Protocol (STP), is convenient to 
>--> distinguish and/or mention both spanning tree protocols : 
>--> legacy STP and 
>--> Rapid Spanning Tree Protocol RSTP (802.1D). In general, I  
>--> recommend to 
>--> use the term RSTP for clarity whenever possible and add a 
>--> sentence like: 
>--> "...The current IEEE standard specifies RSTP, although both 
>--> STP and RSTP 
>--> bridges will exist and must be supported....
>--> - In the abstract,  "zero configuration" is mentioned. If 
>--> VLANs must be 
>--> configured, I do not think real zero configuration can be 
>--> claimed. May 
>--> be it should say "zero IP addresses/subnets configuration" 
>--> or something 
>--> like that.
>--> - Some name or acronym for the spanning trees between 
>--> Rbridges would 
>--> help to reduce the confusion created by two types of spanning trees 
>--> coexisting :  STP(RSTP) and between Rbridges.  A 
>--> possibility is to call 
>--> them  *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees).
>--> 
>--> Guillermo
>--> 
>--> 
>--> 
>--> Gray, Eric wrote:
>--> 
>--> >The draft "Routing Requirements in Support of R-Bridges" - 
>--> submitted last 
>--> >Friday - is now available at:
>--> >
>--> >http://www.ietf.org/internet-drafts/draft-gray-rbridge-rout
>ing-reqs-00.txt
>  
>
>>This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt
>>and is very preliminary.  I am looking for input for the various sections
>>- particularly those that currently only contain "TBD" :-)
>>
>>This was one of the drafts that the working group felt would be required
>>at the last meeting.
>>
>>--
>>Eric Gray
>>[email-masked]
>[email-masked]
>[email-masked]

Date: Tue, 25 Oct 2005 11:59:21 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7505

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

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. 

Gray, Eric wrote:

>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: [email-masked] 
>--> [mailto:[email-masked]]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: [email-masked] 
>--> >>[mailto:[email-masked]] 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: [email-masked]
>--> >>--> [mailto:[email-masked]]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
>--> >>--> >[email-masked] 
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> >>--> >
>--> >>--> >  
>--> >>--> >
>--> >>--> _______________________________________________
>--> >>--> rbridge mailing list
>--> >>--> [email-masked] 
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> >>--> 
>--> >>_______________________________________________
>--> >>rbridge mailing list
>--> >>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>--> >>
>--> >>
>--> >>    
>--> >>
>--> >_______________________________________________
>--> >rbridge mailing list
>--> >[email-masked]
>--> >http://www.postel.org/mailman/listinfo/rbridge
>--> >  
>--> >
>--> 
>--> _______________________________________________
>--> rbridge mailing list
>--> [email-masked]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>[email-masked]

Date: Tue, 25 Oct 2005 11:55:38 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7551

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:

>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: [email-masked] 
>--> [mailto:[email-masked]]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: [email-masked] 
>--> >>[mailto:[email-masked]] 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: [email-masked]
>--> >>--> [mailto:[email-masked]]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
>--> >>--> >[email-masked] 
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> >>--> >
>--> >>--> >  
>--> >>--> >
>--> >>--> _______________________________________________
>--> >>--> rbridge mailing list
>--> >>--> [email-masked] 
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> >>--> 
>--> >>_______________________________________________
>--> >>rbridge mailing list
>--> >>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>--> >>
>--> >>
>--> >>    
>--> >>
>--> >_______________________________________________
>--> >rbridge mailing list
>--> >[email-masked]
>--> >http://www.postel.org/mailman/listinfo/rbridge
>--> >  
>--> >
>--> 
>--> _______________________________________________
>--> rbridge mailing list
>--> [email-masked]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>[email-masked]

Date: Mon, 24 Oct 2005 19:53:40 -0700
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl e
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1316

--==========60CF60F89C2539DAE611==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 24. oktober 2005 13:28 -0300 "Gray, Eric" <[email-masked]>=20
wrote:

> Harald,
>
> 	I am not sure that multicast distribution trees is going
> to be sufficiently unambiguous.  There will be both multicast
> and flooding to take into account and these are not the same.

I was thinking of broadcast ("flooding") as a special kind of=20
multicast..... I don't know how, inside the rbridge cloud, distributing to=20
the "all RBridges" multicast is different from distributing a broadcast.=20
But that's a nit, and may be obvious once the drafts are out.

for the unicast stuff, I think it makes sense to abandon the "tree" term,=20
just because using the term makes people think of the particular way in=20
which the RSTP algorithm configures forwarding tables in bridges.....

--==========60CF60F89C2539DAE611==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========60CF60F89C2539DAE611==========--

From: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 24 Oct 2005 21:24:22 +0200
Importance: Normal
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2958

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre
de Erik Nordmark
Enviado el: lunes, 24 de octubre de 2005 17:07
Para: Developing a hybrid router/bridge.
CC: [email-masked]
Asunto: Re: [rbridge] RBridge/bridge interaction

Guillermo Ib??ez wrote:
> I see the standard root election mechanism of spanning tree islands as
> the fastest and simpler mechanism for DR Rbridge designation. I see the 
> DR Rbridge as being necessarily the ROOT bridge of  that sbridged cloud 
> (or "link"). The root bridge of a standard spanning tree is the 
> "natural" source and sink point for the spanning tree.  To do so, the DR 
> must issue BPDUs to become the root bridge.  This is part of what I 
> mentioned days ago as PARTICIPATE PER PORT, but may be we should call it 
> SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs 
> to contend to be the root bridge of the link).
> The consequence of this DR election mechanism is that the priority 
> configured at Rbridges as bridge ID would determine their also their 
> election priority as DRs. I think this keep both domains coordinated 
> with a single mechanism.

But I don't think it is possible in 802.1D to guarantee that the 
RBridges become the 802.1D root bridges as seen from the bridges. It could
be that there is one or more bridges that are    configured so that they are
the most likely to be selected as 802.1D root bridges.
GI> If priority is configured with very low value, this is unlikely to
happen. It is the network administrator who decides when setting the bridges
priorities. If nothing is configured, the default priority value is in the
middle of the range, so if the default priority value for Rbridges is lower,
one Rbridge will be always root if nothing specially configured.

GI> May be the term "necessarily" is excesive. The reason to contend as root
bridges is two fold: optimize paths and ensure  uniqueness and fast election
of DR Rbridge via root bridge election, linking both processes. This also
may improve 
network predictability and understability, although I do not know details on
the pros and cons of standar IS-IS DR election. My understanding is that it
is slower and requires the spanning tree established. Root bridge election
DOES NOT
Require the spanning tree established and forwarding frames. This might be
the MAIN argument in favour of using root bridge election for DR Rbridge
designation.   

Presumably we'd want RBridges to function even when applied to such a 
network (even though the paths might not be "optimal").

GI> I agree, it can not be mandatory.

    Erik
GI> With Radia's proposal of an optional combined implementation Rbridge+
bridge, it can be set up this way. The bridge participates and contends to
be root.

GI>  Guillermo
_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 24 Oct 2005 13:28:26 -0300
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl	e
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2604

Harald,

	I am not sure that multicast distribution trees is going
to be sufficiently unambiguous.  There will be both multicast
and flooding to take into account and these are not the same.

	Also, I agree with the statement that RBridges will be
creating a DAG, not a spanning tree.  To people familar with
STP, however, it is hard to get their head wrapped around the
differences.  And - once they start to - these differences
seem like anathema to the L2-thinker because they "may" not be
compatible with STP.  This has been - I am sure - a big part 
of the confusion in terminology in previous discussion.  In 
that same dicussion, I had tried to get people using SPST -
Shortest Path Spanning Tree - as a way to help people realize 
that it is not quite the same thing.

	For an example of where this gets very complicated, look
at the discussion of "how many trees?"  If we're talking about
real "spanning trees", then the answer has to be exactly one.
Otherwise, we will get mired in discussions of virtual IS-IS
routers because there will have to be a different link-state
applied to links between RBridges - depending on which spanning 
tree is used to create any given link within, for instance, a
VLAN context.  On the other hand, if we're talking about the
effective spanning trees that result from creating a DAG via 
IS-IS shortest path computations, then there may be any number
of such spanning trees.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Harald Tveit Alvestrand
--> Sent: Monday, October 24, 2005 8:00 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now
--> available
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier, you wrote:

--On 24. oktober 2005 12:48 +0200 Guillermo Ibáñez <[email-masked]> 
wrote:

> - Some name or acronym for the spanning trees between Rbridges would
> help to reduce the confusion created by two types of spanning trees
> coexisting :  STP(RSTP) and between Rbridges.  A possibility is to call
> them  *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees)

why not name them for their function, and call them multicast distribution 
trees?

It's after all an essential point of the design that the unicast packets do 
NOT have to follow the spanning trees; the unicast routing tables will form 
a directed acyclic graph (DAG), not a tree.

                  Harald

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 24 Oct 2005 13:11:48 -0300
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl	e
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3642

Guillermo,

	We should talk - possibly off-line - about word-smithing
the text around STP/RSTP.  I would prefer not to try to guess
what people would like me to say about this (or other) issue(s).
For one thing, it would be nice if you could provide detailed
references (organization, authors - if listed - dates, etc.).

	Bearing in mind that this document is aimed at nailing
down what the requirements are for routing protocol - extensions,
compatibility, etc. - we should not spend to much time and energy
on making sure that what this draft says on non-routing related
reuirements.  Instead, I think we should make sure that the set
of drafts/RFCs that the WG develops are consistent.  Admittedly,
since the over-all requirements, framework and architecture IDs
are not out yet, this is the current draft to address such issues
with.  However, the wording in this draft reflects the original
words in the draft cited in the WG charter.

	As for "zero configuration", this is a goal.  If we cannot
achieve it, that is one thing - but I do not think we want to 
start by weasle-wording our goals.  I don't think anyone believes
we're going to get by with zero-configuration in every case, but
then we're not saying that this goal MUST be achieved in every 
case.  So, I think we should not complicate our goals by overly
qualifying them too much.  Down that way is a slippery slope...

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Monday, October 24, 2005 6:48 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now
--> available
--> 
--> 
--> Eric,
--> Some comments on draft,
--> - When mentioning Spanning Tree Protocol (STP), is convenient to 
--> distinguish and/or mention both spanning tree protocols : 
--> legacy STP and 
--> Rapid Spanning Tree Protocol RSTP (802.1D). In general, I  
--> recommend to 
--> use the term RSTP for clarity whenever possible and add a 
--> sentence like: 
--> "...The current IEEE standard specifies RSTP, although both 
--> STP and RSTP 
--> bridges will exist and must be supported....
--> - In the abstract,  "zero configuration" is mentioned. If 
--> VLANs must be 
--> configured, I do not think real zero configuration can be 
--> claimed. May 
--> be it should say "zero IP addresses/subnets configuration" 
--> or something 
--> like that.
--> - Some name or acronym for the spanning trees between 
--> Rbridges would 
--> help to reduce the confusion created by two types of spanning trees 
--> coexisting :  STP(RSTP) and between Rbridges.  A 
--> possibility is to call 
--> them  *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees).
--> 
--> Guillermo
--> 
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >The draft "Routing Requirements in Support of R-Bridges" - 
--> submitted last 
--> >Friday - is now available at:
--> >
--> >http://www.ietf.org/internet-drafts/draft-gray-rbridge-rout
ing-reqs-00.txt
>
>This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt
>and is very preliminary.  I am looking for input for the various sections
>- particularly those that currently only contain "TBD" :-)
>
>This was one of the drafts that the working group felt would be required
>at the last meeting.
>
>--
>Eric Gray
>[email-masked]
[email-masked]

Date: Mon, 24 Oct 2005 08:06:30 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1314

Guillermo Ib??ez wrote:
> I see the standard root election mechanism of spanning tree islands as 
> the fastest and simpler mechanism for DR Rbridge designation. I see the 
> DR Rbridge as being necessarily the ROOT bridge of  that sbridged cloud 
> (or "link"). The root bridge of a standard spanning tree is the 
> "natural" source and sink point for the spanning tree.  To do so, the DR 
> must issue BPDUs to become the root bridge.  This is part of what I 
> mentioned days ago as PARTICIPATE PER PORT, but may be we should call it 
> SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs 
> to contend to be the root bridge of the link).
> The consequence of this DR election mechanism is that the priority 
> configured at Rbridges as bridge ID would determine their also their 
> election priority as DRs. I think this keep both domains coordinated 
> with a single mechanism.

But I don't think it is possible in 802.1D to guarantee that the 
RBridges become the 802.1D root bridges as seen from the bridges.
It could be that there is one or more bridges that are configured so 
that they are the most likely to be selected as 802.1D root bridges.

Presumably we'd want RBridges to function even when applied to such a 
network (even though the paths might not be "optimal").

    Erik

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 24 Oct 2005 12:44:27 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5081

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: [email-masked] 
--> [mailto:[email-masked]]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: [email-masked] 
--> >>[mailto:[email-masked]] 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: [email-masked]
--> >>--> [mailto:[email-masked]]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
--> >>--> >[email-masked] 
--> http://www.postel.org/mailman/listinfo/rbridge
--> >>--> >
--> >>--> >  
--> >>--> >
--> >>--> _______________________________________________
--> >>--> rbridge mailing list
--> >>--> [email-masked] 
--> http://www.postel.org/mailman/listinfo/rbridge
--> >>--> 
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
--> >>
--> >>
--> >>    
--> >>
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Mon, 24 Oct 2005 05:00:23 -0700
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now available
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1211

--==========6C037B9DCB4F4087D16B==========
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 24. oktober 2005 12:48 +0200 Guillermo Ib=C3=A1=C3=B1ez =
<[email-masked]>=20
wrote:

> - Some name or acronym for the spanning trees between Rbridges would
> help to reduce the confusion created by two types of spanning trees
> coexisting :  STP(RSTP) and between Rbridges.  A possibility is to call
> them  *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees)

why not name them for their function, and call them multicast distribution=20
trees?

It's after all an essential point of the design that the unicast packets do =

NOT have to follow the spanning trees; the unicast routing tables will form =

a directed acyclic graph (DAG), not a tree.

                  Harald

--==========6C037B9DCB4F4087D16B==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========6C037B9DCB4F4087D16B==========--

Date: Mon, 24 Oct 2005 12:48:15 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now available
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1628

Eric,
Some comments on draft,
- When mentioning Spanning Tree Protocol (STP), is convenient to 
distinguish and/or mention both spanning tree protocols : legacy STP and 
Rapid Spanning Tree Protocol RSTP (802.1D). In general, I  recommend to 
use the term RSTP for clarity whenever possible and add a sentence like: 
"...The current IEEE standard specifies RSTP, although both STP and RSTP 
bridges will exist and must be supported....
- In the abstract,  "zero configuration" is mentioned. If VLANs must be 
configured, I do not think real zero configuration can be claimed. May 
be it should say "zero IP addresses/subnets configuration" or something 
like that.
- Some name or acronym for the spanning trees between Rbridges would 
help to reduce the confusion created by two types of spanning trees 
coexisting :  STP(RSTP) and between Rbridges.  A possibility is to call 
them  *RBSTs* or RBTs ..(Routing Bridges [Spanning] Trees).

Guillermo

Gray, Eric wrote:

>The draft "Routing Requirements in Support of R-Bridges" - submitted last 
>Friday - is now available at:
>
>http://www.ietf.org/internet-drafts/draft-gray-rbridge-routing-reqs-00.txt
>
>This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt
>and is very preliminary.  I am looking for input for the various sections
>- particularly those that currently only contain "TBD" :-)
>
>This was one of the drafts that the working group felt would be required
>at the last meeting.
>
>--
>Eric Gray
>[email-masked]

Date: Sat, 22 Oct 2005 13:59:29 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3847

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.
>>From: [email-masked] 
>>[mailto:[email-masked]] 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: [email-masked]
>>--> [mailto:[email-masked]]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
>>--> >[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>--> >
>>--> >  
>>--> >
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>--> 
>>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>
>>
>>    
>>
>[email-masked]

Content-class: urn:content-classes:message
Date: Sat, 22 Oct 2005 16:23:26 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2981

Likewise.

> From: [email-masked] 
> [mailto:[email-masked]] 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: [email-masked]
> --> [mailto:[email-masked]]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
> --> >[email-masked] http://www.postel.org/mailman/listinfo/rbridge
> --> >
> --> >  
> --> >
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
> --> 
> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
> 
> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 21 Oct 2005 19:16:02 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2408

I also agree that this is a quite feasible approach.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]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
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >
--> >  
--> >
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Sat, 22 Oct 2005 00:01:01 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1598

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. 
>>
>>    
>>
>
>
>[email-masked]

Date: Fri, 21 Oct 2005 23:58:21 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2019

Root election would be, as now, planned according to expected traffic 
patterns. If routers have dominant traffic, they could be configured to 
act as roots.
Besides performance, nobody mentions arguments regarding independent 
IS-IS DR election vs DR election linked to root bridge election, which I 
think is a  more important advantage than performance and shortest path 
in the spanning tree. My impression is that convergence is slower for 
IS-IS for DR reconfiguration  than for an RSTP driven DR election. 
But perhaps we have discussed enough this subject. Time will tell if 
something like this is desirable.
Guillermo

Radia Perlman wrote:

>Guillermo Ib??ez wrote:
>
>  
>
>>With the client server model, dominant traffic is to and from the core 
>>layer of campus network, so I think most of the traffic will flow 
>>from/into Rbridge, not withing the islands.
>>
>> 
>>
>>    
>>
>If we buy that argument, then the same argument would say that routers 
>should participate in
>the spanning tree and attempt to become Root. And what if there are 
>multiple routers?
>If it's so vital for performance that one router is Root, then they'd 
>all need to be Root within a bridged
>network.
>
>We shouldn't be trying to optimize that particular tree calculated by 
>the bridged islands. Hopefully
>those trees would become smaller and smaller. And even if we did care 
>about some type of optimality,
>I don't think trying to make one of the RBridges Root will make any 
>difference. (Note "one of the
>RBridges"...there can be several RBridges on the bridged island, so at 
>most one of them can
>be Root). People have lived for a long time without worrying about 
>making one of the routers on
>a bridged LAN be the Root in order to attempt more optimal delivery of 
>traffic on/off the bridged LAN.
>I don't think we should worry about it either.
>
>Radia
>
>
>
>[email-masked]

Date: Fri, 21 Oct 2005 14:48:23 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1299

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

Date: Fri, 21 Oct 2005 23:47:25 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 27213

Gray, Eric wrote:

>Guillermo,
>
>	Here's the problem: in  order for an RBridge to be the 
>spanning tree root for bridges, it has to participate in bridge
>STP.  Nothing else will work.  However, it would be better from
>a simplicity perspective if the designated RBridge forwarder for
>a link were selected on a basis of proximity to the root bridge,
>rather than because it is the root bridge. Or it might just be
>"good enough" to take whatever happens to fall out and document
>some configuration steps that would make sense if there's a real
>problem in a given deployment.
>  
>
I see a contradiction in your argument, the closeness to DR is important 
to choose the root bridge. What else can it be more than to be (the 
root) placed close to the forwarder? . You assume that the root has been 
elected by some special reasons.
I admit it can be stated as an option that RBridge might participate as 
root bridge with only one Designated port as alternative to not 
participating in STP, with the requirement that BPDUs received must be 
RSTP, not STP (speed reasons).

>	But there may be something to your concern for optimizing
>the root and designated forwarder equality as a critical aspect
>of the approach.
>
>	This looks like an excellent opportunity for someone to run
>simulations using randomly generated bridge/RBridge topologies.
>
>	The hypothesis is that having the designated forwarder for 
>an internal RBridge link be something other than the spanning tree
>root will have significant impact on forwarding efficiency.  It
>would be nice if the same topologies were used in simulations that
>assume:
>
>1) total random selection of both spanning tree root and designated
>link forwarder - how likely are the best, average and worst cases?
>
>2) a heuristic selection scheme: giving weight to selection of a
>designated forwarder likely to be adjacent to a spanning tree root
>- what will be the expected (average) impact on forwarding?
>
>  
>
In this case you transfer (and increase it) the complexity to the 
designated  forwarder election

>3) a deterministic approach that results in selecting a designated
>link forwarder with the shortest path adjacency to the STP root.
>
>  
>
It seems  simpler to force the root to be forwarder.

>	The antithesis is that the expected (average) difference, and
>a combination of likelihood of worst case and worst case difference,
>are not significant - taken together to be worth added complexity
>(assume a factor of 2 in cost/complexity).
>
>  
>
Depends on the average spanning tree length

>	One of the important factors to include in the simulations is
>that the effect on frame forwarding of having frames start at a leaf
>(or on a branch) as opposed to at the root is simply that it takes a
>slightly longer time for a broadcast frame to reach all the other 
>branches and leaves if it doesn't start at the root, than it does if
>it does start at the root. So the problem is delay efficiency based
>rather than throughput efficiency based.
>
>  
>
Not exactly. There is more congestion at the root if the forwarder is 
not root.

>	The simulation must not - for example - assume that spanning 
>tree forwarding works the same way as designated RBridge forwarding
>(it does not).
>
>	For example, given the below quasi-random spanning tree (with
>B1 as root) and designated RBridge forwarder (RB1*):
>
>			B1 --+
>                   |   |
>              B6 --+  B12 --+-- RB5
>               |       |    |
>       RB3 -- B5 --+  B4   B8 --+-- B10
>               |   |   |    |   |    |
>              B11 B2  B9   B3   B7  RB1*
>               |   |   |    |   |
>              RB7 RB2 RB4  RB8 RB6
>
>Question: what is the real difference between having this situation
>(B1 root, RB1* designated forwarder) and either of the following:
>
>a) B1 root, RB5 designated forwarder - or 
>b) RB5 both root and designated forwarder. 
>
>Given that the broadcast forwarding paths for the initial case are:
>
>o	RB1
>o	    B10, B7, RB6
>o	         B8, RB5
>o                  B3, RB8
>o                  B12, B4, B9, RB4
>o                       B1, B6, B5, RB3
>o                                   B2, RB2
>o                                   B11, RB7
>
>Case a):
>
>o	RB5
>o	    B8, B3, RB8
>o	        B7, RB6
>o	        B10, RB1
>o	    B12, B4, B9, RB4
>o	         B1, B6, B5, RB3
>o	                     B2, RB2
>o	                     B11, RB7
>
>For case b), it is necessary to make some assumptions about 1) how
>many redundant paths there were, where the blocked ones were, and 
>which will now be un-blocked by the spanning tree with RB5 as root.
>
>The average path length must be considered, rather than the worst
>case, because a broadcast frame might arrive at any RBridge (or any
>bridge, for that matter) - be forwarded to the designated forwarder
>along the spanning tree, and then forwarded along each of the paths
>determined (as shown above).
>
>I am pretty sure that the difference in average length of the path 
>will not be that significant - especially looking at it as a delay
>factor rather than a throughput factor.
>
>If the average length of the paths differs by - for example - one
>bridge-to-bridge link, then it is probably reasonable to argue that
>(on average) there will be one additional link that is traversed
>twice (once raw and once encapsulated) for each broadcast frame.
>It does seem likely that it will not always be the same bridge-to-
>bridge link every time.  
>
>But I suspect that it would be best if someone could take the time
>to simulate all this...
>
>  
>
I agree. But if no automatic tool is used for STP calculations in random 
topologies, it may be quite cumbersome. Does anybody know tools adequate 
for Eric proposal ? Random generated topology must be cut to a subset 
graph by the spanning tree (using node ID to select root or randomly) 
and path lengths calculated.
Guillermo

>--
>Eric
>
>
>
>
>
>--> -----Original Message-----
>--> From: [email-masked] 
>--> [mailto:[email-masked]]On
>--> Behalf Of Guillermo Ib??ez
>--> Sent: Friday, October 21, 2005 1:50 PM
>--> To: 'Developing a hybrid router/bridge.'
>--> Subject: Re: [rbridge] RBridge/bridge interaction
>--> 
>--> 
>--> My doubt is whether the DR Designation procedure is fast 
>--> and reliable enough
>--> for reconfigurations of the islands communicating the 
>--> Rbridges. Using the DR
>--> Rbridge as root bridge and linking the DR Designated role 
>--> of Rbridge to the
>--> role of root bridge  of the link, the root bridge election 
>--> at the link
>--> could be used also as a faster and reliable mechanism for 
>--> DR designation, as
>--> in fact the function is rather similar (although new: never 
>--> a root bridge
>--> had Root port to forward and receive packets). It may sound 
>--> complicated, I
>--> think in the long term it may be more complicated for 
>--> Rbridges to be DRs of
>--> a link that they do not control.
>--> Guillermo 
>--> 
>--> -----Mensaje original-----
>--> De: [email-masked] 
>--> [mailto:[email-masked]] En nombre
>--> de Gray, Eric
>--> Enviado el: viernes, 21 de octubre de 2005 19:07
>--> Para: 'Developing a hybrid router/bridge.'
>--> Asunto: Re: [rbridge] RBridge/bridge interaction
>--> 
>--> 
>--> Guillermo,
>--> 
>--> 	I had to think about what Radia was saying to realize
>--> that she is not objecting to merging one RBridge campus 
>--> with another.  If I
>--> understand correctly, what she is referring 
>--> to is merging spanning trees between two islands (or pockets) of
>--> 802/Ethernet bridges separated by a R-Bridge campus.
>--> 
>--> 	There's nothing to resolve, if the RBridge campus does 
>--> not participate in STP, or transparently pass it through 
>--> the campus from one
>--> island to another.
>--> 
>--> 	So, I suspect that we are not looking for a way to solve
>--> the problem, since there is a way to avoid it.
>--> 
>--> --
>--> Eric Gray
>--> 
>--> --> -----Original Message-----
>--> --> From: [email-masked]
>--> --> [mailto:[email-masked]]On
>--> --> Behalf Of Guillermo Ib??ez
>--> --> Sent: Friday, October 21, 2005 8:14 AM
>--> --> To: Developing a hybrid router/bridge.
>--> --> Subject: Re: [rbridge] RBridge/bridge interaction
>--> --> 
>--> --> 
>--> --> 
>--> --> 
>--> --> Radia Perlman wrote:
>--> --> 
>--> --> >I don't think there's any reason, even if most of the
>--> --> traffic on the
>--> --> >link comes from the DR, for the
>--> --> >DR to be the root of the spanning tree.
>--> --> >What would be bad is if an RBridge, participating in 
>--> two bridged
>--> --> >islands, winds up merging
>--> --> >the islands into a bigger island.
>--> --> >  
>--> --> >
>--> --> Good point, but I think it can be solved.
>--> --> The merging of islands can be prevented if the RBridge
>--> --> acting as root 
>--> --> limits to one port maximum in the Designated Port Role of 
>--> --> spanning tree 
>--> --> for sbridges.
>--> --> 
>--> --> >The whole point is to make the bridged islands as small as
>--> --> possible, so
>--> --> >most forwarding is done
>--> --> >protected by hop count, and with optimal routes.
>--> --> >
>--> --> >  
>--> --> >
>--> --> I'll admit that having RBridges *initiate* BPDUs
>--> --> 
>--> --> >to vie for being Root is not as harmful as having them
>--> --> *forward* BPDUs
>--> --> >between
>--> --> >bridged islands (provided an RBridge is careful not to
>--> --> merge two islands
>--> --> >that would
>--> --> >have been separate if the RBridge had just been 
>--> blocking BPDUs).
>--> --> >
>--> --> >We shouldn't make things more complex in an attempt to
>--> --> come up with a
>--> --> >"more optimal"
>--> --> >spanning tree within the bridged islands.
>--> --> >  
>--> --> >
>--> --> 
>--> --> >With a bidirectional tree, as happens with bridges,
>--> --> there's nothing
>--> --> >special about the Root.
>--> --> >Also, the traffic pattern might be such that most of the
>--> --> traffic is
>--> --> >between endnodes within
>--> --> >the island.
>--> --> >
>--> --> With the client server model, dominant traffic is to and
>--> --> from the core 
>--> --> layer of campus network, so I think most of the traffic 
>--> will flow 
>--> --> from/into Rbridge, not withing the islands.
>--> --> 
>--> --> >So there's really no reason to believe that having the
>--> --> >RBridge DR be the
>--> --> >spanning tree Root will result in better performance. And 
>--> --> is certainly
>--> --> >complicates things.
>--> --> >And it also certainly is dangerous because of the
>--> --> potential of merging
>--> --> >islands.
>--> --> >
>--> --> >  
>--> --> >
>--> --> I do not think is dangerous. The merging of islands is not
>--> --> convenient, 
>--> --> but it can be prevented, limiting to one port the 
>--> --> Designated Role in the 
>--> --> root Rbridge.
>--> --> Guillermo
>--> --> 
>--> --> >Radia
>--> --> >
>--> --> >
>--> --> >
>--> --> >Guillermo Ib??ez wrote:
>--> --> >
>--> --> >  
>--> --> >
>--> --> >>I see the standard root election mechanism of spanning
>--> --> tree islands as
>--> --> >>the fastest and simpler mechanism for DR Rbridge
>--> --> designation. I see the
>--> --> >>DR Rbridge as being necessarily the ROOT bridge of  that
>--> --> sbridged cloud
>--> --> >>(or "link"). The root bridge of a standard spanning 
>--> tree is the
>--> --> >>"natural" source and sink point for the spanning tree.  
>--> --> To do so, the DR
>--> --> >>must issue BPDUs to become the root bridge.  This is part
>--> --> of what I
>--> --> >>mentioned days ago as PARTICIPATE PER PORT, but may be we
>--> --> should call it
>--> --> >>SOURCE OR SINK (participate, do not forward BPDUs, only
>--> --> send own BPDUs
>--> --> >>to contend to be the root bridge of the link).
>--> --> >>The consequence of this DR election mechanism is that the
>--> --> priority
>--> --> >>configured at Rbridges as bridge ID would determine their
>--> --> also their
>--> --> >>election priority as DRs. I think this keep both domains
>--> --> coordinated
>--> --> >>with a single mechanism.
>--> --> >>Guillermo
>--> --> >>
>--> --> >>Radia Perlman wrote:
>--> --> >>
>--> --> >> 
>--> --> >>
>--> --> >>    
>--> --> >>
>--> --> >>>I don't believe there should be options here.
>--> --> >>>It should be plug and play.
>--> --> >>>RBridges should BLOCK bridge spanning tree messages,
>--> --> >>>and isolate the bridged islands.
>--> --> >>>
>--> --> >>>I absolutely do not understand what people are
>--> --> >>>worried about with BLOCK.
>--> --> >>>
>--> --> >>>I suggest someone that actually thinks there is
>--> --> >>>some reason to do anything other than drop
>--> --> >>>spanning tree messages start a thread with
>--> --> >>>a subject line
>--> --> >>>"why it is good for RBridges to forward BPDUs",
>--> --> >>>and very very carefully explain from scratch
>--> --> >>>what the reasoning is. Not with a long
>--> --> >>>email quoting pieces of other emails, but
>--> --> >>>with a carefully crafted, from scratch explanation
>--> --> >>>of what you perceive as a problem with BLOCk, and
>--> --> >>>what the perceived benefit of ever having
>--> --> >>>RBridges forwarding BPDUs would
>--> --> >>>be.
>--> --> >>>
>--> --> >>>Oh...and there was a much earlier thread of the
>--> --> >>>thread about other devices that might forward
>--> --> >>>or drop BPDUs. There have always been things we
>--> --> >>>referred to as "simple bridges" that forwarded spanning tree 
>--> --> >>>messages. I was careful to ensure that the spanning 
>--> tree would 
>--> --> >>>work with such devices. Of course the spanning tree 
>--> would not 
>--> --> >>>prevent a loop of all simple bridges, but if there 
>--> was at least 
>--> --> >>>one spanning tree bridge in the middle of every 
>--> possible loop, 
>--> --> >>>then there would wind up being no loops.
>--> --> >>>
>--> --> >>>You can think of "simple bridges" (ones that 
>--> mindlessly forward 
>--> --> >>>BPDUs) as a layer below bridges. They are invisible 
>--> to bridges. 
>--> --> >>>Bridges see a bunch of segments connected by simple 
>--> bridges as a 
>--> --> >>>single segment. (Just like RBridges will see a bunch 
>--> of segments 
>--> --> >>>connected by bridges as a single segment).
>--> --> >>>
>--> --> >>>Devices that drop BDPUs work if they are really
>--> --> >>>layered on top of bridges, i.e., they let the
>--> --> >>>bridges do their own thing to create isolated
>--> --> >>>broadcast domains, and then these other devices do
>--> --> >>>their own thing to glue these islands together.
>--> --> >>>Like routers do. And like RBridges will do.
>--> --> >>>
>--> --> >>>Radia
>--> --> >>>
>--> --> >>>
>--> --> >>>
>--> --> >>>Guillermo Ib??ez wrote On 10/20/05 14:35,:
>--> --> >>>
>--> --> >>>
>--> --> >>>   
>--> --> >>>
>--> --> >>>      
>--> --> >>>
>--> --> >>>>Eric,
>--> --> >>>>
>--> --> >>>>
>--> --> >>>>Gray, Eric wrote:
>--> --> >>>>
>--> --> >>>>
>--> --> >>>>  
>--> --> >>>>
>--> --> >>>>     
>--> --> >>>>
>--> --> >>>>        
>--> --> >>>>
>--> --> >>>>>Guillermo,
>--> --> >>>>>
>--> --> >>>>>	During the discussion, the terms TRANSPARENT,
>--> --> PARTICIPATE
>--> --> >>>>>and BLOCK were used (often in upper-case, exactly as I
>--> --> have used
>--> --> >>>>>them here) as if these would ultimately be options
>--> --> that might be
>--> --> >>>>>supported - either as a complete set, or as some subset.
>--> --> >>>>>
>--> --> >>>>>	For example, one argument was that TRANSPARENT
>--> --> or PARTICIPATE
>--> --> >>>>>might be used, but BLOCK should not.
>--> --> >>>>>
>--> --> >>>>>	Also, at certain points in the discussion,
>--> --> there was some
>--> --> >>>>>thought that these might be modes that applied at
>--> --> different states
>--> --> >>>>>during transitions in a network.
>--> --> >>>>>
>--> --> >>>>>	From a practical stand-point - however - it
>--> --> would be best if
>--> --> >>>>>we did not have to support all of these, either as
>--> --> options, or as
>--> --> >>>>>modes.  The mere fact that they were brought up does
>--> --> not mean we
>--> --> >>>>>are committed to including them.
>--> --> >>>>>
>--> --> >>>>>
>--> --> >>>>>
>--> --> >>>>>    
>--> --> >>>>>
>--> --> >>>>>       
>--> --> >>>>>
>--> --> >>>>>          
>--> --> >>>>>
>--> --> >>>>Agreed
>--> --> >>>>
>--> --> >>>>
>--> --> >>>>  
>--> --> >>>>
>--> --> >>>>     
>--> --> >>>>
>--> --> >>>>        
>--> --> >>>>
>--> --> >>>>>	In particular, if we start talking about - for
>--> --> instance -
>--> --> >>>>>having a per-interface option for all of these choices
>--> --> (and maybe
>--> --> >>>>>others as well), then we either need to analyze 
>--> proposals for
>--> --> >>>>>architecture and design to ensure that the "right 
>--> things" will
>--> --> >>>>>happen when an arbitrary combination of all of these 
>--> --> options is in
>--> --> >>>>>effect, or we need to define caveats for network
>--> --> operators to avoid
>--> --> >>>>>specific combinations of options.  For example, we may
>--> --> need to say
>--> --> >>>>>that the same option must be set throughout the
>--> --> network or this and
>--> --> >>>>>that will (or may) happen.  That kind of design begs
>--> --> configuration
>--> --> >>>>>errors to occur.
>--> --> >>>>>
>--> --> >>>>>
>--> --> >>>>>
>--> --> >>>>>    
>--> --> >>>>>
>--> --> >>>>>       
>--> --> >>>>>
>--> --> >>>>>          
>--> --> >>>>>
>--> --> >>>>If you refer as configuration options per interface to
>--> --> the PARTICIPATE
>--> --> >>>>PER PORT mode as an option per port, it is not the
>--> --> case. If  you refer
>--> --> >>>>to being the DR the root bridge of the sbridge domain,
>--> --> I think it must
>--> --> >>>>be analyzed as a real alternative, even if it is not
>--> --> the default
>--> --> >>>>configuration.
>--> --> >>>>
>--> --> >>>>
>--> --> >>>>  
>--> --> >>>>
>--> --> >>>>     
>--> --> >>>>
>--> --> >>>>        
>--> --> >>>>
>--> --> >>>>>	In this case, the fact that we want to make the
>--> --> solution plug
>--> --> >>>>>and play means that we can reduce the potential for
>--> --> disaster if we
>--> --> >>>>>choose (and require) a specific default set of option
>--> --> choices.  If
>--> --> >>>>>we can get away with it, however, we should simply
>--> --> avoid options.
>--> --> >>>>>
>--> --> >>>>>
>--> --> >>>>>
>--> --> >>>>>    
>--> --> >>>>>
>--> --> >>>>>       
>--> --> >>>>>
>--> --> >>>>>          
>--> --> >>>>>
>--> --> >>>>Agreed, but not for the root bridge problem because is
>--> --> a real, practical
>--> --> >>>>issue.
>--> --> >>>>
>--> --> >>>>
>--> --> >>>>  
>--> --> >>>>
>--> --> >>>>     
>--> --> >>>>
>--> --> >>>>        
>--> --> >>>>
>--> --> >>>>>	While having these same values as modes that
>--> --> apply during
>--> --> >>>>>certain transitional states is cleaner, it would
>--> --> require a well-
>--> --> >>>>>defined finite state-machine (not a particular 
>--> problem) and a
>--> --> >>>>>genuine need for these behaviors under certain 
>--> --> circumstances.  It
>--> --> >>>>>may well be the case that this turns out to be true.
>--> --> >>>>>
>--> --> >>>>>
>--> --> >>>>>
>--> --> >>>>>    
>--> --> >>>>>
>--> --> >>>>>       
>--> --> >>>>>
>--> --> >>>>>          
>--> --> >>>>>
>--> --> >>>>RSTP port state machines are there, may be they should
>--> --> be taken into
>--> --> >>>>consideration to make a consistent and integrated, but
>--> --> not interwoven,
>--> --> >>>>design for Rbridges that work with RSTP trees. Guillermo.
>--> --> >>>>
>--> --> >>>>
>--> --> >>>>  
>--> --> >>>>
>--> --> >>>>     
>--> --> >>>>
>--> --> >>>>        
>--> --> >>>>
>--> --> >>>>>--
>--> --> >>>>>Eric
>--> --> >>>>>
>--> --> >>>>>--> -----Original Message-----
>--> --> >>>>>--> From: [email-masked] 
>--> --> >>>>>--> [mailto:[email-masked]]On
>--> --> >>>>>--> Behalf Of Guillermo Ib??ez
>--> --> >>>>>--> Sent: Thursday, October 20, 2005 4:19 PM
>--> --> >>>>>--> To: Developing a hybrid router/bridge.
>--> --> >>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction
>--> --> >>>>>--> 
>--> --> >>>>>--> 
>--> --> >>>>>--> I volunteer for some work on the capture, although my 
>--> --> >>>>>--> english might be 
>--> --> >>>>>--> not too understandable.  From what date should 
>--> the capture 
>--> --> >>>>>--> to be done?
>--> --> >>>>>--> 
>--> --> >>>>>--> Regarding PARTICIPATE PER PORT:
>--> --> >>>>>--> Although I do not have a clear position, and it 
>--> --> requires detailed 
>--> --> >>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
>--> --> >>>>>--> better integrated 
>--> --> >>>>>--> with spanning tree, while maintaining the 
>--> basic decoupling 
>--> --> >>>>>--> that BLOCK 
>--> --> >>>>>--> provides.
>--> --> >>>>>--> With PARTICIPATE PER PORT it would be possible to 
>--> --> force the elected 
>--> --> >>>>>--> Rbridge to become the sbridge root of the bridged 
>--> --> domain by 
>--> --> >>>>>--> modifying 
>--> --> >>>>>--> its bridge priority when it gets elected as 
>--> Designated by 
>--> --> >>>>>--> IS-IS (this 
>--> --> >>>>>--> could be an optimization). In this way the 
>--> path length is 
>--> --> >>>>>--> minimum  from 
>--> --> >>>>>--> all bridges of bridged domain to the DR.
>--> --> >>>>>-->  
>--> --> >>>>>--> 
>--> --> >>>>>--> Erik Nordmark wrote:
>--> --> >>>>>--> 
>--> --> >>>>>--> >We've had some useful discussion on this mailing list.
>--> --> >>>>>--> >It would be good if somebody can capture the results 
>--> --> >>>>>--> (perhaps as a long 
>--> --> >>>>>--> >email) that we can fold into the draft(s) later. 
>--> --> Any volunteers?
>--> --> >>>>>--> >
>--> --> >>>>>--> >I don't know if we will have additional 
>--> issues in this 
>--> --> >>>>>--> space or that it 
>--> --> >>>>>--> >otherwise makes sense devoting agenda time to it 
>--> --> in Vancouver.
>--> --> >>>>>--> >
>--> --> >>>>>--> >For instance, while I'm convinced that BLOCK works, I 
>--> --> >>>>>--> wonder if there is 
>--> --> >>>>>--> >something in PARTICIPATE PER PORT that can make the 
>--> --> >>>>>--> interaction work better.
>--> --> >>>>>--> >
>--> --> >>>>>--> >Two cases to consider:
>--> --> >>>>>--> >1. The elected forwarder dies and a new one 
>--> gets elected. 
>--> --> >>>>>--> How quickly 
>--> --> >>>>>--> >can packets sent by stations in the bridged 
>--> cloud fail 
>--> --> >>>>>--> over to go to the 
>--> --> >>>>>--> >new elected forwarder?
>--> --> >>>>>--> >
>--> --> >>>>>--> >  
>--> --> >>>>>--> >
>--> --> >>>>>--> My understanding is that if the forwarded dies, 
>--> --> the sbridge domain 
>--> --> >>>>>--> should handle  it as  a topology change 
>--> --> notification, tables   of 
>--> --> >>>>>--> sbridges should be  flushed according to the 
>--> spanning tree 
>--> --> >>>>>--> rules, so the 
>--> --> >>>>>--> sbridge domain must know the DR will not 
>--> forward frames as 
>--> --> >>>>>--> it used to. 
>--> --> >>>>>--> It seems Rbridge shall issue a Topology Change 
>--> --> Notification 
>--> --> >>>>>--> via sbridge 
>--> --> >>>>>--> domain to flush MAC tables. Is a fast 
>--> analysis, probably I 
>--> --> >>>>>--> miss details.
>--> --> >>>>>-->  
>--> --> >>>>>--> 
>--> --> >>>>>--> >2. We have two separate bridged domains, each 
>--> --> with their elected 
>--> --> >>>>>--> >forwarder. Somebody connects the two bridged domains 
>--> --> >>>>>--> together with a 
>--> --> >>>>>--> >wire. This can cause a temporary loop until a single 
>--> --> >>>>>--> elected forwarder 
>--> --> >>>>>--> >is picked by the RBridges.
>--> --> >>>>>--> >
>--> --> >>>>>--> >  
>--> --> >>>>>--> >
>--> --> >>>>>--> In this case the PARTICIPATE PER PORT seems 
>--> superior, as 
>--> --> >>>>>--> the two merged 
>--> --> >>>>>--> bridged domains will merge their spanning 
>--> trees into one 
>--> --> >>>>>--> and both DRs 
>--> --> >>>>>--> will compete to be the root of the merged tree, 
>--> --> this mechanism will 
>--> --> >>>>>--> likely be faster (via RSTP fast transit to 
>--> --> forwarding state 
>--> --> >>>>>--> over the 
>--> --> >>>>>--> bridged domain)  than  Designation to select the 
>--> --> unique DR. 
>--> --> >>>>>--> In other 
>--> --> >>>>>--> words , the mechanism of root election in 
>--> sbridge could be 
>--> --> >>>>>--> used to help 
>--> --> >>>>>--> in DR designation and/or viceversa.
>--> --> >>>>>--> So I see in PARTICIPATE PER PORT, some 
>--> coupling between DR 
>--> --> >>>>>--> status and 
>--> --> >>>>>--> root status of sbridge domain that can be used
>--> --> >>>>>-->  to speed up convergence and coherence of both 
>--> domains. It 
>--> --> >>>>>--> seems that 
>--> --> >>>>>--> sbridge domains should be under the control of  
>--> --> Rbridges, but the 
>--> --> >>>>>--> sbridge mechanims should be used by Rbridges to 
>--> --> keep the network 
>--> --> >>>>>--> consistency and reconfiguration capabilities of RSTP.
>--> --> >>>>>--> Guillermo
>--> --> >>>>>--> 
>--> --> >>>>>-->  
>--> --> >>>>>--> _______________________________________________
>--> --> >>>>>--> rbridge mailing list
>--> --> >>>>>--> [email-masked]
>--> --> >>>>>--> http://www.postel.org/mailman/listinfo/rbridge
>--> --> >>>>>--> 
>--> --> >>>>>_______________________________________________
>--> --> >>>>>rbridge mailing list
>--> --> >>>>>[email-masked]
>--> --> >>>>>http://www.postel.org/mailman/listinfo/rbridge
>--> --> >>>>>
>--> --> >>>>>
>--> --> >>>>>
>--> --> >>>>>    
>--> --> >>>>>
>--> --> >>>>>       
>--> --> >>>>>
>--> --> >>>>>          
>--> --> >>>>>
>--> --> >>>>_______________________________________________
>--> --> >>>>rbridge mailing list
>--> --> >>>>[email-masked]
>--> --> >>>>http://www.postel.org/mailman/listinfo/rbridge
>--> --> >>>>  
>--> --> >>>>
>--> --> >>>>     
>--> --> >>>>
>--> --> >>>>        
>--> --> >>>>
>--> --> >>>_______________________________________________
>--> --> >>>rbridge mailing list
>--> --> >>>[email-masked]
>--> --> >>>http://www.postel.org/mailman/listinfo/rbridge
>--> --> >>>
>--> --> >>>
>--> --> >>>
>--> --> >>>   
>--> --> >>>
>--> --> >>>      
>--> --> >>>
>--> --> >>_______________________________________________
>--> --> >>rbridge mailing list
>--> --> >>[email-masked]
>--> --> >>http://www.postel.org/mailman/listinfo/rbridge
>--> --> >> 
>--> --> >>
>--> --> >>    
>--> --> >>
>--> --> >
>--> --> >_______________________________________________
>--> --> >rbridge mailing list
>--> --> >[email-masked]
>--> --> >http://www.postel.org/mailman/listinfo/rbridge
>--> --> >
>--> --> >  
>--> --> >
>--> --> _______________________________________________
>--> --> rbridge mailing list
>--> --> [email-masked]
>--> --> http://www.postel.org/mailman/listinfo/rbridge
>--> --> 
>--> _______________________________________________
>--> rbridge mailing list
>--> [email-masked]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>--> _______________________________________________
>--> rbridge mailing list
>--> [email-masked]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>[email-masked]

Date: Fri, 21 Oct 2005 14:36:08 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1175

Guillermo Ib??ez wrote:

>
>With the client server model, dominant traffic is to and from the core 
>layer of campus network, so I think most of the traffic will flow 
>from/into Rbridge, not withing the islands.
>
>  
>
If we buy that argument, then the same argument would say that routers 
should participate in
the spanning tree and attempt to become Root. And what if there are 
multiple routers?
If it's so vital for performance that one router is Root, then they'd 
all need to be Root within a bridged
network.

We shouldn't be trying to optimize that particular tree calculated by 
the bridged islands. Hopefully
those trees would become smaller and smaller. And even if we did care 
about some type of optimality,
I don't think trying to make one of the RBridges Root will make any 
difference. (Note "one of the
RBridges"...there can be several RBridges on the bridged island, so at 
most one of them can
be Root). People have lived for a long time without worrying about 
making one of the routers on
a bridged LAN be the Root in order to attempt more optimal delivery of 
traffic on/off the bridged LAN.
I don't think we should worry about it either.

Radia

Date: Fri, 21 Oct 2005 23:25:23 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4648

Interesting. More scenarios like this are worth to analyze. With more 
internal bridges between RBridges.
Guillermo

Gray, Eric wrote:

>RBridge Folks,
>
>	A way to look at the concept of a layer two device that
>handles looping possibilities/concerns in some way other than 
>by participating in STP - and is therefore not visible to STP
>participants - is that it likely looks (to STP participants
>- i.e. - 802/Ethernet bridges) like a single (possibly large)
>bridged LAN segment. It is simply a link with a lot of MAC 
>addresses on it. This is generally true for any device that 
>lives in the Layer two world and is not an 802/Ethernet bridge, 
>a host, or a router.
>
>	In the RBridge case, there are two bridging scenarios to
>consider: bridges between RBridges (or two, or more, interfaces 
>of the same RBridge) and bridges attached to at most one RBridge 
>interface.  We have loosely been referring to the former case as
>"internal" bridges and the latter as "external" bridges, because 
>of the assumption that RBridges merge into a single campus and
>- therefore - having more than one RBridge interface on a single
>bridged LAN segment puts that segment "inside" the campus.
>
>	Consequently, we can assume that there are no stable back
>connections between "external" bridged LAN segments because any 
>such back connection will necessarily make affected "external" 
>LAN segments "internal".
>
>	For example, in the following simple network:
>
>                            H1  H2 H3
>                              \ | /
>                               RB1
>    H4 --.__                  /   \             __.-- H5
>    H6 ----->-- B1 -- B2 -- RB2 -- RB3 -- B3 --<----- H7
>    H8 ----^           |      \   /     ___|________
>                      B4       \ /      |   |  |   |
>                  _____|___    B5      L1  H9 H10 H11
>                  |   |   |     |\
>                 H12 H13  L2    | \
>                              H14 H15
>
>As shown, the LAN segment consisting of bridges B1, B2 and B4, hosts 
>H4, H6, H8, H12 and H13, and currently unused link L2 are an external
>bridged LAN segment.  The LAN segment consisting of bridge B3 and the
>hosts H5, H7, H9, H10 and H11, and currently unused link L1 are also
>an external bridged LAN segment.  The LAN segment consisting of bridge
>B5 and hosts H14 and H15 is an internal bridged LAN segment, while 
>hosts H1, H2 and H3 are on separate external LAN segments.
>
>Connecting bridges B3 and B4, by connecting currently unused links L1
>and L2 will make bridges B1-B4 and hosts H4-H13 all part of the same
>_internal_ LAN segment.
>
>Other things to note about this network, as is, if RBridges ignore STP:
>
>o	to the RBridges, the network looks like this -
>
>               H1  H2 H3
>    H4 -+       |__|__|         +- H5
>        |          |            |
>    H6 -+         RB1           +- H7
>        |        /   \          |
>    H8 -+---- RB2 --- RB3 ------+- H9
>        |        \___/          |
>   H12 -+          |            +- H10
>        |        __|__          |
>   H13 -+        |   |          +- H11
>                H14 H15
>
>o	to bridges B1, B2 and B4, the network looks like this -
>
>                           +------ H1
>                           +- H2
>                           +------ H3
>    H4 -+                  +- H5
>        |                  +------ H7
>    H6 -+--- B1 -- B2 -----+- H9
>        |           |      +------ H10
>    H8 -+          B4      +- H11
>                 ___|_     +------ H14
>                 |   |     +- H15
>                H12 H13
>
>o	to bridge B3, the network looks like this - 
>                           
>    H1 ------+  
>         H2 -+
>    H3 ------+                +- H5
>         H4 -+                |
>    H6 ------+---- B3 --------+- H7
>         H8 -+   ___|_____
>   H12 ------+   |   |   |
>        H13 -+   H9 H10 H11
>   H14 ------+ 
>        H15 -+
>
>o	because B5 is on an internal LAN segment, its view of host 
>and RBridge MAC addresses will be - at least in part - determined
>by shortest path (spanning tree) computation; it might, for example
>see the network like this (B5 rotated 45 degrees CCW) - 
>
>    H1 ------+      +---------+------ H2         
>         H4 -+      |         +- H3
>    H6 ------+----- B5 --+    +------ H5
>         H8 -+      |    |    +- H7
>   H12 ------+      |    |    +------ H9
>        H13 -+     H14  H15   +- H10
>                              +------ H11
>
>--
>Eric Gray
>
>[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 21 Oct 2005 18:17:03 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 25174

Guillermo,

	Here's the problem: in  order for an RBridge to be the 
spanning tree root for bridges, it has to participate in bridge
STP.  Nothing else will work.  However, it would be better from
a simplicity perspective if the designated RBridge forwarder for
a link were selected on a basis of proximity to the root bridge,
rather than because it is the root bridge. Or it might just be
"good enough" to take whatever happens to fall out and document
some configuration steps that would make sense if there's a real
problem in a given deployment.

	But there may be something to your concern for optimizing
the root and designated forwarder equality as a critical aspect
of the approach.

	This looks like an excellent opportunity for someone to run
simulations using randomly generated bridge/RBridge topologies.

	The hypothesis is that having the designated forwarder for 
an internal RBridge link be something other than the spanning tree
root will have significant impact on forwarding efficiency.  It
would be nice if the same topologies were used in simulations that
assume:

1) total random selection of both spanning tree root and designated
link forwarder - how likely are the best, average and worst cases?

2) a heuristic selection scheme: giving weight to selection of a
designated forwarder likely to be adjacent to a spanning tree root
- what will be the expected (average) impact on forwarding?

3) a deterministic approach that results in selecting a designated
link forwarder with the shortest path adjacency to the STP root.

	The antithesis is that the expected (average) difference, and
a combination of likelihood of worst case and worst case difference,
are not significant - taken together to be worth added complexity
(assume a factor of 2 in cost/complexity).

	One of the important factors to include in the simulations is
that the effect on frame forwarding of having frames start at a leaf
(or on a branch) as opposed to at the root is simply that it takes a
slightly longer time for a broadcast frame to reach all the other 
branches and leaves if it doesn't start at the root, than it does if
it does start at the root. So the problem is delay efficiency based
rather than throughput efficiency based.

	The simulation must not - for example - assume that spanning 
tree forwarding works the same way as designated RBridge forwarding
(it does not).

	For example, given the below quasi-random spanning tree (with
B1 as root) and designated RBridge forwarder (RB1*):

			B1 --+
                   |   |
              B6 --+  B12 --+-- RB5
               |       |    |
       RB3 -- B5 --+  B4   B8 --+-- B10
               |   |   |    |   |    |
              B11 B2  B9   B3   B7  RB1*
               |   |   |    |   |
              RB7 RB2 RB4  RB8 RB6

Question: what is the real difference between having this situation
(B1 root, RB1* designated forwarder) and either of the following:

a) B1 root, RB5 designated forwarder - or 
b) RB5 both root and designated forwarder. 

Given that the broadcast forwarding paths for the initial case are:

o	RB1
o	    B10, B7, RB6
o	         B8, RB5
o                  B3, RB8
o                  B12, B4, B9, RB4
o                       B1, B6, B5, RB3
o                                   B2, RB2
o                                   B11, RB7

Case a):

o	RB5
o	    B8, B3, RB8
o	        B7, RB6
o	        B10, RB1
o	    B12, B4, B9, RB4
o	         B1, B6, B5, RB3
o	                     B2, RB2
o	                     B11, RB7

For case b), it is necessary to make some assumptions about 1) how
many redundant paths there were, where the blocked ones were, and 
which will now be un-blocked by the spanning tree with RB5 as root.

The average path length must be considered, rather than the worst
case, because a broadcast frame might arrive at any RBridge (or any
bridge, for that matter) - be forwarded to the designated forwarder
along the spanning tree, and then forwarded along each of the paths
determined (as shown above).

I am pretty sure that the difference in average length of the path 
will not be that significant - especially looking at it as a delay
factor rather than a throughput factor.

If the average length of the paths differs by - for example - one
bridge-to-bridge link, then it is probably reasonable to argue that
(on average) there will be one additional link that is traversed
twice (once raw and once encapsulated) for each broadcast frame.
It does seem likely that it will not always be the same bridge-to-
bridge link every time.  

But I suspect that it would be best if someone could take the time
to simulate all this...

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Friday, October 21, 2005 1:50 PM
--> To: 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> My doubt is whether the DR Designation procedure is fast 
--> and reliable enough
--> for reconfigurations of the islands communicating the 
--> Rbridges. Using the DR
--> Rbridge as root bridge and linking the DR Designated role 
--> of Rbridge to the
--> role of root bridge  of the link, the root bridge election 
--> at the link
--> could be used also as a faster and reliable mechanism for 
--> DR designation, as
--> in fact the function is rather similar (although new: never 
--> a root bridge
--> had Root port to forward and receive packets). It may sound 
--> complicated, I
--> think in the long term it may be more complicated for 
--> Rbridges to be DRs of
--> a link that they do not control.
--> Guillermo 
--> 
--> -----Mensaje original-----
--> De: [email-masked] 
--> [mailto:[email-masked]] En nombre
--> de Gray, Eric
--> Enviado el: viernes, 21 de octubre de 2005 19:07
--> Para: 'Developing a hybrid router/bridge.'
--> Asunto: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> Guillermo,
--> 
--> 	I had to think about what Radia was saying to realize
--> that she is not objecting to merging one RBridge campus 
--> with another.  If I
--> understand correctly, what she is referring 
--> to is merging spanning trees between two islands (or pockets) of
--> 802/Ethernet bridges separated by a R-Bridge campus.
--> 
--> 	There's nothing to resolve, if the RBridge campus does 
--> not participate in STP, or transparently pass it through 
--> the campus from one
--> island to another.
--> 
--> 	So, I suspect that we are not looking for a way to solve
--> the problem, since there is a way to avoid it.
--> 
--> --
--> Eric Gray
--> 
--> --> -----Original Message-----
--> --> From: [email-masked]
--> --> [mailto:[email-masked]]On
--> --> Behalf Of Guillermo Ib??ez
--> --> Sent: Friday, October 21, 2005 8:14 AM
--> --> To: Developing a hybrid router/bridge.
--> --> Subject: Re: [rbridge] RBridge/bridge interaction
--> --> 
--> --> 
--> --> 
--> --> 
--> --> Radia Perlman wrote:
--> --> 
--> --> >I don't think there's any reason, even if most of the
--> --> traffic on the
--> --> >link comes from the DR, for the
--> --> >DR to be the root of the spanning tree.
--> --> >What would be bad is if an RBridge, participating in 
--> two bridged
--> --> >islands, winds up merging
--> --> >the islands into a bigger island.
--> --> >  
--> --> >
--> --> Good point, but I think it can be solved.
--> --> The merging of islands can be prevented if the RBridge
--> --> acting as root 
--> --> limits to one port maximum in the Designated Port Role of 
--> --> spanning tree 
--> --> for sbridges.
--> --> 
--> --> >The whole point is to make the bridged islands as small as
--> --> possible, so
--> --> >most forwarding is done
--> --> >protected by hop count, and with optimal routes.
--> --> >
--> --> >  
--> --> >
--> --> I'll admit that having RBridges *initiate* BPDUs
--> --> 
--> --> >to vie for being Root is not as harmful as having them
--> --> *forward* BPDUs
--> --> >between
--> --> >bridged islands (provided an RBridge is careful not to
--> --> merge two islands
--> --> >that would
--> --> >have been separate if the RBridge had just been 
--> blocking BPDUs).
--> --> >
--> --> >We shouldn't make things more complex in an attempt to
--> --> come up with a
--> --> >"more optimal"
--> --> >spanning tree within the bridged islands.
--> --> >  
--> --> >
--> --> 
--> --> >With a bidirectional tree, as happens with bridges,
--> --> there's nothing
--> --> >special about the Root.
--> --> >Also, the traffic pattern might be such that most of the
--> --> traffic is
--> --> >between endnodes within
--> --> >the island.
--> --> >
--> --> With the client server model, dominant traffic is to and
--> --> from the core 
--> --> layer of campus network, so I think most of the traffic 
--> will flow 
--> --> from/into Rbridge, not withing the islands.
--> --> 
--> --> >So there's really no reason to believe that having the
--> --> >RBridge DR be the
--> --> >spanning tree Root will result in better performance. And 
--> --> is certainly
--> --> >complicates things.
--> --> >And it also certainly is dangerous because of the
--> --> potential of merging
--> --> >islands.
--> --> >
--> --> >  
--> --> >
--> --> I do not think is dangerous. The merging of islands is not
--> --> convenient, 
--> --> but it can be prevented, limiting to one port the 
--> --> Designated Role in the 
--> --> root Rbridge.
--> --> Guillermo
--> --> 
--> --> >Radia
--> --> >
--> --> >
--> --> >
--> --> >Guillermo Ib??ez wrote:
--> --> >
--> --> >  
--> --> >
--> --> >>I see the standard root election mechanism of spanning
--> --> tree islands as
--> --> >>the fastest and simpler mechanism for DR Rbridge
--> --> designation. I see the
--> --> >>DR Rbridge as being necessarily the ROOT bridge of  that
--> --> sbridged cloud
--> --> >>(or "link"). The root bridge of a standard spanning 
--> tree is the
--> --> >>"natural" source and sink point for the spanning tree.  
--> --> To do so, the DR
--> --> >>must issue BPDUs to become the root bridge.  This is part
--> --> of what I
--> --> >>mentioned days ago as PARTICIPATE PER PORT, but may be we
--> --> should call it
--> --> >>SOURCE OR SINK (participate, do not forward BPDUs, only
--> --> send own BPDUs
--> --> >>to contend to be the root bridge of the link).
--> --> >>The consequence of this DR election mechanism is that the
--> --> priority
--> --> >>configured at Rbridges as bridge ID would determine their
--> --> also their
--> --> >>election priority as DRs. I think this keep both domains
--> --> coordinated
--> --> >>with a single mechanism.
--> --> >>Guillermo
--> --> >>
--> --> >>Radia Perlman wrote:
--> --> >>
--> --> >> 
--> --> >>
--> --> >>    
--> --> >>
--> --> >>>I don't believe there should be options here.
--> --> >>>It should be plug and play.
--> --> >>>RBridges should BLOCK bridge spanning tree messages,
--> --> >>>and isolate the bridged islands.
--> --> >>>
--> --> >>>I absolutely do not understand what people are
--> --> >>>worried about with BLOCK.
--> --> >>>
--> --> >>>I suggest someone that actually thinks there is
--> --> >>>some reason to do anything other than drop
--> --> >>>spanning tree messages start a thread with
--> --> >>>a subject line
--> --> >>>"why it is good for RBridges to forward BPDUs",
--> --> >>>and very very carefully explain from scratch
--> --> >>>what the reasoning is. Not with a long
--> --> >>>email quoting pieces of other emails, but
--> --> >>>with a carefully crafted, from scratch explanation
--> --> >>>of what you perceive as a problem with BLOCk, and
--> --> >>>what the perceived benefit of ever having
--> --> >>>RBridges forwarding BPDUs would
--> --> >>>be.
--> --> >>>
--> --> >>>Oh...and there was a much earlier thread of the
--> --> >>>thread about other devices that might forward
--> --> >>>or drop BPDUs. There have always been things we
--> --> >>>referred to as "simple bridges" that forwarded spanning tree 
--> --> >>>messages. I was careful to ensure that the spanning 
--> tree would 
--> --> >>>work with such devices. Of course the spanning tree 
--> would not 
--> --> >>>prevent a loop of all simple bridges, but if there 
--> was at least 
--> --> >>>one spanning tree bridge in the middle of every 
--> possible loop, 
--> --> >>>then there would wind up being no loops.
--> --> >>>
--> --> >>>You can think of "simple bridges" (ones that 
--> mindlessly forward 
--> --> >>>BPDUs) as a layer below bridges. They are invisible 
--> to bridges. 
--> --> >>>Bridges see a bunch of segments connected by simple 
--> bridges as a 
--> --> >>>single segment. (Just like RBridges will see a bunch 
--> of segments 
--> --> >>>connected by bridges as a single segment).
--> --> >>>
--> --> >>>Devices that drop BDPUs work if they are really
--> --> >>>layered on top of bridges, i.e., they let the
--> --> >>>bridges do their own thing to create isolated
--> --> >>>broadcast domains, and then these other devices do
--> --> >>>their own thing to glue these islands together.
--> --> >>>Like routers do. And like RBridges will do.
--> --> >>>
--> --> >>>Radia
--> --> >>>
--> --> >>>
--> --> >>>
--> --> >>>Guillermo Ib??ez wrote On 10/20/05 14:35,:
--> --> >>>
--> --> >>>
--> --> >>>   
--> --> >>>
--> --> >>>      
--> --> >>>
--> --> >>>>Eric,
--> --> >>>>
--> --> >>>>
--> --> >>>>Gray, Eric wrote:
--> --> >>>>
--> --> >>>>
--> --> >>>>  
--> --> >>>>
--> --> >>>>     
--> --> >>>>
--> --> >>>>        
--> --> >>>>
--> --> >>>>>Guillermo,
--> --> >>>>>
--> --> >>>>>	During the discussion, the terms TRANSPARENT,
--> --> PARTICIPATE
--> --> >>>>>and BLOCK were used (often in upper-case, exactly as I
--> --> have used
--> --> >>>>>them here) as if these would ultimately be options
--> --> that might be
--> --> >>>>>supported - either as a complete set, or as some subset.
--> --> >>>>>
--> --> >>>>>	For example, one argument was that TRANSPARENT
--> --> or PARTICIPATE
--> --> >>>>>might be used, but BLOCK should not.
--> --> >>>>>
--> --> >>>>>	Also, at certain points in the discussion,
--> --> there was some
--> --> >>>>>thought that these might be modes that applied at
--> --> different states
--> --> >>>>>during transitions in a network.
--> --> >>>>>
--> --> >>>>>	From a practical stand-point - however - it
--> --> would be best if
--> --> >>>>>we did not have to support all of these, either as
--> --> options, or as
--> --> >>>>>modes.  The mere fact that they were brought up does
--> --> not mean we
--> --> >>>>>are committed to including them.
--> --> >>>>>
--> --> >>>>>
--> --> >>>>>
--> --> >>>>>    
--> --> >>>>>
--> --> >>>>>       
--> --> >>>>>
--> --> >>>>>          
--> --> >>>>>
--> --> >>>>Agreed
--> --> >>>>
--> --> >>>>
--> --> >>>>  
--> --> >>>>
--> --> >>>>     
--> --> >>>>
--> --> >>>>        
--> --> >>>>
--> --> >>>>>	In particular, if we start talking about - for
--> --> instance -
--> --> >>>>>having a per-interface option for all of these choices
--> --> (and maybe
--> --> >>>>>others as well), then we either need to analyze 
--> proposals for
--> --> >>>>>architecture and design to ensure that the "right 
--> things" will
--> --> >>>>>happen when an arbitrary combination of all of these 
--> --> options is in
--> --> >>>>>effect, or we need to define caveats for network
--> --> operators to avoid
--> --> >>>>>specific combinations of options.  For example, we may
--> --> need to say
--> --> >>>>>that the same option must be set throughout the
--> --> network or this and
--> --> >>>>>that will (or may) happen.  That kind of design begs
--> --> configuration
--> --> >>>>>errors to occur.
--> --> >>>>>
--> --> >>>>>
--> --> >>>>>
--> --> >>>>>    
--> --> >>>>>
--> --> >>>>>       
--> --> >>>>>
--> --> >>>>>          
--> --> >>>>>
--> --> >>>>If you refer as configuration options per interface to
--> --> the PARTICIPATE
--> --> >>>>PER PORT mode as an option per port, it is not the
--> --> case. If  you refer
--> --> >>>>to being the DR the root bridge of the sbridge domain,
--> --> I think it must
--> --> >>>>be analyzed as a real alternative, even if it is not
--> --> the default
--> --> >>>>configuration.
--> --> >>>>
--> --> >>>>
--> --> >>>>  
--> --> >>>>
--> --> >>>>     
--> --> >>>>
--> --> >>>>        
--> --> >>>>
--> --> >>>>>	In this case, the fact that we want to make the
--> --> solution plug
--> --> >>>>>and play means that we can reduce the potential for
--> --> disaster if we
--> --> >>>>>choose (and require) a specific default set of option
--> --> choices.  If
--> --> >>>>>we can get away with it, however, we should simply
--> --> avoid options.
--> --> >>>>>
--> --> >>>>>
--> --> >>>>>
--> --> >>>>>    
--> --> >>>>>
--> --> >>>>>       
--> --> >>>>>
--> --> >>>>>          
--> --> >>>>>
--> --> >>>>Agreed, but not for the root bridge problem because is
--> --> a real, practical
--> --> >>>>issue.
--> --> >>>>
--> --> >>>>
--> --> >>>>  
--> --> >>>>
--> --> >>>>     
--> --> >>>>
--> --> >>>>        
--> --> >>>>
--> --> >>>>>	While having these same values as modes that
--> --> apply during
--> --> >>>>>certain transitional states is cleaner, it would
--> --> require a well-
--> --> >>>>>defined finite state-machine (not a particular 
--> problem) and a
--> --> >>>>>genuine need for these behaviors under certain 
--> --> circumstances.  It
--> --> >>>>>may well be the case that this turns out to be true.
--> --> >>>>>
--> --> >>>>>
--> --> >>>>>
--> --> >>>>>    
--> --> >>>>>
--> --> >>>>>       
--> --> >>>>>
--> --> >>>>>          
--> --> >>>>>
--> --> >>>>RSTP port state machines are there, may be they should
--> --> be taken into
--> --> >>>>consideration to make a consistent and integrated, but
--> --> not interwoven,
--> --> >>>>design for Rbridges that work with RSTP trees. Guillermo.
--> --> >>>>
--> --> >>>>
--> --> >>>>  
--> --> >>>>
--> --> >>>>     
--> --> >>>>
--> --> >>>>        
--> --> >>>>
--> --> >>>>>--
--> --> >>>>>Eric
--> --> >>>>>
--> --> >>>>>--> -----Original Message-----
--> --> >>>>>--> From: [email-masked] 
--> --> >>>>>--> [mailto:[email-masked]]On
--> --> >>>>>--> Behalf Of Guillermo Ib??ez
--> --> >>>>>--> Sent: Thursday, October 20, 2005 4:19 PM
--> --> >>>>>--> To: Developing a hybrid router/bridge.
--> --> >>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction
--> --> >>>>>--> 
--> --> >>>>>--> 
--> --> >>>>>--> I volunteer for some work on the capture, although my 
--> --> >>>>>--> english might be 
--> --> >>>>>--> not too understandable.  From what date should 
--> the capture 
--> --> >>>>>--> to be done?
--> --> >>>>>--> 
--> --> >>>>>--> Regarding PARTICIPATE PER PORT:
--> --> >>>>>--> Although I do not have a clear position, and it 
--> --> requires detailed 
--> --> >>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
--> --> >>>>>--> better integrated 
--> --> >>>>>--> with spanning tree, while maintaining the 
--> basic decoupling 
--> --> >>>>>--> that BLOCK 
--> --> >>>>>--> provides.
--> --> >>>>>--> With PARTICIPATE PER PORT it would be possible to 
--> --> force the elected 
--> --> >>>>>--> Rbridge to become the sbridge root of the bridged 
--> --> domain by 
--> --> >>>>>--> modifying 
--> --> >>>>>--> its bridge priority when it gets elected as 
--> Designated by 
--> --> >>>>>--> IS-IS (this 
--> --> >>>>>--> could be an optimization). In this way the 
--> path length is 
--> --> >>>>>--> minimum  from 
--> --> >>>>>--> all bridges of bridged domain to the DR.
--> --> >>>>>-->  
--> --> >>>>>--> 
--> --> >>>>>--> Erik Nordmark wrote:
--> --> >>>>>--> 
--> --> >>>>>--> >We've had some useful discussion on this mailing list.
--> --> >>>>>--> >It would be good if somebody can capture the results 
--> --> >>>>>--> (perhaps as a long 
--> --> >>>>>--> >email) that we can fold into the draft(s) later. 
--> --> Any volunteers?
--> --> >>>>>--> >
--> --> >>>>>--> >I don't know if we will have additional 
--> issues in this 
--> --> >>>>>--> space or that it 
--> --> >>>>>--> >otherwise makes sense devoting agenda time to it 
--> --> in Vancouver.
--> --> >>>>>--> >
--> --> >>>>>--> >For instance, while I'm convinced that BLOCK works, I 
--> --> >>>>>--> wonder if there is 
--> --> >>>>>--> >something in PARTICIPATE PER PORT that can make the 
--> --> >>>>>--> interaction work better.
--> --> >>>>>--> >
--> --> >>>>>--> >Two cases to consider:
--> --> >>>>>--> >1. The elected forwarder dies and a new one 
--> gets elected. 
--> --> >>>>>--> How quickly 
--> --> >>>>>--> >can packets sent by stations in the bridged 
--> cloud fail 
--> --> >>>>>--> over to go to the 
--> --> >>>>>--> >new elected forwarder?
--> --> >>>>>--> >
--> --> >>>>>--> >  
--> --> >>>>>--> >
--> --> >>>>>--> My understanding is that if the forwarded dies, 
--> --> the sbridge domain 
--> --> >>>>>--> should handle  it as  a topology change 
--> --> notification, tables   of 
--> --> >>>>>--> sbridges should be  flushed according to the 
--> spanning tree 
--> --> >>>>>--> rules, so the 
--> --> >>>>>--> sbridge domain must know the DR will not 
--> forward frames as 
--> --> >>>>>--> it used to. 
--> --> >>>>>--> It seems Rbridge shall issue a Topology Change 
--> --> Notification 
--> --> >>>>>--> via sbridge 
--> --> >>>>>--> domain to flush MAC tables. Is a fast 
--> analysis, probably I 
--> --> >>>>>--> miss details.
--> --> >>>>>-->  
--> --> >>>>>--> 
--> --> >>>>>--> >2. We have two separate bridged domains, each 
--> --> with their elected 
--> --> >>>>>--> >forwarder. Somebody connects the two bridged domains 
--> --> >>>>>--> together with a 
--> --> >>>>>--> >wire. This can cause a temporary loop until a single 
--> --> >>>>>--> elected forwarder 
--> --> >>>>>--> >is picked by the RBridges.
--> --> >>>>>--> >
--> --> >>>>>--> >  
--> --> >>>>>--> >
--> --> >>>>>--> In this case the PARTICIPATE PER PORT seems 
--> superior, as 
--> --> >>>>>--> the two merged 
--> --> >>>>>--> bridged domains will merge their spanning 
--> trees into one 
--> --> >>>>>--> and both DRs 
--> --> >>>>>--> will compete to be the root of the merged tree, 
--> --> this mechanism will 
--> --> >>>>>--> likely be faster (via RSTP fast transit to 
--> --> forwarding state 
--> --> >>>>>--> over the 
--> --> >>>>>--> bridged domain)  than  Designation to select the 
--> --> unique DR. 
--> --> >>>>>--> In other 
--> --> >>>>>--> words , the mechanism of root election in 
--> sbridge could be 
--> --> >>>>>--> used to help 
--> --> >>>>>--> in DR designation and/or viceversa.
--> --> >>>>>--> So I see in PARTICIPATE PER PORT, some 
--> coupling between DR 
--> --> >>>>>--> status and 
--> --> >>>>>--> root status of sbridge domain that can be used
--> --> >>>>>-->  to speed up convergence and coherence of both 
--> domains. It 
--> --> >>>>>--> seems that 
--> --> >>>>>--> sbridge domains should be under the control of  
--> --> Rbridges, but the 
--> --> >>>>>--> sbridge mechanims should be used by Rbridges to 
--> --> keep the network 
--> --> >>>>>--> consistency and reconfiguration capabilities of RSTP.
--> --> >>>>>--> Guillermo
--> --> >>>>>--> 
--> --> >>>>>-->  
--> --> >>>>>--> _______________________________________________
--> --> >>>>>--> rbridge mailing list
--> --> >>>>>--> [email-masked]
--> --> >>>>>--> http://www.postel.org/mailman/listinfo/rbridge
--> --> >>>>>--> 
--> --> >>>>>_______________________________________________
--> --> >>>>>rbridge mailing list
--> --> >>>>>[email-masked]
--> --> >>>>>http://www.postel.org/mailman/listinfo/rbridge
--> --> >>>>>
--> --> >>>>>
--> --> >>>>>
--> --> >>>>>    
--> --> >>>>>
--> --> >>>>>       
--> --> >>>>>
--> --> >>>>>          
--> --> >>>>>
--> --> >>>>_______________________________________________
--> --> >>>>rbridge mailing list
--> --> >>>>[email-masked]
--> --> >>>>http://www.postel.org/mailman/listinfo/rbridge
--> --> >>>>  
--> --> >>>>
--> --> >>>>     
--> --> >>>>
--> --> >>>>        
--> --> >>>>
--> --> >>>_______________________________________________
--> --> >>>rbridge mailing list
--> --> >>>[email-masked]
--> --> >>>http://www.postel.org/mailman/listinfo/rbridge
--> --> >>>
--> --> >>>
--> --> >>>
--> --> >>>   
--> --> >>>
--> --> >>>      
--> --> >>>
--> --> >>_______________________________________________
--> --> >>rbridge mailing list
--> --> >>[email-masked]
--> --> >>http://www.postel.org/mailman/listinfo/rbridge
--> --> >> 
--> --> >>
--> --> >>    
--> --> >>
--> --> >
--> --> >_______________________________________________
--> --> >rbridge mailing list
--> --> >[email-masked]
--> --> >http://www.postel.org/mailman/listinfo/rbridge
--> --> >
--> --> >  
--> --> >
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked]
--> --> http://www.postel.org/mailman/listinfo/rbridge
--> --> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Fri, 21 Oct 2005 23:16:01 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 18697

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. 
This effort is peanuts if you compare with VLAN configuration, and it  
has been accepted without any opposition.
The second point is how fast is the DR election process is actually.
The third point is that "being aware of bridges" just means that 
RBridges participate in the root election process, where only the 
RBridges will apply to be root. Not a real issue. It is much more 
complex to handle per VLAN spanning trees. So it  is only an  apparent 
complexity.  My feeling is that the "uncontrolled sbridge islands" will 
sooner or later require control. I understand that now is not wellcome 
to include the bridges in the design. Although we might like to make the 
RBridges fully independent of bridges, the whole is a system and must be 
slightly coordinated or we risk more unpredictable behaviour of specific 
situations that will at the end require more tight control of the 
spanning trees.
I now realiza that the difference in view probably derives from the fact 
that Radia perhaps tend to think on STP, that provides  timer-based 
convergence (slow), and I tend to think in RSTP (faster  than IS-IS I 
presume). I might agree that both situations are different and STP is 
not an alternative due to slow convergence, but the current IEEE 
standard is RSTP, so it will be dominant in the near term in networks, 
decisions should be based on RSTP performance.
Guillermo

Gray, Eric wrote:

>Guillermo,
>
>	I think the point is that .coordination between bridges
>and RBridges means at least RBridges have to be aware of the
>bridges.  I say this because having bridges be aware of the
>RBridges - at least as RBridges - is not an option.
>
>	Having even the RBridges being necessarily aware of all
>bridges is unnecessary and would therefore add complexity to
>RBridges.  If you would like to make the point that the root
>election process is not complicated, first I would disagree 
>(because - minimally - it adds complexity to a configuration 
>process, which is something we're trying to avoid) and second
>I would point out that any complexity that is unecessary is a
>complication that should be avoided.
>
>	The processes of IS-IS and multicast DR election are, of
>course, completely independent of the existence of bridges.
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: [email-masked] 
>--> [mailto:[email-masked]]On
>--> Behalf Of Guillermo Ib??ez
>--> Sent: Friday, October 21, 2005 8:26 AM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] RBridge/bridge interaction
>--> 
>--> 
>--> I agree suboptimality is not the key issue, but 
>--> coordination between STP 
>--> and RBridges  regarding DR election (faster DR election 
>--> IMMO, although I 
>--> know nothing about IS-IS DR election) . Path optimization is a plus.
>--> Guillermo
>--> 
>--> Gray, Eric wrote:
>--> 
>--> >Guillermo,
>--> >
>--> >	Actually, the thing about a spanning tree is that 
>--> frames entering
>--> >the tree will reach every node.  Hence the result of 
>--> having an RBridge
>--> >be something other than the root of the local spanning 
>--> tree would be 
>--> >that frame delivery might be sub-optimal.  In fact, it is not even
>--> >necessary for the R-Bridge to be directly connected to the 
>--> root of a
>--> >local spanning tree.
>--> >
>--> >	That's part of the reason why an RBridge does not need to be a
>--> >part of the local STP.
>--> >
>--> >	Given the way that spanning tree works in general, sub-optimal 
>--> >delivery of frames would not be something new.  Having th
>--> >
>--> >--
>--> >Eric
>--> >
>--> >--> -----Original Message-----
>--> >--> From: [email-masked] 
>--> >--> [mailto:[email-masked]]On
>--> >--> Behalf Of Guillermo Ib??ez
>--> >--> Sent: Friday, October 21, 2005 2:33 AM
>--> >--> To: [email-masked]; Developing a hybrid router/bridge.
>--> >--> Subject: Re: [rbridge] RBridge/bridge interaction
>--> >--> 
>--> >--> 
>--> >--> 
>--> >--> I see the standard root election mechanism of spanning tree 
>--> >--> islands as 
>--> >--> the fastest and simpler mechanism for DR Rbridge 
>--> >--> designation. I see the 
>--> >--> DR Rbridge as being necessarily the ROOT bridge of  that 
>--> >--> sbridged cloud 
>--> >--> (or "link"). The root bridge of a standard spanning 
>--> tree is the 
>--> >--> "natural" source and sink point for the spanning tree.  To 
>--> >--> do so, the DR 
>--> >--> must issue BPDUs to become the root bridge.  This is 
>--> part of what I 
>--> >--> mentioned days ago as PARTICIPATE PER PORT, but may be we 
>--> >--> should call it 
>--> >--> SOURCE OR SINK (participate, do not forward BPDUs, only 
>--> >--> send own BPDUs 
>--> >--> to contend to be the root bridge of the link).
>--> >--> The consequence of this DR election mechanism is that 
>--> the priority 
>--> >--> configured at Rbridges as bridge ID would determine their 
>--> >--> also their 
>--> >--> election priority as DRs. I think this keep both domains 
>--> >--> coordinated 
>--> >--> with a single mechanism.
>--> >--> Guillermo
>--> >--> 
>--> >--> Radia Perlman wrote:
>--> >--> 
>--> >--> >I don't believe there should be options here.
>--> >--> >It should be plug and play.
>--> >--> >RBridges should BLOCK bridge spanning tree messages,
>--> >--> >and isolate the bridged islands.
>--> >--> >
>--> >--> >I absolutely do not understand what people are
>--> >--> >worried about with BLOCK.
>--> >--> >
>--> >--> >I suggest someone that actually thinks there is
>--> >--> >some reason to do anything other than drop
>--> >--> >spanning tree messages start a thread with
>--> >--> >a subject line
>--> >--> >"why it is good for RBridges to forward BPDUs",
>--> >--> >and very very carefully explain from scratch
>--> >--> >what the reasoning is. Not with a long
>--> >--> >email quoting pieces of other emails, but
>--> >--> >with a carefully crafted, from scratch explanation
>--> >--> >of what you perceive as a problem with BLOCk, and
>--> >--> >what the perceived benefit of ever having
>--> >--> >RBridges forwarding BPDUs would
>--> >--> >be.
>--> >--> >
>--> >--> >Oh...and there was a much earlier thread of the
>--> >--> >thread about other devices that might forward
>--> >--> >or drop BPDUs. There have always been things we
>--> >--> >referred to as "simple bridges" that forwarded spanning
>--> >--> >tree messages. I was careful to ensure that the
>--> >--> >spanning tree would work with such devices. Of course
>--> >--> >the spanning tree would not prevent a loop of all
>--> >--> >simple bridges, but if there was at least one spanning
>--> >--> >tree bridge in the middle of every possible loop, then
>--> >--> >there would wind up being no loops.
>--> >--> >
>--> >--> >You can think of "simple bridges" (ones that mindlessly
>--> >--> >forward BPDUs) as a layer below bridges. They are
>--> >--> >invisible to bridges. Bridges see a bunch of
>--> >--> >segments connected by simple bridges as a single segment.
>--> >--> >(Just like RBridges will see a bunch of segments connected
>--> >--> >by bridges as a single segment).
>--> >--> >
>--> >--> >Devices that drop BDPUs work if they are really
>--> >--> >layered on top of bridges, i.e., they let the
>--> >--> >bridges do their own thing to create isolated
>--> >--> >broadcast domains, and then these other devices do
>--> >--> >their own thing to glue these islands together.
>--> >--> >Like routers do. And like RBridges will do.
>--> >--> >
>--> >--> >Radia
>--> >--> >
>--> >--> >
>--> >--> >
>--> >--> >Guillermo Ib??ez wrote On 10/20/05 14:35,:
>--> >--> >  
>--> >--> >
>--> >--> >>Eric,
>--> >--> >>
>--> >--> >>
>--> >--> >>Gray, Eric wrote:
>--> >--> >>
>--> >--> >>
>--> >--> >>    
>--> >--> >>
>--> >--> >>>Guillermo,
>--> >--> >>>
>--> >--> >>>	During the discussion, the terms TRANSPARENT, 
>--> PARTICIPATE
>--> >--> >>>and BLOCK were used (often in upper-case, exactly 
>--> as I have used
>--> >--> >>>them here) as if these would ultimately be options 
>--> that might be
>--> >--> >>>supported - either as a complete set, or as some subset.  
>--> >--> >>>
>--> >--> >>>	For example, one argument was that TRANSPARENT 
>--> or PARTICIPATE 
>--> >--> >>>might be used, but BLOCK should not.
>--> >--> >>>
>--> >--> >>>	Also, at certain points in the discussion, 
>--> there was some
>--> >--> >>>thought that these might be modes that applied at 
>--> >--> different states
>--> >--> >>>during transitions in a network.
>--> >--> >>>
>--> >--> >>>	From a practical stand-point - however - it 
>--> would be best if
>--> >--> >>>we did not have to support all of these, either as 
>--> options, or as
>--> >--> >>>modes.  The mere fact that they were brought up 
>--> does not mean we
>--> >--> >>>are committed to including them.
>--> >--> >>>
>--> >--> >>>
>--> >--> >>>
>--> >--> >>>      
>--> >--> >>>
>--> >--> >>Agreed
>--> >--> >>
>--> >--> >>
>--> >--> >>    
>--> >--> >>
>--> >--> >>>	In particular, if we start talking about - for 
>--> instance -
>--> >--> >>>having a per-interface option for all of these 
>--> choices (and maybe
>--> >--> >>>others as well), then we either need to analyze 
>--> proposals for 
>--> >--> >>>architecture and design to ensure that the "right 
>--> things" will
>--> >--> >>>happen when an arbitrary combination of all of these 
>--> >--> options is in 
>--> >--> >>>effect, or we need to define caveats for network 
>--> >--> operators to avoid 
>--> >--> >>>specific combinations of options.  For example, we may 
>--> >--> need to say
>--> >--> >>>that the same option must be set throughout the network 
>--> >--> or this and
>--> >--> >>>that will (or may) happen.  That kind of design begs 
>--> >--> configuration
>--> >--> >>>errors to occur.
>--> >--> >>>
>--> >--> >>>
>--> >--> >>>
>--> >--> >>>      
>--> >--> >>>
>--> >--> >>If you refer as configuration options per interface to 
>--> >--> the PARTICIPATE 
>--> >--> >>PER PORT mode as an option per port, it is not the case. 
>--> >--> If  you refer 
>--> >--> >>to being the DR the root bridge of the sbridge domain, I 
>--> >--> think it must 
>--> >--> >>be analyzed as a real alternative, even if it is not 
>--> the default 
>--> >--> >>configuration.
>--> >--> >>
>--> >--> >>
>--> >--> >>    
>--> >--> >>
>--> >--> >>>	In this case, the fact that we want to make the 
>--> solution plug
>--> >--> >>>and play means that we can reduce the potential for 
>--> >--> disaster if we
>--> >--> >>>choose (and require) a specific default set of option 
>--> >--> choices.  If
>--> >--> >>>we can get away with it, however, we should simply 
>--> avoid options.
>--> >--> >>>
>--> >--> >>>
>--> >--> >>>
>--> >--> >>>      
>--> >--> >>>
>--> >--> >>Agreed, but not for the root bridge problem because is a 
>--> >--> real, practical 
>--> >--> >>issue.
>--> >--> >>
>--> >--> >>
>--> >--> >>    
>--> >--> >>
>--> >--> >>>	While having these same values as modes that 
>--> apply during 
>--> >--> >>>certain transitional states is cleaner, it would 
>--> require a well-
>--> >--> >>>defined finite state-machine (not a particular 
>--> problem) and a 
>--> >--> >>>genuine need for these behaviors under certain 
>--> circumstances.  It
>--> >--> >>>may well be the case that this turns out to be true.
>--> >--> >>>
>--> >--> >>>
>--> >--> >>>
>--> >--> >>>      
>--> >--> >>>
>--> >--> >>RSTP port state machines are there, may be they should be 
>--> >--> taken into 
>--> >--> >>consideration to make a consistent and integrated, but 
>--> >--> not interwoven, 
>--> >--> >>design for Rbridges that work with RSTP trees.
>--> >--> >>Guillermo. 
>--> >--> >>
>--> >--> >>
>--> >--> >>    
>--> >--> >>
>--> >--> >>>--
>--> >--> >>>Eric
>--> >--> >>>
>--> >--> >>>--> -----Original Message-----
>--> >--> >>>--> From: [email-masked] 
>--> >--> >>>--> [mailto:[email-masked]]On
>--> >--> >>>--> Behalf Of Guillermo Ib??ez
>--> >--> >>>--> Sent: Thursday, October 20, 2005 4:19 PM
>--> >--> >>>--> To: Developing a hybrid router/bridge.
>--> >--> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction
>--> >--> >>>--> 
>--> >--> >>>--> 
>--> >--> >>>--> I volunteer for some work on the capture, although my 
>--> >--> >>>--> english might be 
>--> >--> >>>--> not too understandable.  From what date should 
>--> the capture 
>--> >--> >>>--> to be done?
>--> >--> >>>--> 
>--> >--> >>>--> Regarding PARTICIPATE PER PORT:
>--> >--> >>>--> Although I do not have a clear position, and it 
>--> >--> requires detailed 
>--> >--> >>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
>--> >--> >>>--> better integrated 
>--> >--> >>>--> with spanning tree, while maintaining the basic 
>--> decoupling 
>--> >--> >>>--> that BLOCK 
>--> >--> >>>--> provides.
>--> >--> >>>--> With PARTICIPATE PER PORT it would be possible to 
>--> >--> force the elected 
>--> >--> >>>--> Rbridge to become the sbridge root of the 
>--> bridged domain by 
>--> >--> >>>--> modifying 
>--> >--> >>>--> its bridge priority when it gets elected as 
>--> Designated by 
>--> >--> >>>--> IS-IS (this 
>--> >--> >>>--> could be an optimization). In this way the path 
>--> length is 
>--> >--> >>>--> minimum  from 
>--> >--> >>>--> all bridges of bridged domain to the DR.
>--> >--> >>>-->  
>--> >--> >>>--> 
>--> >--> >>>--> Erik Nordmark wrote:
>--> >--> >>>--> 
>--> >--> >>>--> >We've had some useful discussion on this mailing list.
>--> >--> >>>--> >It would be good if somebody can capture the results 
>--> >--> >>>--> (perhaps as a long 
>--> >--> >>>--> >email) that we can fold into the draft(s) later. 
>--> >--> Any volunteers?
>--> >--> >>>--> >
>--> >--> >>>--> >I don't know if we will have additional issues in this 
>--> >--> >>>--> space or that it 
>--> >--> >>>--> >otherwise makes sense devoting agenda time to it in 
>--> >--> Vancouver.
>--> >--> >>>--> >
>--> >--> >>>--> >For instance, while I'm convinced that BLOCK works, I 
>--> >--> >>>--> wonder if there is 
>--> >--> >>>--> >something in PARTICIPATE PER PORT that can make the 
>--> >--> >>>--> interaction work better.
>--> >--> >>>--> >
>--> >--> >>>--> >Two cases to consider:
>--> >--> >>>--> >1. The elected forwarder dies and a new one 
>--> gets elected. 
>--> >--> >>>--> How quickly 
>--> >--> >>>--> >can packets sent by stations in the bridged cloud fail 
>--> >--> >>>--> over to go to the 
>--> >--> >>>--> >new elected forwarder?
>--> >--> >>>--> >
>--> >--> >>>--> >  
>--> >--> >>>--> >
>--> >--> >>>--> My understanding is that if the forwarded dies, the 
>--> >--> sbridge domain 
>--> >--> >>>--> should handle  it as  a topology change 
>--> >--> notification, tables   of 
>--> >--> >>>--> sbridges should be  flushed according to the 
>--> spanning tree 
>--> >--> >>>--> rules, so the 
>--> >--> >>>--> sbridge domain must know the DR will not 
>--> forward frames as 
>--> >--> >>>--> it used to. 
>--> >--> >>>--> It seems Rbridge shall issue a Topology Change 
>--> Notification 
>--> >--> >>>--> via sbridge 
>--> >--> >>>--> domain to flush MAC tables. Is a fast analysis, 
>--> probably I 
>--> >--> >>>--> miss details.
>--> >--> >>>-->  
>--> >--> >>>--> 
>--> >--> >>>--> >2. We have two separate bridged domains, each with 
>--> >--> their elected 
>--> >--> >>>--> >forwarder. Somebody connects the two bridged domains 
>--> >--> >>>--> together with a 
>--> >--> >>>--> >wire. This can cause a temporary loop until a single 
>--> >--> >>>--> elected forwarder 
>--> >--> >>>--> >is picked by the RBridges.
>--> >--> >>>--> >
>--> >--> >>>--> >  
>--> >--> >>>--> >
>--> >--> >>>--> In this case the PARTICIPATE PER PORT seems 
>--> superior, as 
>--> >--> >>>--> the two merged 
>--> >--> >>>--> bridged domains will merge their spanning trees 
>--> into one 
>--> >--> >>>--> and both DRs 
>--> >--> >>>--> will compete to be the root of the merged tree, this 
>--> >--> mechanism will 
>--> >--> >>>--> likely be faster (via RSTP fast transit to 
>--> forwarding state 
>--> >--> >>>--> over the 
>--> >--> >>>--> bridged domain)  than  Designation to select 
>--> the unique DR. 
>--> >--> >>>--> In other 
>--> >--> >>>--> words , the mechanism of root election in 
>--> sbridge could be 
>--> >--> >>>--> used to help 
>--> >--> >>>--> in DR designation and/or viceversa.
>--> >--> >>>--> So I see in PARTICIPATE PER PORT, some coupling 
>--> between DR 
>--> >--> >>>--> status and 
>--> >--> >>>--> root status of sbridge domain that can be used
>--> >--> >>>-->  to speed up convergence and coherence of both 
>--> domains. It 
>--> >--> >>>--> seems that 
>--> >--> >>>--> sbridge domains should be under the control of  
>--> >--> Rbridges, but the 
>--> >--> >>>--> sbridge mechanims should be used by Rbridges to keep 
>--> >--> the network 
>--> >--> >>>--> consistency and reconfiguration capabilities of RSTP.
>--> >--> >>>--> Guillermo
>--> >--> >>>--> 
>--> >--> >>>-->  
>--> >--> >>>--> _______________________________________________
>--> >--> >>>--> rbridge mailing list
>--> >--> >>>--> [email-masked]
>--> >--> >>>--> http://www.postel.org/mailman/listinfo/rbridge
>--> >--> >>>--> 
>--> >--> >>>_______________________________________________
>--> >--> >>>rbridge mailing list
>--> >--> >>>[email-masked]
>--> >--> >>>http://www.postel.org/mailman/listinfo/rbridge
>--> >--> >>>
>--> >--> >>>
>--> >--> >>>
>--> >--> >>>      
>--> >--> >>>
>--> >--> >>_______________________________________________
>--> >--> >>rbridge mailing list
>--> >--> >>[email-masked]
>--> >--> >>http://www.postel.org/mailman/listinfo/rbridge
>--> >--> >>    
>--> >--> >>
>--> >--> >
>--> >--> >_______________________________________________
>--> >--> >rbridge mailing list
>--> >--> >[email-masked]
>--> >--> >http://www.postel.org/mailman/listinfo/rbridge
>--> >--> >
>--> >--> >  
>--> >--> >
>--> >--> _______________________________________________
>--> >--> rbridge mailing list
>--> >--> [email-masked]
>--> >--> http://www.postel.org/mailman/listinfo/rbridge
>--> >--> 
>--> >_______________________________________________
>--> >rbridge mailing list
>--> >[email-masked]
>--> >http://www.postel.org/mailman/listinfo/rbridge
>--> >
>--> >  
>--> >
>--> _______________________________________________
>--> rbridge mailing list
>--> [email-masked]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 21 Oct 2005 16:09:24 -0300
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl	e
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1934

Peter,

	I can certainly add this as a separate subsection under 
section 3.  In my own mind (wherever I misplaced it), I do not
think there is a clear distinction between per-ingress and the
combination of per-ingress and per-VLAN, but not everybody is
going to think of VLAN IDs as part of a logical interface ID.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Peter Ashwood-Smith
--> Sent: Friday, October 21, 2005 10:47 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now
--> available
--> 
--> 
--> 
--> For completeness in section "3. Issues", there is of course the
--> possibility of
--> Per-ingress/Per VLAN spanning trees.
--> 
--> Peter
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> > [mailto:[email-masked]] On Behalf Of Gray, Eric
--> > Sent: Thursday, October 20, 2005 5:56 PM
--> > To: 'Developing a hybrid router/bridge.'
--> > Subject: [rbridge] R-Bridge Routing Requirements draft is now 
--> > available
--> > 
--> > 
--> > The draft "Routing Requirements in Support of R-Bridges" - 
--> > submitted last 
--> > Friday - is now available at:
--> > 
-->
http://www.ietf.org/internet-drafts/draft-gray-rbridge-routing-reqs-00.txt

This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt
and is very preliminary.  I am looking for input for the various
sections
- particularly those that currently only contain "TBD" :-)

This was one of the drafts that the working group felt would be required
at the last meeting.

--
Eric Gray
_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 21 Oct 2005 16:02:43 -0300
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now availabl	e
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2124

Peter,

	Thanks for the comment(s).  We can probably "argue" off-line
about what it means to be "easy to define" in the IETF.  Also, are
we definitely talking about IS-IS as run directly over L2?

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Peter Ashwood-Smith
--> Sent: Friday, October 21, 2005 10:29 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now
--> available
--> 
--> 
--> 
--> First comment:
--> 
--> "IS-IS is a more appropriate choice than OSPF in this case 
--> because it is
--> 
--> easy in IS-IS to define new TLVs for carrying new information"
--> 
--> I don't think its the new TLVs that are much of a problem, 
--> after all its
--> really a new protocol so we could tweak and extend without backward
--> compatibility worries. However the fact IS-IS runs directly over L2
--> is to me the big plus.
--> 
--> Peter
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> > [mailto:[email-masked]] On Behalf Of Gray, Eric
--> > Sent: Thursday, October 20, 2005 5:56 PM
--> > To: 'Developing a hybrid router/bridge.'
--> > Subject: [rbridge] R-Bridge Routing Requirements draft is now 
--> > available
--> > 
--> > 
--> > The draft "Routing Requirements in Support of R-Bridges" - 
--> > submitted last 
--> > Friday - is now available at:
--> > 
--> http://www.ietf.org/internet-drafts/draft-gray-rbridge-routi
ng-reqs-00.t
xt

This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt
and is very preliminary.  I am looking for input for the various
sections
- particularly those that currently only contain "TBD" :-)

This was one of the drafts that the working group felt would be required
at the last meeting.

--
Eric Gray
_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 21 Oct 2005 15:58:31 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4254

RBridge Folks,

	A way to look at the concept of a layer two device that
handles looping possibilities/concerns in some way other than 
by participating in STP - and is therefore not visible to STP
participants - is that it likely looks (to STP participants
- i.e. - 802/Ethernet bridges) like a single (possibly large)
bridged LAN segment. It is simply a link with a lot of MAC 
addresses on it. This is generally true for any device that 
lives in the Layer two world and is not an 802/Ethernet bridge, 
a host, or a router.

	In the RBridge case, there are two bridging scenarios to
consider: bridges between RBridges (or two, or more, interfaces 
of the same RBridge) and bridges attached to at most one RBridge 
interface.  We have loosely been referring to the former case as
"internal" bridges and the latter as "external" bridges, because 
of the assumption that RBridges merge into a single campus and
- therefore - having more than one RBridge interface on a single
bridged LAN segment puts that segment "inside" the campus.

	Consequently, we can assume that there are no stable back
connections between "external" bridged LAN segments because any 
such back connection will necessarily make affected "external" 
LAN segments "internal".

	For example, in the following simple network:

                            H1  H2 H3
                              \ | /
                               RB1
    H4 --.__                  /   \             __.-- H5
    H6 ----->-- B1 -- B2 -- RB2 -- RB3 -- B3 --<----- H7
    H8 ----^           |      \   /     ___|________
                      B4       \ /      |   |  |   |
                  _____|___    B5      L1  H9 H10 H11
                  |   |   |     |\
                 H12 H13  L2    | \
                              H14 H15

As shown, the LAN segment consisting of bridges B1, B2 and B4, hosts 
H4, H6, H8, H12 and H13, and currently unused link L2 are an external
bridged LAN segment.  The LAN segment consisting of bridge B3 and the
hosts H5, H7, H9, H10 and H11, and currently unused link L1 are also
an external bridged LAN segment.  The LAN segment consisting of bridge
B5 and hosts H14 and H15 is an internal bridged LAN segment, while 
hosts H1, H2 and H3 are on separate external LAN segments.

Connecting bridges B3 and B4, by connecting currently unused links L1
and L2 will make bridges B1-B4 and hosts H4-H13 all part of the same
_internal_ LAN segment.

Other things to note about this network, as is, if RBridges ignore STP:

o	to the RBridges, the network looks like this -

               H1  H2 H3
    H4 -+       |__|__|         +- H5
        |          |            |
    H6 -+         RB1           +- H7
        |        /   \          |
    H8 -+---- RB2 --- RB3 ------+- H9
        |        \___/          |
   H12 -+          |            +- H10
        |        __|__          |
   H13 -+        |   |          +- H11
                H14 H15

o	to bridges B1, B2 and B4, the network looks like this -

                           +------ H1
                           +- H2
                           +------ H3
    H4 -+                  +- H5
        |                  +------ H7
    H6 -+--- B1 -- B2 -----+- H9
        |           |      +------ H10
    H8 -+          B4      +- H11
                 ___|_     +------ H14
                 |   |     +- H15
                H12 H13

o	to bridge B3, the network looks like this - 
                           
    H1 ------+  
         H2 -+
    H3 ------+                +- H5
         H4 -+                |
    H6 ------+---- B3 --------+- H7
         H8 -+   ___|_____
   H12 ------+   |   |   |
        H13 -+   H9 H10 H11
   H14 ------+ 
        H15 -+

o	because B5 is on an internal LAN segment, its view of host 
and RBridge MAC addresses will be - at least in part - determined
by shortest path (spanning tree) computation; it might, for example
see the network like this (B5 rotated 45 degrees CCW) - 

    H1 ------+      +---------+------ H2         
         H4 -+      |         +- H3
    H6 ------+----- B5 --+    +------ H5
         H8 -+      |    |    +- H7
   H12 ------+      |    |    +------ H9
        H13 -+     H14  H15   +- H10
                              +------ H11

--
Eric Gray

From: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 21 Oct 2005 19:49:43 +0200
Importance: Normal
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 17647

My doubt is whether the DR Designation procedure is fast and reliable enough
for reconfigurations of the islands communicating the Rbridges. Using the DR
Rbridge as root bridge and linking the DR Designated role of Rbridge to the
role of root bridge  of the link, the root bridge election at the link
could be used also as a faster and reliable mechanism for DR designation, as
in fact the function is rather similar (although new: never a root bridge
had Root port to forward and receive packets). It may sound complicated, I
think in the long term it may be more complicated for Rbridges to be DRs of
a link that they do not control.
Guillermo 

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre
de Gray, Eric
Enviado el: viernes, 21 de octubre de 2005 19:07
Para: 'Developing a hybrid router/bridge.'
Asunto: Re: [rbridge] RBridge/bridge interaction

Guillermo,

	I had to think about what Radia was saying to realize
that she is not objecting to merging one RBridge campus with another.  If I
understand correctly, what she is referring 
to is merging spanning trees between two islands (or pockets) of
802/Ethernet bridges separated by a R-Bridge campus.

	There's nothing to resolve, if the RBridge campus does 
not participate in STP, or transparently pass it through the campus from one
island to another.

	So, I suspect that we are not looking for a way to solve
the problem, since there is a way to avoid it.

--
Eric Gray

--> -----Original Message-----
--> From: [email-masked]
--> [mailto:[email-masked]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Friday, October 21, 2005 8:14 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> 
--> 
--> Radia Perlman wrote:
--> 
--> >I don't think there's any reason, even if most of the
--> traffic on the
--> >link comes from the DR, for the
--> >DR to be the root of the spanning tree.
--> >What would be bad is if an RBridge, participating in two bridged
--> >islands, winds up merging
--> >the islands into a bigger island.
--> >  
--> >
--> Good point, but I think it can be solved.
--> The merging of islands can be prevented if the RBridge
--> acting as root 
--> limits to one port maximum in the Designated Port Role of 
--> spanning tree 
--> for sbridges.
--> 
--> >The whole point is to make the bridged islands as small as
--> possible, so
--> >most forwarding is done
--> >protected by hop count, and with optimal routes.
--> >
--> >  
--> >
--> I'll admit that having RBridges *initiate* BPDUs
--> 
--> >to vie for being Root is not as harmful as having them
--> *forward* BPDUs
--> >between
--> >bridged islands (provided an RBridge is careful not to
--> merge two islands
--> >that would
--> >have been separate if the RBridge had just been blocking BPDUs).
--> >
--> >We shouldn't make things more complex in an attempt to
--> come up with a
--> >"more optimal"
--> >spanning tree within the bridged islands.
--> >  
--> >
--> 
--> >With a bidirectional tree, as happens with bridges,
--> there's nothing
--> >special about the Root.
--> >Also, the traffic pattern might be such that most of the
--> traffic is
--> >between endnodes within
--> >the island.
--> >
--> With the client server model, dominant traffic is to and
--> from the core 
--> layer of campus network, so I think most of the traffic will flow 
--> from/into Rbridge, not withing the islands.
--> 
--> >So there's really no reason to believe that having the
--> >RBridge DR be the
--> >spanning tree Root will result in better performance. And 
--> is certainly
--> >complicates things.
--> >And it also certainly is dangerous because of the
--> potential of merging
--> >islands.
--> >
--> >  
--> >
--> I do not think is dangerous. The merging of islands is not
--> convenient, 
--> but it can be prevented, limiting to one port the 
--> Designated Role in the 
--> root Rbridge.
--> Guillermo
--> 
--> >Radia
--> >
--> >
--> >
--> >Guillermo Ib??ez wrote:
--> >
--> >  
--> >
--> >>I see the standard root election mechanism of spanning
--> tree islands as
--> >>the fastest and simpler mechanism for DR Rbridge
--> designation. I see the
--> >>DR Rbridge as being necessarily the ROOT bridge of  that
--> sbridged cloud
--> >>(or "link"). The root bridge of a standard spanning tree is the
--> >>"natural" source and sink point for the spanning tree.  
--> To do so, the DR
--> >>must issue BPDUs to become the root bridge.  This is part
--> of what I
--> >>mentioned days ago as PARTICIPATE PER PORT, but may be we
--> should call it
--> >>SOURCE OR SINK (participate, do not forward BPDUs, only
--> send own BPDUs
--> >>to contend to be the root bridge of the link).
--> >>The consequence of this DR election mechanism is that the
--> priority
--> >>configured at Rbridges as bridge ID would determine their
--> also their
--> >>election priority as DRs. I think this keep both domains
--> coordinated
--> >>with a single mechanism.
--> >>Guillermo
--> >>
--> >>Radia Perlman wrote:
--> >>
--> >> 
--> >>
--> >>    
--> >>
--> >>>I don't believe there should be options here.
--> >>>It should be plug and play.
--> >>>RBridges should BLOCK bridge spanning tree messages,
--> >>>and isolate the bridged islands.
--> >>>
--> >>>I absolutely do not understand what people are
--> >>>worried about with BLOCK.
--> >>>
--> >>>I suggest someone that actually thinks there is
--> >>>some reason to do anything other than drop
--> >>>spanning tree messages start a thread with
--> >>>a subject line
--> >>>"why it is good for RBridges to forward BPDUs",
--> >>>and very very carefully explain from scratch
--> >>>what the reasoning is. Not with a long
--> >>>email quoting pieces of other emails, but
--> >>>with a carefully crafted, from scratch explanation
--> >>>of what you perceive as a problem with BLOCk, and
--> >>>what the perceived benefit of ever having
--> >>>RBridges forwarding BPDUs would
--> >>>be.
--> >>>
--> >>>Oh...and there was a much earlier thread of the
--> >>>thread about other devices that might forward
--> >>>or drop BPDUs. There have always been things we
--> >>>referred to as "simple bridges" that forwarded spanning tree 
--> >>>messages. I was careful to ensure that the spanning tree would 
--> >>>work with such devices. Of course the spanning tree would not 
--> >>>prevent a loop of all simple bridges, but if there was at least 
--> >>>one spanning tree bridge in the middle of every possible loop, 
--> >>>then there would wind up being no loops.
--> >>>
--> >>>You can think of "simple bridges" (ones that mindlessly forward 
--> >>>BPDUs) as a layer below bridges. They are invisible to bridges. 
--> >>>Bridges see a bunch of segments connected by simple bridges as a 
--> >>>single segment. (Just like RBridges will see a bunch of segments 
--> >>>connected by bridges as a single segment).
--> >>>
--> >>>Devices that drop BDPUs work if they are really
--> >>>layered on top of bridges, i.e., they let the
--> >>>bridges do their own thing to create isolated
--> >>>broadcast domains, and then these other devices do
--> >>>their own thing to glue these islands together.
--> >>>Like routers do. And like RBridges will do.
--> >>>
--> >>>Radia
--> >>>
--> >>>
--> >>>
--> >>>Guillermo Ib??ez wrote On 10/20/05 14:35,:
--> >>>
--> >>>
--> >>>   
--> >>>
--> >>>      
--> >>>
--> >>>>Eric,
--> >>>>
--> >>>>
--> >>>>Gray, Eric wrote:
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>Guillermo,
--> >>>>>
--> >>>>>	During the discussion, the terms TRANSPARENT,
--> PARTICIPATE
--> >>>>>and BLOCK were used (often in upper-case, exactly as I
--> have used
--> >>>>>them here) as if these would ultimately be options
--> that might be
--> >>>>>supported - either as a complete set, or as some subset.
--> >>>>>
--> >>>>>	For example, one argument was that TRANSPARENT
--> or PARTICIPATE
--> >>>>>might be used, but BLOCK should not.
--> >>>>>
--> >>>>>	Also, at certain points in the discussion,
--> there was some
--> >>>>>thought that these might be modes that applied at
--> different states
--> >>>>>during transitions in a network.
--> >>>>>
--> >>>>>	From a practical stand-point - however - it
--> would be best if
--> >>>>>we did not have to support all of these, either as
--> options, or as
--> >>>>>modes.  The mere fact that they were brought up does
--> not mean we
--> >>>>>are committed to including them.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>Agreed
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>	In particular, if we start talking about - for
--> instance -
--> >>>>>having a per-interface option for all of these choices
--> (and maybe
--> >>>>>others as well), then we either need to analyze proposals for
--> >>>>>architecture and design to ensure that the "right things" will
--> >>>>>happen when an arbitrary combination of all of these 
--> options is in
--> >>>>>effect, or we need to define caveats for network
--> operators to avoid
--> >>>>>specific combinations of options.  For example, we may
--> need to say
--> >>>>>that the same option must be set throughout the
--> network or this and
--> >>>>>that will (or may) happen.  That kind of design begs
--> configuration
--> >>>>>errors to occur.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>If you refer as configuration options per interface to
--> the PARTICIPATE
--> >>>>PER PORT mode as an option per port, it is not the
--> case. If  you refer
--> >>>>to being the DR the root bridge of the sbridge domain,
--> I think it must
--> >>>>be analyzed as a real alternative, even if it is not
--> the default
--> >>>>configuration.
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>	In this case, the fact that we want to make the
--> solution plug
--> >>>>>and play means that we can reduce the potential for
--> disaster if we
--> >>>>>choose (and require) a specific default set of option
--> choices.  If
--> >>>>>we can get away with it, however, we should simply
--> avoid options.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>Agreed, but not for the root bridge problem because is
--> a real, practical
--> >>>>issue.
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>	While having these same values as modes that
--> apply during
--> >>>>>certain transitional states is cleaner, it would
--> require a well-
--> >>>>>defined finite state-machine (not a particular problem) and a
--> >>>>>genuine need for these behaviors under certain 
--> circumstances.  It
--> >>>>>may well be the case that this turns out to be true.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>RSTP port state machines are there, may be they should
--> be taken into
--> >>>>consideration to make a consistent and integrated, but
--> not interwoven,
--> >>>>design for Rbridges that work with RSTP trees. Guillermo.
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>--
--> >>>>>Eric
--> >>>>>
--> >>>>>--> -----Original Message-----
--> >>>>>--> From: [email-masked] 
--> >>>>>--> [mailto:[email-masked]]On
--> >>>>>--> Behalf Of Guillermo Ib??ez
--> >>>>>--> Sent: Thursday, October 20, 2005 4:19 PM
--> >>>>>--> To: Developing a hybrid router/bridge.
--> >>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction
--> >>>>>--> 
--> >>>>>--> 
--> >>>>>--> I volunteer for some work on the capture, although my 
--> >>>>>--> english might be 
--> >>>>>--> not too understandable.  From what date should the capture 
--> >>>>>--> to be done?
--> >>>>>--> 
--> >>>>>--> Regarding PARTICIPATE PER PORT:
--> >>>>>--> Although I do not have a clear position, and it 
--> requires detailed 
--> >>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
--> >>>>>--> better integrated 
--> >>>>>--> with spanning tree, while maintaining the basic decoupling 
--> >>>>>--> that BLOCK 
--> >>>>>--> provides.
--> >>>>>--> With PARTICIPATE PER PORT it would be possible to 
--> force the elected 
--> >>>>>--> Rbridge to become the sbridge root of the bridged 
--> domain by 
--> >>>>>--> modifying 
--> >>>>>--> its bridge priority when it gets elected as Designated by 
--> >>>>>--> IS-IS (this 
--> >>>>>--> could be an optimization). In this way the path length is 
--> >>>>>--> minimum  from 
--> >>>>>--> all bridges of bridged domain to the DR.
--> >>>>>-->  
--> >>>>>--> 
--> >>>>>--> Erik Nordmark wrote:
--> >>>>>--> 
--> >>>>>--> >We've had some useful discussion on this mailing list.
--> >>>>>--> >It would be good if somebody can capture the results 
--> >>>>>--> (perhaps as a long 
--> >>>>>--> >email) that we can fold into the draft(s) later. 
--> Any volunteers?
--> >>>>>--> >
--> >>>>>--> >I don't know if we will have additional issues in this 
--> >>>>>--> space or that it 
--> >>>>>--> >otherwise makes sense devoting agenda time to it 
--> in Vancouver.
--> >>>>>--> >
--> >>>>>--> >For instance, while I'm convinced that BLOCK works, I 
--> >>>>>--> wonder if there is 
--> >>>>>--> >something in PARTICIPATE PER PORT that can make the 
--> >>>>>--> interaction work better.
--> >>>>>--> >
--> >>>>>--> >Two cases to consider:
--> >>>>>--> >1. The elected forwarder dies and a new one gets elected. 
--> >>>>>--> How quickly 
--> >>>>>--> >can packets sent by stations in the bridged cloud fail 
--> >>>>>--> over to go to the 
--> >>>>>--> >new elected forwarder?
--> >>>>>--> >
--> >>>>>--> >  
--> >>>>>--> >
--> >>>>>--> My understanding is that if the forwarded dies, 
--> the sbridge domain 
--> >>>>>--> should handle  it as  a topology change 
--> notification, tables   of 
--> >>>>>--> sbridges should be  flushed according to the spanning tree 
--> >>>>>--> rules, so the 
--> >>>>>--> sbridge domain must know the DR will not forward frames as 
--> >>>>>--> it used to. 
--> >>>>>--> It seems Rbridge shall issue a Topology Change 
--> Notification 
--> >>>>>--> via sbridge 
--> >>>>>--> domain to flush MAC tables. Is a fast analysis, probably I 
--> >>>>>--> miss details.
--> >>>>>-->  
--> >>>>>--> 
--> >>>>>--> >2. We have two separate bridged domains, each 
--> with their elected 
--> >>>>>--> >forwarder. Somebody connects the two bridged domains 
--> >>>>>--> together with a 
--> >>>>>--> >wire. This can cause a temporary loop until a single 
--> >>>>>--> elected forwarder 
--> >>>>>--> >is picked by the RBridges.
--> >>>>>--> >
--> >>>>>--> >  
--> >>>>>--> >
--> >>>>>--> In this case the PARTICIPATE PER PORT seems superior, as 
--> >>>>>--> the two merged 
--> >>>>>--> bridged domains will merge their spanning trees into one 
--> >>>>>--> and both DRs 
--> >>>>>--> will compete to be the root of the merged tree, 
--> this mechanism will 
--> >>>>>--> likely be faster (via RSTP fast transit to 
--> forwarding state 
--> >>>>>--> over the 
--> >>>>>--> bridged domain)  than  Designation to select the 
--> unique DR. 
--> >>>>>--> In other 
--> >>>>>--> words , the mechanism of root election in sbridge could be 
--> >>>>>--> used to help 
--> >>>>>--> in DR designation and/or viceversa.
--> >>>>>--> So I see in PARTICIPATE PER PORT, some coupling between DR 
--> >>>>>--> status and 
--> >>>>>--> root status of sbridge domain that can be used
--> >>>>>-->  to speed up convergence and coherence of both domains. It 
--> >>>>>--> seems that 
--> >>>>>--> sbridge domains should be under the control of  
--> Rbridges, but the 
--> >>>>>--> sbridge mechanims should be used by Rbridges to 
--> keep the network 
--> >>>>>--> consistency and reconfiguration capabilities of RSTP.
--> >>>>>--> Guillermo
--> >>>>>--> 
--> >>>>>-->  
--> >>>>>--> _______________________________________________
--> >>>>>--> rbridge mailing list
--> >>>>>--> [email-masked]
--> >>>>>--> http://www.postel.org/mailman/listinfo/rbridge
--> >>>>>--> 
--> >>>>>_______________________________________________
--> >>>>>rbridge mailing list
--> >>>>>[email-masked]
--> >>>>>http://www.postel.org/mailman/listinfo/rbridge
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>_______________________________________________
--> >>>>rbridge mailing list
--> >>>>[email-masked]
--> >>>>http://www.postel.org/mailman/listinfo/rbridge
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>_______________________________________________
--> >>>rbridge mailing list
--> >>>[email-masked]
--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >>>
--> >>>
--> >>>
--> >>>   
--> >>>
--> >>>      
--> >>>
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[email-masked]
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> >> 
--> >>
--> >>    
--> >>
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >
--> >  
--> >
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 
_______________________________________________
rbridge mailing list
[email-masked]
http://www.postel.org/mailman/listinfo/rbridge

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 21 Oct 2005 14:19:00 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 16472

Guillermo,

	I think the point is that coordination between bridges
and RBridges means at least RBridges have to be aware of the
bridges.  I say this because having bridges be aware of the
RBridges - at least as RBridges - is not an option.

	Having even the RBridges being necessarily aware of all
bridges is unnecessary and would therefore add complexity to
RBridges.  If you would like to make the point that the root
election process is not complicated, first I would disagree 
(because - minimally - it adds complexity to a configuration 
process, which is something we're trying to avoid) and second
I would point out that any complexity that is unecessary is a
complication that should be avoided.

	The processes of IS-IS and multicast DR election are, of
course, completely independent of the existence of bridges.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Friday, October 21, 2005 8:26 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> I agree suboptimality is not the key issue, but 
--> coordination between STP 
--> and RBridges  regarding DR election (faster DR election 
--> IMMO, although I 
--> know nothing about IS-IS DR election) . Path optimization is a plus.
--> Guillermo
--> 
--> Gray, Eric wrote:
--> 
--> >Guillermo,
--> >
--> >	Actually, the thing about a spanning tree is that 
--> frames entering
--> >the tree will reach every node.  Hence the result of 
--> having an RBridge
--> >be something other than the root of the local spanning 
--> tree would be 
--> >that frame delivery might be sub-optimal.  In fact, it is not even
--> >necessary for the R-Bridge to be directly connected to the 
--> root of a
--> >local spanning tree.
--> >
--> >	That's part of the reason why an RBridge does not need to be a
--> >part of the local STP.
--> >
--> >	Given the way that spanning tree works in general, sub-optimal 
--> >delivery of frames would not be something new.  Having th
--> >
--> >--
--> >Eric
--> >
--> >--> -----Original Message-----
--> >--> From: [email-masked] 
--> >--> [mailto:[email-masked]]On
--> >--> Behalf Of Guillermo Ib??ez
--> >--> Sent: Friday, October 21, 2005 2:33 AM
--> >--> To: [email-masked]; Developing a hybrid router/bridge.
--> >--> Subject: Re: [rbridge] RBridge/bridge interaction
--> >--> 
--> >--> 
--> >--> 
--> >--> I see the standard root election mechanism of spanning tree 
--> >--> islands as 
--> >--> the fastest and simpler mechanism for DR Rbridge 
--> >--> designation. I see the 
--> >--> DR Rbridge as being necessarily the ROOT bridge of  that 
--> >--> sbridged cloud 
--> >--> (or "link"). The root bridge of a standard spanning 
--> tree is the 
--> >--> "natural" source and sink point for the spanning tree.  To 
--> >--> do so, the DR 
--> >--> must issue BPDUs to become the root bridge.  This is 
--> part of what I 
--> >--> mentioned days ago as PARTICIPATE PER PORT, but may be we 
--> >--> should call it 
--> >--> SOURCE OR SINK (participate, do not forward BPDUs, only 
--> >--> send own BPDUs 
--> >--> to contend to be the root bridge of the link).
--> >--> The consequence of this DR election mechanism is that 
--> the priority 
--> >--> configured at Rbridges as bridge ID would determine their 
--> >--> also their 
--> >--> election priority as DRs. I think this keep both domains 
--> >--> coordinated 
--> >--> with a single mechanism.
--> >--> Guillermo
--> >--> 
--> >--> Radia Perlman wrote:
--> >--> 
--> >--> >I don't believe there should be options here.
--> >--> >It should be plug and play.
--> >--> >RBridges should BLOCK bridge spanning tree messages,
--> >--> >and isolate the bridged islands.
--> >--> >
--> >--> >I absolutely do not understand what people are
--> >--> >worried about with BLOCK.
--> >--> >
--> >--> >I suggest someone that actually thinks there is
--> >--> >some reason to do anything other than drop
--> >--> >spanning tree messages start a thread with
--> >--> >a subject line
--> >--> >"why it is good for RBridges to forward BPDUs",
--> >--> >and very very carefully explain from scratch
--> >--> >what the reasoning is. Not with a long
--> >--> >email quoting pieces of other emails, but
--> >--> >with a carefully crafted, from scratch explanation
--> >--> >of what you perceive as a problem with BLOCk, and
--> >--> >what the perceived benefit of ever having
--> >--> >RBridges forwarding BPDUs would
--> >--> >be.
--> >--> >
--> >--> >Oh...and there was a much earlier thread of the
--> >--> >thread about other devices that might forward
--> >--> >or drop BPDUs. There have always been things we
--> >--> >referred to as "simple bridges" that forwarded spanning
--> >--> >tree messages. I was careful to ensure that the
--> >--> >spanning tree would work with such devices. Of course
--> >--> >the spanning tree would not prevent a loop of all
--> >--> >simple bridges, but if there was at least one spanning
--> >--> >tree bridge in the middle of every possible loop, then
--> >--> >there would wind up being no loops.
--> >--> >
--> >--> >You can think of "simple bridges" (ones that mindlessly
--> >--> >forward BPDUs) as a layer below bridges. They are
--> >--> >invisible to bridges. Bridges see a bunch of
--> >--> >segments connected by simple bridges as a single segment.
--> >--> >(Just like RBridges will see a bunch of segments connected
--> >--> >by bridges as a single segment).
--> >--> >
--> >--> >Devices that drop BDPUs work if they are really
--> >--> >layered on top of bridges, i.e., they let the
--> >--> >bridges do their own thing to create isolated
--> >--> >broadcast domains, and then these other devices do
--> >--> >their own thing to glue these islands together.
--> >--> >Like routers do. And like RBridges will do.
--> >--> >
--> >--> >Radia
--> >--> >
--> >--> >
--> >--> >
--> >--> >Guillermo Ib??ez wrote On 10/20/05 14:35,:
--> >--> >  
--> >--> >
--> >--> >>Eric,
--> >--> >>
--> >--> >>
--> >--> >>Gray, Eric wrote:
--> >--> >>
--> >--> >>
--> >--> >>    
--> >--> >>
--> >--> >>>Guillermo,
--> >--> >>>
--> >--> >>>	During the discussion, the terms TRANSPARENT, 
--> PARTICIPATE
--> >--> >>>and BLOCK were used (often in upper-case, exactly 
--> as I have used
--> >--> >>>them here) as if these would ultimately be options 
--> that might be
--> >--> >>>supported - either as a complete set, or as some subset.  
--> >--> >>>
--> >--> >>>	For example, one argument was that TRANSPARENT 
--> or PARTICIPATE 
--> >--> >>>might be used, but BLOCK should not.
--> >--> >>>
--> >--> >>>	Also, at certain points in the discussion, 
--> there was some
--> >--> >>>thought that these might be modes that applied at 
--> >--> different states
--> >--> >>>during transitions in a network.
--> >--> >>>
--> >--> >>>	From a practical stand-point - however - it 
--> would be best if
--> >--> >>>we did not have to support all of these, either as 
--> options, or as
--> >--> >>>modes.  The mere fact that they were brought up 
--> does not mean we
--> >--> >>>are committed to including them.
--> >--> >>>
--> >--> >>>
--> >--> >>>
--> >--> >>>      
--> >--> >>>
--> >--> >>Agreed
--> >--> >>
--> >--> >>
--> >--> >>    
--> >--> >>
--> >--> >>>	In particular, if we start talking about - for 
--> instance -
--> >--> >>>having a per-interface option for all of these 
--> choices (and maybe
--> >--> >>>others as well), then we either need to analyze 
--> proposals for 
--> >--> >>>architecture and design to ensure that the "right 
--> things" will
--> >--> >>>happen when an arbitrary combination of all of these 
--> >--> options is in 
--> >--> >>>effect, or we need to define caveats for network 
--> >--> operators to avoid 
--> >--> >>>specific combinations of options.  For example, we may 
--> >--> need to say
--> >--> >>>that the same option must be set throughout the network 
--> >--> or this and
--> >--> >>>that will (or may) happen.  That kind of design begs 
--> >--> configuration
--> >--> >>>errors to occur.
--> >--> >>>
--> >--> >>>
--> >--> >>>
--> >--> >>>      
--> >--> >>>
--> >--> >>If you refer as configuration options per interface to 
--> >--> the PARTICIPATE 
--> >--> >>PER PORT mode as an option per port, it is not the case. 
--> >--> If  you refer 
--> >--> >>to being the DR the root bridge of the sbridge domain, I 
--> >--> think it must 
--> >--> >>be analyzed as a real alternative, even if it is not 
--> the default 
--> >--> >>configuration.
--> >--> >>
--> >--> >>
--> >--> >>    
--> >--> >>
--> >--> >>>	In this case, the fact that we want to make the 
--> solution plug
--> >--> >>>and play means that we can reduce the potential for 
--> >--> disaster if we
--> >--> >>>choose (and require) a specific default set of option 
--> >--> choices.  If
--> >--> >>>we can get away with it, however, we should simply 
--> avoid options.
--> >--> >>>
--> >--> >>>
--> >--> >>>
--> >--> >>>      
--> >--> >>>
--> >--> >>Agreed, but not for the root bridge problem because is a 
--> >--> real, practical 
--> >--> >>issue.
--> >--> >>
--> >--> >>
--> >--> >>    
--> >--> >>
--> >--> >>>	While having these same values as modes that 
--> apply during 
--> >--> >>>certain transitional states is cleaner, it would 
--> require a well-
--> >--> >>>defined finite state-machine (not a particular 
--> problem) and a 
--> >--> >>>genuine need for these behaviors under certain 
--> circumstances.  It
--> >--> >>>may well be the case that this turns out to be true.
--> >--> >>>
--> >--> >>>
--> >--> >>>
--> >--> >>>      
--> >--> >>>
--> >--> >>RSTP port state machines are there, may be they should be 
--> >--> taken into 
--> >--> >>consideration to make a consistent and integrated, but 
--> >--> not interwoven, 
--> >--> >>design for Rbridges that work with RSTP trees.
--> >--> >>Guillermo. 
--> >--> >>
--> >--> >>
--> >--> >>    
--> >--> >>
--> >--> >>>--
--> >--> >>>Eric
--> >--> >>>
--> >--> >>>--> -----Original Message-----
--> >--> >>>--> From: [email-masked] 
--> >--> >>>--> [mailto:[email-masked]]On
--> >--> >>>--> Behalf Of Guillermo Ib??ez
--> >--> >>>--> Sent: Thursday, October 20, 2005 4:19 PM
--> >--> >>>--> To: Developing a hybrid router/bridge.
--> >--> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction
--> >--> >>>--> 
--> >--> >>>--> 
--> >--> >>>--> I volunteer for some work on the capture, although my 
--> >--> >>>--> english might be 
--> >--> >>>--> not too understandable.  From what date should 
--> the capture 
--> >--> >>>--> to be done?
--> >--> >>>--> 
--> >--> >>>--> Regarding PARTICIPATE PER PORT:
--> >--> >>>--> Although I do not have a clear position, and it 
--> >--> requires detailed 
--> >--> >>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
--> >--> >>>--> better integrated 
--> >--> >>>--> with spanning tree, while maintaining the basic 
--> decoupling 
--> >--> >>>--> that BLOCK 
--> >--> >>>--> provides.
--> >--> >>>--> With PARTICIPATE PER PORT it would be possible to 
--> >--> force the elected 
--> >--> >>>--> Rbridge to become the sbridge root of the 
--> bridged domain by 
--> >--> >>>--> modifying 
--> >--> >>>--> its bridge priority when it gets elected as 
--> Designated by 
--> >--> >>>--> IS-IS (this 
--> >--> >>>--> could be an optimization). In this way the path 
--> length is 
--> >--> >>>--> minimum  from 
--> >--> >>>--> all bridges of bridged domain to the DR.
--> >--> >>>-->  
--> >--> >>>--> 
--> >--> >>>--> Erik Nordmark wrote:
--> >--> >>>--> 
--> >--> >>>--> >We've had some useful discussion on this mailing list.
--> >--> >>>--> >It would be good if somebody can capture the results 
--> >--> >>>--> (perhaps as a long 
--> >--> >>>--> >email) that we can fold into the draft(s) later. 
--> >--> Any volunteers?
--> >--> >>>--> >
--> >--> >>>--> >I don't know if we will have additional issues in this 
--> >--> >>>--> space or that it 
--> >--> >>>--> >otherwise makes sense devoting agenda time to it in 
--> >--> Vancouver.
--> >--> >>>--> >
--> >--> >>>--> >For instance, while I'm convinced that BLOCK works, I 
--> >--> >>>--> wonder if there is 
--> >--> >>>--> >something in PARTICIPATE PER PORT that can make the 
--> >--> >>>--> interaction work better.
--> >--> >>>--> >
--> >--> >>>--> >Two cases to consider:
--> >--> >>>--> >1. The elected forwarder dies and a new one 
--> gets elected. 
--> >--> >>>--> How quickly 
--> >--> >>>--> >can packets sent by stations in the bridged cloud fail 
--> >--> >>>--> over to go to the 
--> >--> >>>--> >new elected forwarder?
--> >--> >>>--> >
--> >--> >>>--> >  
--> >--> >>>--> >
--> >--> >>>--> My understanding is that if the forwarded dies, the 
--> >--> sbridge domain 
--> >--> >>>--> should handle  it as  a topology change 
--> >--> notification, tables   of 
--> >--> >>>--> sbridges should be  flushed according to the 
--> spanning tree 
--> >--> >>>--> rules, so the 
--> >--> >>>--> sbridge domain must know the DR will not 
--> forward frames as 
--> >--> >>>--> it used to. 
--> >--> >>>--> It seems Rbridge shall issue a Topology Change 
--> Notification 
--> >--> >>>--> via sbridge 
--> >--> >>>--> domain to flush MAC tables. Is a fast analysis, 
--> probably I 
--> >--> >>>--> miss details.
--> >--> >>>-->  
--> >--> >>>--> 
--> >--> >>>--> >2. We have two separate bridged domains, each with 
--> >--> their elected 
--> >--> >>>--> >forwarder. Somebody connects the two bridged domains 
--> >--> >>>--> together with a 
--> >--> >>>--> >wire. This can cause a temporary loop until a single 
--> >--> >>>--> elected forwarder 
--> >--> >>>--> >is picked by the RBridges.
--> >--> >>>--> >
--> >--> >>>--> >  
--> >--> >>>--> >
--> >--> >>>--> In this case the PARTICIPATE PER PORT seems 
--> superior, as 
--> >--> >>>--> the two merged 
--> >--> >>>--> bridged domains will merge their spanning trees 
--> into one 
--> >--> >>>--> and both DRs 
--> >--> >>>--> will compete to be the root of the merged tree, this 
--> >--> mechanism will 
--> >--> >>>--> likely be faster (via RSTP fast transit to 
--> forwarding state 
--> >--> >>>--> over the 
--> >--> >>>--> bridged domain)  than  Designation to select 
--> the unique DR. 
--> >--> >>>--> In other 
--> >--> >>>--> words , the mechanism of root election in 
--> sbridge could be 
--> >--> >>>--> used to help 
--> >--> >>>--> in DR designation and/or viceversa.
--> >--> >>>--> So I see in PARTICIPATE PER PORT, some coupling 
--> between DR 
--> >--> >>>--> status and 
--> >--> >>>--> root status of sbridge domain that can be used
--> >--> >>>-->  to speed up convergence and coherence of both 
--> domains. It 
--> >--> >>>--> seems that 
--> >--> >>>--> sbridge domains should be under the control of  
--> >--> Rbridges, but the 
--> >--> >>>--> sbridge mechanims should be used by Rbridges to keep 
--> >--> the network 
--> >--> >>>--> consistency and reconfiguration capabilities of RSTP.
--> >--> >>>--> Guillermo
--> >--> >>>--> 
--> >--> >>>-->  
--> >--> >>>--> _______________________________________________
--> >--> >>>--> rbridge mailing list
--> >--> >>>--> [email-masked]
--> >--> >>>--> http://www.postel.org/mailman/listinfo/rbridge
--> >--> >>>--> 
--> >--> >>>_______________________________________________
--> >--> >>>rbridge mailing list
--> >--> >>>[email-masked]
--> >--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >--> >>>
--> >--> >>>
--> >--> >>>
--> >--> >>>      
--> >--> >>>
--> >--> >>_______________________________________________
--> >--> >>rbridge mailing list
--> >--> >>[email-masked]
--> >--> >>http://www.postel.org/mailman/listinfo/rbridge
--> >--> >>    
--> >--> >>
--> >--> >
--> >--> >_______________________________________________
--> >--> >rbridge mailing list
--> >--> >[email-masked]
--> >--> >http://www.postel.org/mailman/listinfo/rbridge
--> >--> >
--> >--> >  
--> >--> >
--> >--> _______________________________________________
--> >--> rbridge mailing list
--> >--> [email-masked]
--> >--> http://www.postel.org/mailman/listinfo/rbridge
--> >--> 
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >
--> >  
--> >
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 21 Oct 2005 14:06:49 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 16703

Guillermo,

	I had to think about what Radia was saying to realize
that she is not objecting to merging one RBridge campus with
another.  If I understand correctly, what she is referring 
to is merging spanning trees between two islands (or pockets)
of 802/Ethernet bridges separated by a R-Bridge campus.

	There's nothing to resolve, if the RBridge campus does 
not participate in STP, or transparently pass it through the
campus from one island to another.

	So, I suspect that we are not looking for a way to solve
the problem, since there is a way to avoid it.

--
Eric Gray

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Friday, October 21, 2005 8:14 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> 
--> 
--> Radia Perlman wrote:
--> 
--> >I don't think there's any reason, even if most of the 
--> traffic on the 
--> >link comes from the DR, for the
--> >DR to be the root of the spanning tree.
--> >What would be bad is if an RBridge, participating in two bridged 
--> >islands, winds up merging
--> >the islands into a bigger island.
--> >  
--> >
--> Good point, but I think it can be solved.
--> The merging of islands can be prevented if the RBridge 
--> acting as root 
--> limits to one port maximum in the Designated Port Role of 
--> spanning tree 
--> for sbridges.
--> 
--> >The whole point is to make the bridged islands as small as 
--> possible, so 
--> >most forwarding is done
--> >protected by hop count, and with optimal routes.
--> >
--> >  
--> >
--> I'll admit that having RBridges *initiate* BPDUs
--> 
--> >to vie for being Root is not as harmful as having them 
--> *forward* BPDUs 
--> >between
--> >bridged islands (provided an RBridge is careful not to 
--> merge two islands 
--> >that would
--> >have been separate if the RBridge had just been blocking BPDUs).
--> >
--> >We shouldn't make things more complex in an attempt to 
--> come up with a 
--> >"more optimal"
--> >spanning tree within the bridged islands.
--> >  
--> >
--> 
--> >With a bidirectional tree, as happens with bridges, 
--> there's nothing 
--> >special about the Root.
--> >Also, the traffic pattern might be such that most of the 
--> traffic is 
--> >between endnodes within
--> >the island. 
--> >
--> With the client server model, dominant traffic is to and 
--> from the core 
--> layer of campus network, so I think most of the traffic will flow 
--> from/into Rbridge, not withing the islands.
--> 
--> >So there's really no reason to believe that having the 
--> >RBridge DR be the
--> >spanning tree Root will result in better performance. And 
--> is certainly 
--> >complicates things.
--> >And it also certainly is dangerous because of the 
--> potential of merging 
--> >islands.
--> >
--> >  
--> >
--> I do not think is dangerous. The merging of islands is not 
--> convenient, 
--> but it can be prevented, limiting to one port the 
--> Designated Role in the 
--> root Rbridge.
--> Guillermo
--> 
--> >Radia
--> >
--> >
--> >
--> >Guillermo Ib??ez wrote:
--> >
--> >  
--> >
--> >>I see the standard root election mechanism of spanning 
--> tree islands as 
--> >>the fastest and simpler mechanism for DR Rbridge 
--> designation. I see the 
--> >>DR Rbridge as being necessarily the ROOT bridge of  that 
--> sbridged cloud 
--> >>(or "link"). The root bridge of a standard spanning tree is the 
--> >>"natural" source and sink point for the spanning tree.  
--> To do so, the DR 
--> >>must issue BPDUs to become the root bridge.  This is part 
--> of what I 
--> >>mentioned days ago as PARTICIPATE PER PORT, but may be we 
--> should call it 
--> >>SOURCE OR SINK (participate, do not forward BPDUs, only 
--> send own BPDUs 
--> >>to contend to be the root bridge of the link).
--> >>The consequence of this DR election mechanism is that the 
--> priority 
--> >>configured at Rbridges as bridge ID would determine their 
--> also their 
--> >>election priority as DRs. I think this keep both domains 
--> coordinated 
--> >>with a single mechanism.
--> >>Guillermo
--> >>
--> >>Radia Perlman wrote:
--> >>
--> >> 
--> >>
--> >>    
--> >>
--> >>>I don't believe there should be options here.
--> >>>It should be plug and play.
--> >>>RBridges should BLOCK bridge spanning tree messages,
--> >>>and isolate the bridged islands.
--> >>>
--> >>>I absolutely do not understand what people are
--> >>>worried about with BLOCK.
--> >>>
--> >>>I suggest someone that actually thinks there is
--> >>>some reason to do anything other than drop
--> >>>spanning tree messages start a thread with
--> >>>a subject line
--> >>>"why it is good for RBridges to forward BPDUs",
--> >>>and very very carefully explain from scratch
--> >>>what the reasoning is. Not with a long
--> >>>email quoting pieces of other emails, but
--> >>>with a carefully crafted, from scratch explanation
--> >>>of what you perceive as a problem with BLOCk, and
--> >>>what the perceived benefit of ever having
--> >>>RBridges forwarding BPDUs would
--> >>>be.
--> >>>
--> >>>Oh...and there was a much earlier thread of the
--> >>>thread about other devices that might forward
--> >>>or drop BPDUs. There have always been things we
--> >>>referred to as "simple bridges" that forwarded spanning
--> >>>tree messages. I was careful to ensure that the
--> >>>spanning tree would work with such devices. Of course
--> >>>the spanning tree would not prevent a loop of all
--> >>>simple bridges, but if there was at least one spanning
--> >>>tree bridge in the middle of every possible loop, then
--> >>>there would wind up being no loops.
--> >>>
--> >>>You can think of "simple bridges" (ones that mindlessly
--> >>>forward BPDUs) as a layer below bridges. They are
--> >>>invisible to bridges. Bridges see a bunch of
--> >>>segments connected by simple bridges as a single segment.
--> >>>(Just like RBridges will see a bunch of segments connected
--> >>>by bridges as a single segment).
--> >>>
--> >>>Devices that drop BDPUs work if they are really
--> >>>layered on top of bridges, i.e., they let the
--> >>>bridges do their own thing to create isolated
--> >>>broadcast domains, and then these other devices do
--> >>>their own thing to glue these islands together.
--> >>>Like routers do. And like RBridges will do.
--> >>>
--> >>>Radia
--> >>>
--> >>>
--> >>>
--> >>>Guillermo Ib??ez wrote On 10/20/05 14:35,:
--> >>>
--> >>>
--> >>>   
--> >>>
--> >>>      
--> >>>
--> >>>>Eric,
--> >>>>
--> >>>>
--> >>>>Gray, Eric wrote:
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>Guillermo,
--> >>>>>
--> >>>>>	During the discussion, the terms TRANSPARENT, 
--> PARTICIPATE
--> >>>>>and BLOCK were used (often in upper-case, exactly as I 
--> have used
--> >>>>>them here) as if these would ultimately be options 
--> that might be
--> >>>>>supported - either as a complete set, or as some subset.  
--> >>>>>
--> >>>>>	For example, one argument was that TRANSPARENT 
--> or PARTICIPATE 
--> >>>>>might be used, but BLOCK should not.
--> >>>>>
--> >>>>>	Also, at certain points in the discussion, 
--> there was some
--> >>>>>thought that these might be modes that applied at 
--> different states
--> >>>>>during transitions in a network.
--> >>>>>
--> >>>>>	From a practical stand-point - however - it 
--> would be best if
--> >>>>>we did not have to support all of these, either as 
--> options, or as
--> >>>>>modes.  The mere fact that they were brought up does 
--> not mean we
--> >>>>>are committed to including them.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>Agreed
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>	In particular, if we start talking about - for 
--> instance -
--> >>>>>having a per-interface option for all of these choices 
--> (and maybe
--> >>>>>others as well), then we either need to analyze proposals for 
--> >>>>>architecture and design to ensure that the "right things" will
--> >>>>>happen when an arbitrary combination of all of these 
--> options is in 
--> >>>>>effect, or we need to define caveats for network 
--> operators to avoid 
--> >>>>>specific combinations of options.  For example, we may 
--> need to say
--> >>>>>that the same option must be set throughout the 
--> network or this and
--> >>>>>that will (or may) happen.  That kind of design begs 
--> configuration
--> >>>>>errors to occur.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>If you refer as configuration options per interface to 
--> the PARTICIPATE 
--> >>>>PER PORT mode as an option per port, it is not the 
--> case. If  you refer 
--> >>>>to being the DR the root bridge of the sbridge domain, 
--> I think it must 
--> >>>>be analyzed as a real alternative, even if it is not 
--> the default 
--> >>>>configuration.
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>	In this case, the fact that we want to make the 
--> solution plug
--> >>>>>and play means that we can reduce the potential for 
--> disaster if we
--> >>>>>choose (and require) a specific default set of option 
--> choices.  If
--> >>>>>we can get away with it, however, we should simply 
--> avoid options.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>Agreed, but not for the root bridge problem because is 
--> a real, practical 
--> >>>>issue.
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>	While having these same values as modes that 
--> apply during 
--> >>>>>certain transitional states is cleaner, it would 
--> require a well-
--> >>>>>defined finite state-machine (not a particular problem) and a 
--> >>>>>genuine need for these behaviors under certain 
--> circumstances.  It
--> >>>>>may well be the case that this turns out to be true.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>RSTP port state machines are there, may be they should 
--> be taken into 
--> >>>>consideration to make a consistent and integrated, but 
--> not interwoven, 
--> >>>>design for Rbridges that work with RSTP trees.
--> >>>>Guillermo. 
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>--
--> >>>>>Eric
--> >>>>>
--> >>>>>--> -----Original Message-----
--> >>>>>--> From: [email-masked] 
--> >>>>>--> [mailto:[email-masked]]On
--> >>>>>--> Behalf Of Guillermo Ib??ez
--> >>>>>--> Sent: Thursday, October 20, 2005 4:19 PM
--> >>>>>--> To: Developing a hybrid router/bridge.
--> >>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction
--> >>>>>--> 
--> >>>>>--> 
--> >>>>>--> I volunteer for some work on the capture, although my 
--> >>>>>--> english might be 
--> >>>>>--> not too understandable.  From what date should the capture 
--> >>>>>--> to be done?
--> >>>>>--> 
--> >>>>>--> Regarding PARTICIPATE PER PORT:
--> >>>>>--> Although I do not have a clear position, and it 
--> requires detailed 
--> >>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
--> >>>>>--> better integrated 
--> >>>>>--> with spanning tree, while maintaining the basic decoupling 
--> >>>>>--> that BLOCK 
--> >>>>>--> provides.
--> >>>>>--> With PARTICIPATE PER PORT it would be possible to 
--> force the elected 
--> >>>>>--> Rbridge to become the sbridge root of the bridged 
--> domain by 
--> >>>>>--> modifying 
--> >>>>>--> its bridge priority when it gets elected as Designated by 
--> >>>>>--> IS-IS (this 
--> >>>>>--> could be an optimization). In this way the path length is 
--> >>>>>--> minimum  from 
--> >>>>>--> all bridges of bridged domain to the DR.
--> >>>>>-->  
--> >>>>>--> 
--> >>>>>--> Erik Nordmark wrote:
--> >>>>>--> 
--> >>>>>--> >We've had some useful discussion on this mailing list.
--> >>>>>--> >It would be good if somebody can capture the results 
--> >>>>>--> (perhaps as a long 
--> >>>>>--> >email) that we can fold into the draft(s) later. 
--> Any volunteers?
--> >>>>>--> >
--> >>>>>--> >I don't know if we will have additional issues in this 
--> >>>>>--> space or that it 
--> >>>>>--> >otherwise makes sense devoting agenda time to it 
--> in Vancouver.
--> >>>>>--> >
--> >>>>>--> >For instance, while I'm convinced that BLOCK works, I 
--> >>>>>--> wonder if there is 
--> >>>>>--> >something in PARTICIPATE PER PORT that can make the 
--> >>>>>--> interaction work better.
--> >>>>>--> >
--> >>>>>--> >Two cases to consider:
--> >>>>>--> >1. The elected forwarder dies and a new one gets elected. 
--> >>>>>--> How quickly 
--> >>>>>--> >can packets sent by stations in the bridged cloud fail 
--> >>>>>--> over to go to the 
--> >>>>>--> >new elected forwarder?
--> >>>>>--> >
--> >>>>>--> >  
--> >>>>>--> >
--> >>>>>--> My understanding is that if the forwarded dies, 
--> the sbridge domain 
--> >>>>>--> should handle  it as  a topology change 
--> notification, tables   of 
--> >>>>>--> sbridges should be  flushed according to the spanning tree 
--> >>>>>--> rules, so the 
--> >>>>>--> sbridge domain must know the DR will not forward frames as 
--> >>>>>--> it used to. 
--> >>>>>--> It seems Rbridge shall issue a Topology Change 
--> Notification 
--> >>>>>--> via sbridge 
--> >>>>>--> domain to flush MAC tables. Is a fast analysis, probably I 
--> >>>>>--> miss details.
--> >>>>>-->  
--> >>>>>--> 
--> >>>>>--> >2. We have two separate bridged domains, each 
--> with their elected 
--> >>>>>--> >forwarder. Somebody connects the two bridged domains 
--> >>>>>--> together with a 
--> >>>>>--> >wire. This can cause a temporary loop until a single 
--> >>>>>--> elected forwarder 
--> >>>>>--> >is picked by the RBridges.
--> >>>>>--> >
--> >>>>>--> >  
--> >>>>>--> >
--> >>>>>--> In this case the PARTICIPATE PER PORT seems superior, as 
--> >>>>>--> the two merged 
--> >>>>>--> bridged domains will merge their spanning trees into one 
--> >>>>>--> and both DRs 
--> >>>>>--> will compete to be the root of the merged tree, 
--> this mechanism will 
--> >>>>>--> likely be faster (via RSTP fast transit to 
--> forwarding state 
--> >>>>>--> over the 
--> >>>>>--> bridged domain)  than  Designation to select the 
--> unique DR. 
--> >>>>>--> In other 
--> >>>>>--> words , the mechanism of root election in sbridge could be 
--> >>>>>--> used to help 
--> >>>>>--> in DR designation and/or viceversa.
--> >>>>>--> So I see in PARTICIPATE PER PORT, some coupling between DR 
--> >>>>>--> status and 
--> >>>>>--> root status of sbridge domain that can be used
--> >>>>>-->  to speed up convergence and coherence of both domains. It 
--> >>>>>--> seems that 
--> >>>>>--> sbridge domains should be under the control of  
--> Rbridges, but the 
--> >>>>>--> sbridge mechanims should be used by Rbridges to 
--> keep the network 
--> >>>>>--> consistency and reconfiguration capabilities of RSTP.
--> >>>>>--> Guillermo
--> >>>>>--> 
--> >>>>>-->  
--> >>>>>--> _______________________________________________
--> >>>>>--> rbridge mailing list
--> >>>>>--> [email-masked]
--> >>>>>--> http://www.postel.org/mailman/listinfo/rbridge
--> >>>>>--> 
--> >>>>>_______________________________________________
--> >>>>>rbridge mailing list
--> >>>>>[email-masked]
--> >>>>>http://www.postel.org/mailman/listinfo/rbridge
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>_______________________________________________
--> >>>>rbridge mailing list
--> >>>>[email-masked]
--> >>>>http://www.postel.org/mailman/listinfo/rbridge
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>_______________________________________________
--> >>>rbridge mailing list
--> >>>[email-masked]
--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >>>
--> >>>
--> >>>
--> >>>   
--> >>>
--> >>>      
--> >>>
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[email-masked]
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> >> 
--> >>
--> >>    
--> >>
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >
--> >  
--> >
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Fri, 21 Oct 2005 08:34:02 -0700
From: "Michael Smith \(michsmit\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 924

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> 
> And I can't resist pointing out interesting technical 
> tidbits...with the bridge spanning tree, the packets go on 
> all the links, even if no other bridges will be picking up 
> the packet. Whereas with RBridges, if the link-state-computed 
> tree indicates no downstream receivers, then the packet is 
> not sent onto that port.

Interesting, are you referring only to the encapsulated packets ?  I
would think that every link in the link-state-computed spanning tree
would still need to see the unencapsulated packet.  We may know that
there are no rbridge receivers but we don't necessarily know about
non-rbridge receivers.  For any links that have peer rbridges downstream
from the view of the spanning tree, there would end up being 2 packets
transmitted.

Michael

> Radia

Content-class: urn:content-classes:message
Date: Fri, 21 Oct 2005 10:47:06 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now available
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1064

For completeness in section "3. Issues", there is of course the
possibility of
Per-ingress/Per VLAN spanning trees.

Peter

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gray, Eric
> Sent: Thursday, October 20, 2005 5:56 PM
> To: 'Developing a hybrid router/bridge.'
> Subject: [rbridge] R-Bridge Routing Requirements draft is now 
> available
> 
> 
> The draft "Routing Requirements in Support of R-Bridges" - 
> submitted last 
> Friday - is now available at:
> 
http://www.ietf.org/internet-drafts/draft-gray-rbridge-routing-reqs-00.t
xt

This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt
and is very preliminary.  I am looking for input for the various
sections
- particularly those that currently only contain "TBD" :-)

This was one of the drafts that the working group felt would be required
at the last meeting.

--
Eric Gray
_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Fri, 21 Oct 2005 10:28:45 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] R-Bridge Routing Requirements draft is now available
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1334

First comment:

"IS-IS is a more appropriate choice than OSPF in this case because it is

easy in IS-IS to define new TLVs for carrying new information"

I don't think its the new TLVs that are much of a problem, after all its
really a new protocol so we could tweak and extend without backward
compatibility worries. However the fact IS-IS runs directly over L2
is to me the big plus.

Peter

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gray, Eric
> Sent: Thursday, October 20, 2005 5:56 PM
> To: 'Developing a hybrid router/bridge.'
> Subject: [rbridge] R-Bridge Routing Requirements draft is now 
> available
> 
> 
> The draft "Routing Requirements in Support of R-Bridges" - 
> submitted last 
> Friday - is now available at:
> 
http://www.ietf.org/internet-drafts/draft-gray-rbridge-routing-reqs-00.t
xt

This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt
and is very preliminary.  I am looking for input for the various
sections
- particularly those that currently only contain "TBD" :-)

This was one of the drafts that the working group felt would be required
at the last meeting.

--
Eric Gray
_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

Date: Fri, 21 Oct 2005 14:25:58 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 13469

I agree suboptimality is not the key issue, but coordination between STP 
and RBridges  regarding DR election (faster DR election IMMO, although I 
know nothing about IS-IS DR election) . Path optimization is a plus.
Guillermo

Gray, Eric wrote:

>Guillermo,
>
>	Actually, the thing about a spanning tree is that frames entering
>the tree will reach every node.  Hence the result of having an RBridge
>be something other than the root of the local spanning tree would be 
>that frame delivery might be sub-optimal.  In fact, it is not even
>necessary for the R-Bridge to be directly connected to the root of a
>local spanning tree.
>
>	That's part of the reason why an RBridge does not need to be a
>part of the local STP.
>
>	Given the way that spanning tree works in general, sub-optimal 
>delivery of frames would not be something new.  Having th
>
>--
>Eric
>
>--> -----Original Message-----
>--> From: [email-masked] 
>--> [mailto:[email-masked]]On
>--> Behalf Of Guillermo Ib??ez
>--> Sent: Friday, October 21, 2005 2:33 AM
>--> To: [email-masked]; Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] RBridge/bridge interaction
>--> 
>--> 
>--> 
>--> I see the standard root election mechanism of spanning tree 
>--> islands as 
>--> the fastest and simpler mechanism for DR Rbridge 
>--> designation. I see the 
>--> DR Rbridge as being necessarily the ROOT bridge of  that 
>--> sbridged cloud 
>--> (or "link"). The root bridge of a standard spanning tree is the 
>--> "natural" source and sink point for the spanning tree.  To 
>--> do so, the DR 
>--> must issue BPDUs to become the root bridge.  This is part of what I 
>--> mentioned days ago as PARTICIPATE PER PORT, but may be we 
>--> should call it 
>--> SOURCE OR SINK (participate, do not forward BPDUs, only 
>--> send own BPDUs 
>--> to contend to be the root bridge of the link).
>--> The consequence of this DR election mechanism is that the priority 
>--> configured at Rbridges as bridge ID would determine their 
>--> also their 
>--> election priority as DRs. I think this keep both domains 
>--> coordinated 
>--> with a single mechanism.
>--> Guillermo
>--> 
>--> Radia Perlman wrote:
>--> 
>--> >I don't believe there should be options here.
>--> >It should be plug and play.
>--> >RBridges should BLOCK bridge spanning tree messages,
>--> >and isolate the bridged islands.
>--> >
>--> >I absolutely do not understand what people are
>--> >worried about with BLOCK.
>--> >
>--> >I suggest someone that actually thinks there is
>--> >some reason to do anything other than drop
>--> >spanning tree messages start a thread with
>--> >a subject line
>--> >"why it is good for RBridges to forward BPDUs",
>--> >and very very carefully explain from scratch
>--> >what the reasoning is. Not with a long
>--> >email quoting pieces of other emails, but
>--> >with a carefully crafted, from scratch explanation
>--> >of what you perceive as a problem with BLOCk, and
>--> >what the perceived benefit of ever having
>--> >RBridges forwarding BPDUs would
>--> >be.
>--> >
>--> >Oh...and there was a much earlier thread of the
>--> >thread about other devices that might forward
>--> >or drop BPDUs. There have always been things we
>--> >referred to as "simple bridges" that forwarded spanning
>--> >tree messages. I was careful to ensure that the
>--> >spanning tree would work with such devices. Of course
>--> >the spanning tree would not prevent a loop of all
>--> >simple bridges, but if there was at least one spanning
>--> >tree bridge in the middle of every possible loop, then
>--> >there would wind up being no loops.
>--> >
>--> >You can think of "simple bridges" (ones that mindlessly
>--> >forward BPDUs) as a layer below bridges. They are
>--> >invisible to bridges. Bridges see a bunch of
>--> >segments connected by simple bridges as a single segment.
>--> >(Just like RBridges will see a bunch of segments connected
>--> >by bridges as a single segment).
>--> >
>--> >Devices that drop BDPUs work if they are really
>--> >layered on top of bridges, i.e., they let the
>--> >bridges do their own thing to create isolated
>--> >broadcast domains, and then these other devices do
>--> >their own thing to glue these islands together.
>--> >Like routers do. And like RBridges will do.
>--> >
>--> >Radia
>--> >
>--> >
>--> >
>--> >Guillermo Ib??ez wrote On 10/20/05 14:35,:
>--> >  
>--> >
>--> >>Eric,
>--> >>
>--> >>
>--> >>Gray, Eric wrote:
>--> >>
>--> >>
>--> >>    
>--> >>
>--> >>>Guillermo,
>--> >>>
>--> >>>	During the discussion, the terms TRANSPARENT, PARTICIPATE
>--> >>>and BLOCK were used (often in upper-case, exactly as I have used
>--> >>>them here) as if these would ultimately be options that might be
>--> >>>supported - either as a complete set, or as some subset.  
>--> >>>
>--> >>>	For example, one argument was that TRANSPARENT or PARTICIPATE 
>--> >>>might be used, but BLOCK should not.
>--> >>>
>--> >>>	Also, at certain points in the discussion, there was some
>--> >>>thought that these might be modes that applied at 
>--> different states
>--> >>>during transitions in a network.
>--> >>>
>--> >>>	From a practical stand-point - however - it would be best if
>--> >>>we did not have to support all of these, either as options, or as
>--> >>>modes.  The mere fact that they were brought up does not mean we
>--> >>>are committed to including them.
>--> >>>
>--> >>>
>--> >>>
>--> >>>      
>--> >>>
>--> >>Agreed
>--> >>
>--> >>
>--> >>    
>--> >>
>--> >>>	In particular, if we start talking about - for instance -
>--> >>>having a per-interface option for all of these choices (and maybe
>--> >>>others as well), then we either need to analyze proposals for 
>--> >>>architecture and design to ensure that the "right things" will
>--> >>>happen when an arbitrary combination of all of these 
>--> options is in 
>--> >>>effect, or we need to define caveats for network 
>--> operators to avoid 
>--> >>>specific combinations of options.  For example, we may 
>--> need to say
>--> >>>that the same option must be set throughout the network 
>--> or this and
>--> >>>that will (or may) happen.  That kind of design begs 
>--> configuration
>--> >>>errors to occur.
>--> >>>
>--> >>>
>--> >>>
>--> >>>      
>--> >>>
>--> >>If you refer as configuration options per interface to 
>--> the PARTICIPATE 
>--> >>PER PORT mode as an option per port, it is not the case. 
>--> If  you refer 
>--> >>to being the DR the root bridge of the sbridge domain, I 
>--> think it must 
>--> >>be analyzed as a real alternative, even if it is not the default 
>--> >>configuration.
>--> >>
>--> >>
>--> >>    
>--> >>
>--> >>>	In this case, the fact that we want to make the solution plug
>--> >>>and play means that we can reduce the potential for 
>--> disaster if we
>--> >>>choose (and require) a specific default set of option 
>--> choices.  If
>--> >>>we can get away with it, however, we should simply avoid options.
>--> >>>
>--> >>>
>--> >>>
>--> >>>      
>--> >>>
>--> >>Agreed, but not for the root bridge problem because is a 
>--> real, practical 
>--> >>issue.
>--> >>
>--> >>
>--> >>    
>--> >>
>--> >>>	While having these same values as modes that apply during 
>--> >>>certain transitional states is cleaner, it would require a well-
>--> >>>defined finite state-machine (not a particular problem) and a 
>--> >>>genuine need for these behaviors under certain circumstances.  It
>--> >>>may well be the case that this turns out to be true.
>--> >>>
>--> >>>
>--> >>>
>--> >>>      
>--> >>>
>--> >>RSTP port state machines are there, may be they should be 
>--> taken into 
>--> >>consideration to make a consistent and integrated, but 
>--> not interwoven, 
>--> >>design for Rbridges that work with RSTP trees.
>--> >>Guillermo. 
>--> >>
>--> >>
>--> >>    
>--> >>
>--> >>>--
>--> >>>Eric
>--> >>>
>--> >>>--> -----Original Message-----
>--> >>>--> From: [email-masked] 
>--> >>>--> [mailto:[email-masked]]On
>--> >>>--> Behalf Of Guillermo Ib??ez
>--> >>>--> Sent: Thursday, October 20, 2005 4:19 PM
>--> >>>--> To: Developing a hybrid router/bridge.
>--> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction
>--> >>>--> 
>--> >>>--> 
>--> >>>--> I volunteer for some work on the capture, although my 
>--> >>>--> english might be 
>--> >>>--> not too understandable.  From what date should the capture 
>--> >>>--> to be done?
>--> >>>--> 
>--> >>>--> Regarding PARTICIPATE PER PORT:
>--> >>>--> Although I do not have a clear position, and it 
>--> requires detailed 
>--> >>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
>--> >>>--> better integrated 
>--> >>>--> with spanning tree, while maintaining the basic decoupling 
>--> >>>--> that BLOCK 
>--> >>>--> provides.
>--> >>>--> With PARTICIPATE PER PORT it would be possible to 
>--> force the elected 
>--> >>>--> Rbridge to become the sbridge root of the bridged domain by 
>--> >>>--> modifying 
>--> >>>--> its bridge priority when it gets elected as Designated by 
>--> >>>--> IS-IS (this 
>--> >>>--> could be an optimization). In this way the path length is 
>--> >>>--> minimum  from 
>--> >>>--> all bridges of bridged domain to the DR.
>--> >>>-->  
>--> >>>--> 
>--> >>>--> Erik Nordmark wrote:
>--> >>>--> 
>--> >>>--> >We've had some useful discussion on this mailing list.
>--> >>>--> >It would be good if somebody can capture the results 
>--> >>>--> (perhaps as a long 
>--> >>>--> >email) that we can fold into the draft(s) later. 
>--> Any volunteers?
>--> >>>--> >
>--> >>>--> >I don't know if we will have additional issues in this 
>--> >>>--> space or that it 
>--> >>>--> >otherwise makes sense devoting agenda time to it in 
>--> Vancouver.
>--> >>>--> >
>--> >>>--> >For instance, while I'm convinced that BLOCK works, I 
>--> >>>--> wonder if there is 
>--> >>>--> >something in PARTICIPATE PER PORT that can make the 
>--> >>>--> interaction work better.
>--> >>>--> >
>--> >>>--> >Two cases to consider:
>--> >>>--> >1. The elected forwarder dies and a new one gets elected. 
>--> >>>--> How quickly 
>--> >>>--> >can packets sent by stations in the bridged cloud fail 
>--> >>>--> over to go to the 
>--> >>>--> >new elected forwarder?
>--> >>>--> >
>--> >>>--> >  
>--> >>>--> >
>--> >>>--> My understanding is that if the forwarded dies, the 
>--> sbridge domain 
>--> >>>--> should handle  it as  a topology change 
>--> notification, tables   of 
>--> >>>--> sbridges should be  flushed according to the spanning tree 
>--> >>>--> rules, so the 
>--> >>>--> sbridge domain must know the DR will not forward frames as 
>--> >>>--> it used to. 
>--> >>>--> It seems Rbridge shall issue a Topology Change Notification 
>--> >>>--> via sbridge 
>--> >>>--> domain to flush MAC tables. Is a fast analysis, probably I 
>--> >>>--> miss details.
>--> >>>-->  
>--> >>>--> 
>--> >>>--> >2. We have two separate bridged domains, each with 
>--> their elected 
>--> >>>--> >forwarder. Somebody connects the two bridged domains 
>--> >>>--> together with a 
>--> >>>--> >wire. This can cause a temporary loop until a single 
>--> >>>--> elected forwarder 
>--> >>>--> >is picked by the RBridges.
>--> >>>--> >
>--> >>>--> >  
>--> >>>--> >
>--> >>>--> In this case the PARTICIPATE PER PORT seems superior, as 
>--> >>>--> the two merged 
>--> >>>--> bridged domains will merge their spanning trees into one 
>--> >>>--> and both DRs 
>--> >>>--> will compete to be the root of the merged tree, this 
>--> mechanism will 
>--> >>>--> likely be faster (via RSTP fast transit to forwarding state 
>--> >>>--> over the 
>--> >>>--> bridged domain)  than  Designation to select the unique DR. 
>--> >>>--> In other 
>--> >>>--> words , the mechanism of root election in sbridge could be 
>--> >>>--> used to help 
>--> >>>--> in DR designation and/or viceversa.
>--> >>>--> So I see in PARTICIPATE PER PORT, some coupling between DR 
>--> >>>--> status and 
>--> >>>--> root status of sbridge domain that can be used
>--> >>>-->  to speed up convergence and coherence of both domains. It 
>--> >>>--> seems that 
>--> >>>--> sbridge domains should be under the control of  
>--> Rbridges, but the 
>--> >>>--> sbridge mechanims should be used by Rbridges to keep 
>--> the network 
>--> >>>--> consistency and reconfiguration capabilities of RSTP.
>--> >>>--> Guillermo
>--> >>>--> 
>--> >>>-->  
>--> >>>--> _______________________________________________
>--> >>>--> rbridge mailing list
>--> >>>--> [email-masked]
>--> >>>--> http://www.postel.org/mailman/listinfo/rbridge
>--> >>>--> 
>--> >>>_______________________________________________
>--> >>>rbridge mailing list
>--> >>>[email-masked]
>--> >>>http://www.postel.org/mailman/listinfo/rbridge
>--> >>>
>--> >>>
>--> >>>
>--> >>>      
>--> >>>
>--> >>_______________________________________________
>--> >>rbridge mailing list
>--> >>[email-masked]
>--> >>http://www.postel.org/mailman/listinfo/rbridge
>--> >>    
>--> >>
>--> >
>--> >_______________________________________________
>--> >rbridge mailing list
>--> >[email-masked]
>--> >http://www.postel.org/mailman/listinfo/rbridge
>--> >
>--> >  
>--> >
>--> _______________________________________________
>--> rbridge mailing list
>--> [email-masked]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>[email-masked]

Date: Fri, 21 Oct 2005 14:14:19 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 13594

Radia Perlman wrote:

>I don't think there's any reason, even if most of the traffic on the 
>link comes from the DR, for the
>DR to be the root of the spanning tree.
>What would be bad is if an RBridge, participating in two bridged 
>islands, winds up merging
>the islands into a bigger island.
>  
>
Good point, but I think it can be solved.
The merging of islands can be prevented if the RBridge acting as root 
limits to one port maximum in the Designated Port Role of spanning tree 
for sbridges.

>The whole point is to make the bridged islands as small as possible, so 
>most forwarding is done
>protected by hop count, and with optimal routes.
>
>  
>
I'll admit that having RBridges *initiate* BPDUs

>to vie for being Root is not as harmful as having them *forward* BPDUs 
>between
>bridged islands (provided an RBridge is careful not to merge two islands 
>that would
>have been separate if the RBridge had just been blocking BPDUs).
>
>We shouldn't make things more complex in an attempt to come up with a 
>"more optimal"
>spanning tree within the bridged islands.
>  
>

>With a bidirectional tree, as happens with bridges, there's nothing 
>special about the Root.
>Also, the traffic pattern might be such that most of the traffic is 
>between endnodes within
>the island. 
>
With the client server model, dominant traffic is to and from the core 
layer of campus network, so I think most of the traffic will flow 
from/into Rbridge, not withing the islands.

>So there's really no reason to believe that having the 
>RBridge DR be the
>spanning tree Root will result in better performance. And is certainly 
>complicates things.
>And it also certainly is dangerous because of the potential of merging 
>islands.
>
>  
>
I do not think is dangerous. The merging of islands is not convenient, 
but it can be prevented, limiting to one port the Designated Role in the 
root Rbridge.
Guillermo

>Radia
>
>
>
>Guillermo Ib??ez wrote:
>
>  
>
>>I see the standard root election mechanism of spanning tree islands as 
>>the fastest and simpler mechanism for DR Rbridge designation. I see the 
>>DR Rbridge as being necessarily the ROOT bridge of  that sbridged cloud 
>>(or "link"). The root bridge of a standard spanning tree is the 
>>"natural" source and sink point for the spanning tree.  To do so, the DR 
>>must issue BPDUs to become the root bridge.  This is part of what I 
>>mentioned days ago as PARTICIPATE PER PORT, but may be we should call it 
>>SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs 
>>to contend to be the root bridge of the link).
>>The consequence of this DR election mechanism is that the priority 
>>configured at Rbridges as bridge ID would determine their also their 
>>election priority as DRs. I think this keep both domains coordinated 
>>with a single mechanism.
>>Guillermo
>>
>>Radia Perlman wrote:
>>
>> 
>>
>>    
>>
>>>I don't believe there should be options here.
>>>It should be plug and play.
>>>RBridges should BLOCK bridge spanning tree messages,
>>>and isolate the bridged islands.
>>>
>>>I absolutely do not understand what people are
>>>worried about with BLOCK.
>>>
>>>I suggest someone that actually thinks there is
>>>some reason to do anything other than drop
>>>spanning tree messages start a thread with
>>>a subject line
>>>"why it is good for RBridges to forward BPDUs",
>>>and very very carefully explain from scratch
>>>what the reasoning is. Not with a long
>>>email quoting pieces of other emails, but
>>>with a carefully crafted, from scratch explanation
>>>of what you perceive as a problem with BLOCk, and
>>>what the perceived benefit of ever having
>>>RBridges forwarding BPDUs would
>>>be.
>>>
>>>Oh...and there was a much earlier thread of the
>>>thread about other devices that might forward
>>>or drop BPDUs. There have always been things we
>>>referred to as "simple bridges" that forwarded spanning
>>>tree messages. I was careful to ensure that the
>>>spanning tree would work with such devices. Of course
>>>the spanning tree would not prevent a loop of all
>>>simple bridges, but if there was at least one spanning
>>>tree bridge in the middle of every possible loop, then
>>>there would wind up being no loops.
>>>
>>>You can think of "simple bridges" (ones that mindlessly
>>>forward BPDUs) as a layer below bridges. They are
>>>invisible to bridges. Bridges see a bunch of
>>>segments connected by simple bridges as a single segment.
>>>(Just like RBridges will see a bunch of segments connected
>>>by bridges as a single segment).
>>>
>>>Devices that drop BDPUs work if they are really
>>>layered on top of bridges, i.e., they let the
>>>bridges do their own thing to create isolated
>>>broadcast domains, and then these other devices do
>>>their own thing to glue these islands together.
>>>Like routers do. And like RBridges will do.
>>>
>>>Radia
>>>
>>>
>>>
>>>Guillermo Ib??ez wrote On 10/20/05 14:35,:
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>Eric,
>>>>
>>>>
>>>>Gray, Eric wrote:
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>Guillermo,
>>>>>
>>>>>	During the discussion, the terms TRANSPARENT, PARTICIPATE
>>>>>and BLOCK were used (often in upper-case, exactly as I have used
>>>>>them here) as if these would ultimately be options that might be
>>>>>supported - either as a complete set, or as some subset.  
>>>>>
>>>>>	For example, one argument was that TRANSPARENT or PARTICIPATE 
>>>>>might be used, but BLOCK should not.
>>>>>
>>>>>	Also, at certain points in the discussion, there was some
>>>>>thought that these might be modes that applied at different states
>>>>>during transitions in a network.
>>>>>
>>>>>	From a practical stand-point - however - it would be best if
>>>>>we did not have to support all of these, either as options, or as
>>>>>modes.  The mere fact that they were brought up does not mean we
>>>>>are committed to including them.
>>>>>
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>Agreed
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>	In particular, if we start talking about - for instance -
>>>>>having a per-interface option for all of these choices (and maybe
>>>>>others as well), then we either need to analyze proposals for 
>>>>>architecture and design to ensure that the "right things" will
>>>>>happen when an arbitrary combination of all of these options is in 
>>>>>effect, or we need to define caveats for network operators to avoid 
>>>>>specific combinations of options.  For example, we may need to say
>>>>>that the same option must be set throughout the network or this and
>>>>>that will (or may) happen.  That kind of design begs configuration
>>>>>errors to occur.
>>>>>
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>If you refer as configuration options per interface to the PARTICIPATE 
>>>>PER PORT mode as an option per port, it is not the case. If  you refer 
>>>>to being the DR the root bridge of the sbridge domain, I think it must 
>>>>be analyzed as a real alternative, even if it is not the default 
>>>>configuration.
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>	In this case, the fact that we want to make the solution plug
>>>>>and play means that we can reduce the potential for disaster if we
>>>>>choose (and require) a specific default set of option choices.  If
>>>>>we can get away with it, however, we should simply avoid options.
>>>>>
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>Agreed, but not for the root bridge problem because is a real, practical 
>>>>issue.
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>	While having these same values as modes that apply during 
>>>>>certain transitional states is cleaner, it would require a well-
>>>>>defined finite state-machine (not a particular problem) and a 
>>>>>genuine need for these behaviors under certain circumstances.  It
>>>>>may well be the case that this turns out to be true.
>>>>>
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>RSTP port state machines are there, may be they should be taken into 
>>>>consideration to make a consistent and integrated, but not interwoven, 
>>>>design for Rbridges that work with RSTP trees.
>>>>Guillermo. 
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>--
>>>>>Eric
>>>>>
>>>>>--> -----Original Message-----
>>>>>--> From: [email-masked] 
>>>>>--> [mailto:[email-masked]]On
>>>>>--> Behalf Of Guillermo Ib??ez
>>>>>--> Sent: Thursday, October 20, 2005 4:19 PM
>>>>>--> To: Developing a hybrid router/bridge.
>>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction
>>>>>--> 
>>>>>--> 
>>>>>--> I volunteer for some work on the capture, although my 
>>>>>--> english might be 
>>>>>--> not too understandable.  From what date should the capture 
>>>>>--> to be done?
>>>>>--> 
>>>>>--> Regarding PARTICIPATE PER PORT:
>>>>>--> Although I do not have a clear position, and it requires detailed 
>>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
>>>>>--> better integrated 
>>>>>--> with spanning tree, while maintaining the basic decoupling 
>>>>>--> that BLOCK 
>>>>>--> provides.
>>>>>--> With PARTICIPATE PER PORT it would be possible to force the elected 
>>>>>--> Rbridge to become the sbridge root of the bridged domain by 
>>>>>--> modifying 
>>>>>--> its bridge priority when it gets elected as Designated by 
>>>>>--> IS-IS (this 
>>>>>--> could be an optimization). In this way the path length is 
>>>>>--> minimum  from 
>>>>>--> all bridges of bridged domain to the DR.
>>>>>-->  
>>>>>--> 
>>>>>--> Erik Nordmark wrote:
>>>>>--> 
>>>>>--> >We've had some useful discussion on this mailing list.
>>>>>--> >It would be good if somebody can capture the results 
>>>>>--> (perhaps as a long 
>>>>>--> >email) that we can fold into the draft(s) later. Any volunteers?
>>>>>--> >
>>>>>--> >I don't know if we will have additional issues in this 
>>>>>--> space or that it 
>>>>>--> >otherwise makes sense devoting agenda time to it in Vancouver.
>>>>>--> >
>>>>>--> >For instance, while I'm convinced that BLOCK works, I 
>>>>>--> wonder if there is 
>>>>>--> >something in PARTICIPATE PER PORT that can make the 
>>>>>--> interaction work better.
>>>>>--> >
>>>>>--> >Two cases to consider:
>>>>>--> >1. The elected forwarder dies and a new one gets elected. 
>>>>>--> How quickly 
>>>>>--> >can packets sent by stations in the bridged cloud fail 
>>>>>--> over to go to the 
>>>>>--> >new elected forwarder?
>>>>>--> >
>>>>>--> >  
>>>>>--> >
>>>>>--> My understanding is that if the forwarded dies, the sbridge domain 
>>>>>--> should handle  it as  a topology change notification, tables   of 
>>>>>--> sbridges should be  flushed according to the spanning tree 
>>>>>--> rules, so the 
>>>>>--> sbridge domain must know the DR will not forward frames as 
>>>>>--> it used to. 
>>>>>--> It seems Rbridge shall issue a Topology Change Notification 
>>>>>--> via sbridge 
>>>>>--> domain to flush MAC tables. Is a fast analysis, probably I 
>>>>>--> miss details.
>>>>>-->  
>>>>>--> 
>>>>>--> >2. We have two separate bridged domains, each with their elected 
>>>>>--> >forwarder. Somebody connects the two bridged domains 
>>>>>--> together with a 
>>>>>--> >wire. This can cause a temporary loop until a single 
>>>>>--> elected forwarder 
>>>>>--> >is picked by the RBridges.
>>>>>--> >
>>>>>--> >  
>>>>>--> >
>>>>>--> In this case the PARTICIPATE PER PORT seems superior, as 
>>>>>--> the two merged 
>>>>>--> bridged domains will merge their spanning trees into one 
>>>>>--> and both DRs 
>>>>>--> will compete to be the root of the merged tree, this mechanism will 
>>>>>--> likely be faster (via RSTP fast transit to forwarding state 
>>>>>--> over the 
>>>>>--> bridged domain)  than  Designation to select the unique DR. 
>>>>>--> In other 
>>>>>--> words , the mechanism of root election in sbridge could be 
>>>>>--> used to help 
>>>>>--> in DR designation and/or viceversa.
>>>>>--> So I see in PARTICIPATE PER PORT, some coupling between DR 
>>>>>--> status and 
>>>>>--> root status of sbridge domain that can be used
>>>>>-->  to speed up convergence and coherence of both domains. It 
>>>>>--> seems that 
>>>>>--> sbridge domains should be under the control of  Rbridges, but the 
>>>>>--> sbridge mechanims should be used by Rbridges to keep the network 
>>>>>--> consistency and reconfiguration capabilities of RSTP.
>>>>>--> Guillermo
>>>>>--> 
>>>>>-->  
>>>>>--> _______________________________________________
>>>>>--> rbridge mailing list
>>>>>--> [email-masked]
>>>>>--> http://www.postel.org/mailman/listinfo/rbridge
>>>>>--> 
>>>>>[email-masked]
>>>>[email-masked]
>>>[email-masked]
>>[email-masked]
>[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 21 Oct 2005 08:26:50 -0300
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 14765

Guillermo,

	Sorry, part way through my last sentence, Outlook decided
to go ahead and send it.

	Please just ignore the "Having th" at the end.  It wasn't 
very important anyway...  :-)

--
Eric

--> -----Original Message-----
--> From: Gray, Eric 
--> Sent: Friday, October 21, 2005 6:39 AM
--> To: 'Developing a hybrid router/bridge.'; [email-masked]
--> Subject: RE: [rbridge] RBridge/bridge interaction
--> 
--> 
--> Guillermo,
--> 
--> 	Actually, the thing about a spanning tree is that frames entering
--> the tree will reach every node.  Hence the result of having an RBridge
--> be something other than the root of the local spanning tree would be 
--> that frame delivery might be sub-optimal.  In fact, it is not even
--> necessary for the R-Bridge to be directly connected to the root of a
--> local spanning tree.
--> 
--> 	That's part of the reason why an RBridge does not need to be a
--> part of the local STP.
--> 
--> 	Given the way that spanning tree works in general, sub-optimal 
--> delivery of frames would not be something new.  Having th
--> 
--> --
--> Eric
--> 
--> --> -----Original Message-----
--> --> From: [email-masked] 
--> --> [mailto:[email-masked]]On
--> --> Behalf Of Guillermo Ib??ez
--> --> Sent: Friday, October 21, 2005 2:33 AM
--> --> To: [email-masked]; Developing a hybrid router/bridge.
--> --> Subject: Re: [rbridge] RBridge/bridge interaction
--> --> 
--> --> 
--> --> 
--> --> I see the standard root election mechanism of spanning tree 
--> --> islands as 
--> --> the fastest and simpler mechanism for DR Rbridge 
--> --> designation. I see the 
--> --> DR Rbridge as being necessarily the ROOT bridge of  that 
--> --> sbridged cloud 
--> --> (or "link"). The root bridge of a standard spanning tree is the 
--> --> "natural" source and sink point for the spanning tree.  To 
--> --> do so, the DR 
--> --> must issue BPDUs to become the root bridge.  This is 
--> part of what I 
--> --> mentioned days ago as PARTICIPATE PER PORT, but may be we 
--> --> should call it 
--> --> SOURCE OR SINK (participate, do not forward BPDUs, only 
--> --> send own BPDUs 
--> --> to contend to be the root bridge of the link).
--> --> The consequence of this DR election mechanism is that 
--> the priority 
--> --> configured at Rbridges as bridge ID would determine their 
--> --> also their 
--> --> election priority as DRs. I think this keep both domains 
--> --> coordinated 
--> --> with a single mechanism.
--> --> Guillermo
--> --> 
--> --> Radia Perlman wrote:
--> --> 
--> --> >I don't believe there should be options here.
--> --> >It should be plug and play.
--> --> >RBridges should BLOCK bridge spanning tree messages,
--> --> >and isolate the bridged islands.
--> --> >
--> --> >I absolutely do not understand what people are
--> --> >worried about with BLOCK.
--> --> >
--> --> >I suggest someone that actually thinks there is
--> --> >some reason to do anything other than drop
--> --> >spanning tree messages start a thread with
--> --> >a subject line
--> --> >"why it is good for RBridges to forward BPDUs",
--> --> >and very very carefully explain from scratch
--> --> >what the reasoning is. Not with a long
--> --> >email quoting pieces of other emails, but
--> --> >with a carefully crafted, from scratch explanation
--> --> >of what you perceive as a problem with BLOCk, and
--> --> >what the perceived benefit of ever having
--> --> >RBridges forwarding BPDUs would
--> --> >be.
--> --> >
--> --> >Oh...and there was a much earlier thread of the
--> --> >thread about other devices that might forward
--> --> >or drop BPDUs. There have always been things we
--> --> >referred to as "simple bridges" that forwarded spanning
--> --> >tree messages. I was careful to ensure that the
--> --> >spanning tree would work with such devices. Of course
--> --> >the spanning tree would not prevent a loop of all
--> --> >simple bridges, but if there was at least one spanning
--> --> >tree bridge in the middle of every possible loop, then
--> --> >there would wind up being no loops.
--> --> >
--> --> >You can think of "simple bridges" (ones that mindlessly
--> --> >forward BPDUs) as a layer below bridges. They are
--> --> >invisible to bridges. Bridges see a bunch of
--> --> >segments connected by simple bridges as a single segment.
--> --> >(Just like RBridges will see a bunch of segments connected
--> --> >by bridges as a single segment).
--> --> >
--> --> >Devices that drop BDPUs work if they are really
--> --> >layered on top of bridges, i.e., they let the
--> --> >bridges do their own thing to create isolated
--> --> >broadcast domains, and then these other devices do
--> --> >their own thing to glue these islands together.
--> --> >Like routers do. And like RBridges will do.
--> --> >
--> --> >Radia
--> --> >
--> --> >
--> --> >
--> --> >Guillermo Ib??ez wrote On 10/20/05 14:35,:
--> --> >  
--> --> >
--> --> >>Eric,
--> --> >>
--> --> >>
--> --> >>Gray, Eric wrote:
--> --> >>
--> --> >>
--> --> >>    
--> --> >>
--> --> >>>Guillermo,
--> --> >>>
--> --> >>>	During the discussion, the terms TRANSPARENT, 
--> PARTICIPATE
--> --> >>>and BLOCK were used (often in upper-case, exactly as 
--> I have used
--> --> >>>them here) as if these would ultimately be options 
--> that might be
--> --> >>>supported - either as a complete set, or as some subset.  
--> --> >>>
--> --> >>>	For example, one argument was that TRANSPARENT 
--> or PARTICIPATE 
--> --> >>>might be used, but BLOCK should not.
--> --> >>>
--> --> >>>	Also, at certain points in the discussion, 
--> there was some
--> --> >>>thought that these might be modes that applied at 
--> --> different states
--> --> >>>during transitions in a network.
--> --> >>>
--> --> >>>	From a practical stand-point - however - it 
--> would be best if
--> --> >>>we did not have to support all of these, either as 
--> options, or as
--> --> >>>modes.  The mere fact that they were brought up does 
--> not mean we
--> --> >>>are committed to including them.
--> --> >>>
--> --> >>>
--> --> >>>
--> --> >>>      
--> --> >>>
--> --> >>Agreed
--> --> >>
--> --> >>
--> --> >>    
--> --> >>
--> --> >>>	In particular, if we start talking about - for 
--> instance -
--> --> >>>having a per-interface option for all of these 
--> choices (and maybe
--> --> >>>others as well), then we either need to analyze 
--> proposals for 
--> --> >>>architecture and design to ensure that the "right 
--> things" will
--> --> >>>happen when an arbitrary combination of all of these 
--> --> options is in 
--> --> >>>effect, or we need to define caveats for network 
--> --> operators to avoid 
--> --> >>>specific combinations of options.  For example, we may 
--> --> need to say
--> --> >>>that the same option must be set throughout the network 
--> --> or this and
--> --> >>>that will (or may) happen.  That kind of design begs 
--> --> configuration
--> --> >>>errors to occur.
--> --> >>>
--> --> >>>
--> --> >>>
--> --> >>>      
--> --> >>>
--> --> >>If you refer as configuration options per interface to 
--> --> the PARTICIPATE 
--> --> >>PER PORT mode as an option per port, it is not the case. 
--> --> If  you refer 
--> --> >>to being the DR the root bridge of the sbridge domain, I 
--> --> think it must 
--> --> >>be analyzed as a real alternative, even if it is not 
--> the default 
--> --> >>configuration.
--> --> >>
--> --> >>
--> --> >>    
--> --> >>
--> --> >>>	In this case, the fact that we want to make the 
--> solution plug
--> --> >>>and play means that we can reduce the potential for 
--> --> disaster if we
--> --> >>>choose (and require) a specific default set of option 
--> --> choices.  If
--> --> >>>we can get away with it, however, we should simply 
--> avoid options.
--> --> >>>
--> --> >>>
--> --> >>>
--> --> >>>      
--> --> >>>
--> --> >>Agreed, but not for the root bridge problem because is a 
--> --> real, practical 
--> --> >>issue.
--> --> >>
--> --> >>
--> --> >>    
--> --> >>
--> --> >>>	While having these same values as modes that 
--> apply during 
--> --> >>>certain transitional states is cleaner, it would 
--> require a well-
--> --> >>>defined finite state-machine (not a particular 
--> problem) and a 
--> --> >>>genuine need for these behaviors under certain 
--> circumstances.  It
--> --> >>>may well be the case that this turns out to be true.
--> --> >>>
--> --> >>>
--> --> >>>
--> --> >>>      
--> --> >>>
--> --> >>RSTP port state machines are there, may be they should be 
--> --> taken into 
--> --> >>consideration to make a consistent and integrated, but 
--> --> not interwoven, 
--> --> >>design for Rbridges that work with RSTP trees.
--> --> >>Guillermo. 
--> --> >>
--> --> >>
--> --> >>    
--> --> >>
--> --> >>>--
--> --> >>>Eric
--> --> >>>
--> --> >>>--> -----Original Message-----
--> --> >>>--> From: [email-masked] 
--> --> >>>--> [mailto:[email-masked]]On
--> --> >>>--> Behalf Of Guillermo Ib??ez
--> --> >>>--> Sent: Thursday, October 20, 2005 4:19 PM
--> --> >>>--> To: Developing a hybrid router/bridge.
--> --> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction
--> --> >>>--> 
--> --> >>>--> 
--> --> >>>--> I volunteer for some work on the capture, although my 
--> --> >>>--> english might be 
--> --> >>>--> not too understandable.  From what date should 
--> the capture 
--> --> >>>--> to be done?
--> --> >>>--> 
--> --> >>>--> Regarding PARTICIPATE PER PORT:
--> --> >>>--> Although I do not have a clear position, and it 
--> --> requires detailed 
--> --> >>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
--> --> >>>--> better integrated 
--> --> >>>--> with spanning tree, while maintaining the basic 
--> decoupling 
--> --> >>>--> that BLOCK 
--> --> >>>--> provides.
--> --> >>>--> With PARTICIPATE PER PORT it would be possible to 
--> --> force the elected 
--> --> >>>--> Rbridge to become the sbridge root of the 
--> bridged domain by 
--> --> >>>--> modifying 
--> --> >>>--> its bridge priority when it gets elected as 
--> Designated by 
--> --> >>>--> IS-IS (this 
--> --> >>>--> could be an optimization). In this way the path 
--> length is 
--> --> >>>--> minimum  from 
--> --> >>>--> all bridges of bridged domain to the DR.
--> --> >>>-->  
--> --> >>>--> 
--> --> >>>--> Erik Nordmark wrote:
--> --> >>>--> 
--> --> >>>--> >We've had some useful discussion on this mailing list.
--> --> >>>--> >It would be good if somebody can capture the results 
--> --> >>>--> (perhaps as a long 
--> --> >>>--> >email) that we can fold into the draft(s) later. 
--> --> Any volunteers?
--> --> >>>--> >
--> --> >>>--> >I don't know if we will have additional issues in this 
--> --> >>>--> space or that it 
--> --> >>>--> >otherwise makes sense devoting agenda time to it in 
--> --> Vancouver.
--> --> >>>--> >
--> --> >>>--> >For instance, while I'm convinced that BLOCK works, I 
--> --> >>>--> wonder if there is 
--> --> >>>--> >something in PARTICIPATE PER PORT that can make the 
--> --> >>>--> interaction work better.
--> --> >>>--> >
--> --> >>>--> >Two cases to consider:
--> --> >>>--> >1. The elected forwarder dies and a new one 
--> gets elected. 
--> --> >>>--> How quickly 
--> --> >>>--> >can packets sent by stations in the bridged cloud fail 
--> --> >>>--> over to go to the 
--> --> >>>--> >new elected forwarder?
--> --> >>>--> >
--> --> >>>--> >  
--> --> >>>--> >
--> --> >>>--> My understanding is that if the forwarded dies, the 
--> --> sbridge domain 
--> --> >>>--> should handle  it as  a topology change 
--> --> notification, tables   of 
--> --> >>>--> sbridges should be  flushed according to the 
--> spanning tree 
--> --> >>>--> rules, so the 
--> --> >>>--> sbridge domain must know the DR will not forward 
--> frames as 
--> --> >>>--> it used to. 
--> --> >>>--> It seems Rbridge shall issue a Topology Change 
--> Notification 
--> --> >>>--> via sbridge 
--> --> >>>--> domain to flush MAC tables. Is a fast analysis, 
--> probably I 
--> --> >>>--> miss details.
--> --> >>>-->  
--> --> >>>--> 
--> --> >>>--> >2. We have two separate bridged domains, each with 
--> --> their elected 
--> --> >>>--> >forwarder. Somebody connects the two bridged domains 
--> --> >>>--> together with a 
--> --> >>>--> >wire. This can cause a temporary loop until a single 
--> --> >>>--> elected forwarder 
--> --> >>>--> >is picked by the RBridges.
--> --> >>>--> >
--> --> >>>--> >  
--> --> >>>--> >
--> --> >>>--> In this case the PARTICIPATE PER PORT seems superior, as 
--> --> >>>--> the two merged 
--> --> >>>--> bridged domains will merge their spanning trees into one 
--> --> >>>--> and both DRs 
--> --> >>>--> will compete to be the root of the merged tree, this 
--> --> mechanism will 
--> --> >>>--> likely be faster (via RSTP fast transit to 
--> forwarding state 
--> --> >>>--> over the 
--> --> >>>--> bridged domain)  than  Designation to select the 
--> unique DR. 
--> --> >>>--> In other 
--> --> >>>--> words , the mechanism of root election in 
--> sbridge could be 
--> --> >>>--> used to help 
--> --> >>>--> in DR designation and/or viceversa.
--> --> >>>--> So I see in PARTICIPATE PER PORT, some coupling 
--> between DR 
--> --> >>>--> status and 
--> --> >>>--> root status of sbridge domain that can be used
--> --> >>>-->  to speed up convergence and coherence of both 
--> domains. It 
--> --> >>>--> seems that 
--> --> >>>--> sbridge domains should be under the control of  
--> --> Rbridges, but the 
--> --> >>>--> sbridge mechanims should be used by Rbridges to keep 
--> --> the network 
--> --> >>>--> consistency and reconfiguration capabilities of RSTP.
--> --> >>>--> Guillermo
--> --> >>>--> 
--> --> >>>-->  
--> --> >>>--> _______________________________________________
--> --> >>>--> rbridge mailing list
--> --> >>>--> [email-masked]
--> --> >>>--> http://www.postel.org/mailman/listinfo/rbridge
--> --> >>>--> 
--> --> >>>_______________________________________________
--> --> >>>rbridge mailing list
--> --> >>>[email-masked]
--> --> >>>http://www.postel.org/mailman/listinfo/rbridge
--> --> >>>
--> --> >>>
--> --> >>>
--> --> >>>      
--> --> >>>
--> --> >>_______________________________________________
--> --> >>rbridge mailing list
--> --> >>[email-masked]
--> --> >>http://www.postel.org/mailman/listinfo/rbridge
--> --> >>    
--> --> >>
--> --> >
--> --> >_______________________________________________
--> --> >rbridge mailing list
--> --> >[email-masked]
--> --> >http://www.postel.org/mailman/listinfo/rbridge
--> --> >
--> --> >  
--> --> >
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked]
--> --> http://www.postel.org/mailman/listinfo/rbridge
--> --> 
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>, [email-masked]
Date: Fri, 21 Oct 2005 07:38:41 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 12715

Guillermo,

	Actually, the thing about a spanning tree is that frames entering
the tree will reach every node.  Hence the result of having an RBridge
be something other than the root of the local spanning tree would be 
that frame delivery might be sub-optimal.  In fact, it is not even
necessary for the R-Bridge to be directly connected to the root of a
local spanning tree.

	That's part of the reason why an RBridge does not need to be a
part of the local STP.

	Given the way that spanning tree works in general, sub-optimal 
delivery of frames would not be something new.  Having th

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Friday, October 21, 2005 2:33 AM
--> To: [email-masked]; Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> 
--> I see the standard root election mechanism of spanning tree 
--> islands as 
--> the fastest and simpler mechanism for DR Rbridge 
--> designation. I see the 
--> DR Rbridge as being necessarily the ROOT bridge of  that 
--> sbridged cloud 
--> (or "link"). The root bridge of a standard spanning tree is the 
--> "natural" source and sink point for the spanning tree.  To 
--> do so, the DR 
--> must issue BPDUs to become the root bridge.  This is part of what I 
--> mentioned days ago as PARTICIPATE PER PORT, but may be we 
--> should call it 
--> SOURCE OR SINK (participate, do not forward BPDUs, only 
--> send own BPDUs 
--> to contend to be the root bridge of the link).
--> The consequence of this DR election mechanism is that the priority 
--> configured at Rbridges as bridge ID would determine their 
--> also their 
--> election priority as DRs. I think this keep both domains 
--> coordinated 
--> with a single mechanism.
--> Guillermo
--> 
--> Radia Perlman wrote:
--> 
--> >I don't believe there should be options here.
--> >It should be plug and play.
--> >RBridges should BLOCK bridge spanning tree messages,
--> >and isolate the bridged islands.
--> >
--> >I absolutely do not understand what people are
--> >worried about with BLOCK.
--> >
--> >I suggest someone that actually thinks there is
--> >some reason to do anything other than drop
--> >spanning tree messages start a thread with
--> >a subject line
--> >"why it is good for RBridges to forward BPDUs",
--> >and very very carefully explain from scratch
--> >what the reasoning is. Not with a long
--> >email quoting pieces of other emails, but
--> >with a carefully crafted, from scratch explanation
--> >of what you perceive as a problem with BLOCk, and
--> >what the perceived benefit of ever having
--> >RBridges forwarding BPDUs would
--> >be.
--> >
--> >Oh...and there was a much earlier thread of the
--> >thread about other devices that might forward
--> >or drop BPDUs. There have always been things we
--> >referred to as "simple bridges" that forwarded spanning
--> >tree messages. I was careful to ensure that the
--> >spanning tree would work with such devices. Of course
--> >the spanning tree would not prevent a loop of all
--> >simple bridges, but if there was at least one spanning
--> >tree bridge in the middle of every possible loop, then
--> >there would wind up being no loops.
--> >
--> >You can think of "simple bridges" (ones that mindlessly
--> >forward BPDUs) as a layer below bridges. They are
--> >invisible to bridges. Bridges see a bunch of
--> >segments connected by simple bridges as a single segment.
--> >(Just like RBridges will see a bunch of segments connected
--> >by bridges as a single segment).
--> >
--> >Devices that drop BDPUs work if they are really
--> >layered on top of bridges, i.e., they let the
--> >bridges do their own thing to create isolated
--> >broadcast domains, and then these other devices do
--> >their own thing to glue these islands together.
--> >Like routers do. And like RBridges will do.
--> >
--> >Radia
--> >
--> >
--> >
--> >Guillermo Ib??ez wrote On 10/20/05 14:35,:
--> >  
--> >
--> >>Eric,
--> >>
--> >>
--> >>Gray, Eric wrote:
--> >>
--> >>
--> >>    
--> >>
--> >>>Guillermo,
--> >>>
--> >>>	During the discussion, the terms TRANSPARENT, PARTICIPATE
--> >>>and BLOCK were used (often in upper-case, exactly as I have used
--> >>>them here) as if these would ultimately be options that might be
--> >>>supported - either as a complete set, or as some subset.  
--> >>>
--> >>>	For example, one argument was that TRANSPARENT or PARTICIPATE 
--> >>>might be used, but BLOCK should not.
--> >>>
--> >>>	Also, at certain points in the discussion, there was some
--> >>>thought that these might be modes that applied at 
--> different states
--> >>>during transitions in a network.
--> >>>
--> >>>	From a practical stand-point - however - it would be best if
--> >>>we did not have to support all of these, either as options, or as
--> >>>modes.  The mere fact that they were brought up does not mean we
--> >>>are committed to including them.
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>Agreed
--> >>
--> >>
--> >>    
--> >>
--> >>>	In particular, if we start talking about - for instance -
--> >>>having a per-interface option for all of these choices (and maybe
--> >>>others as well), then we either need to analyze proposals for 
--> >>>architecture and design to ensure that the "right things" will
--> >>>happen when an arbitrary combination of all of these 
--> options is in 
--> >>>effect, or we need to define caveats for network 
--> operators to avoid 
--> >>>specific combinations of options.  For example, we may 
--> need to say
--> >>>that the same option must be set throughout the network 
--> or this and
--> >>>that will (or may) happen.  That kind of design begs 
--> configuration
--> >>>errors to occur.
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>If you refer as configuration options per interface to 
--> the PARTICIPATE 
--> >>PER PORT mode as an option per port, it is not the case. 
--> If  you refer 
--> >>to being the DR the root bridge of the sbridge domain, I 
--> think it must 
--> >>be analyzed as a real alternative, even if it is not the default 
--> >>configuration.
--> >>
--> >>
--> >>    
--> >>
--> >>>	In this case, the fact that we want to make the solution plug
--> >>>and play means that we can reduce the potential for 
--> disaster if we
--> >>>choose (and require) a specific default set of option 
--> choices.  If
--> >>>we can get away with it, however, we should simply avoid options.
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>Agreed, but not for the root bridge problem because is a 
--> real, practical 
--> >>issue.
--> >>
--> >>
--> >>    
--> >>
--> >>>	While having these same values as modes that apply during 
--> >>>certain transitional states is cleaner, it would require a well-
--> >>>defined finite state-machine (not a particular problem) and a 
--> >>>genuine need for these behaviors under certain circumstances.  It
--> >>>may well be the case that this turns out to be true.
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>RSTP port state machines are there, may be they should be 
--> taken into 
--> >>consideration to make a consistent and integrated, but 
--> not interwoven, 
--> >>design for Rbridges that work with RSTP trees.
--> >>Guillermo. 
--> >>
--> >>
--> >>    
--> >>
--> >>>--
--> >>>Eric
--> >>>
--> >>>--> -----Original Message-----
--> >>>--> From: [email-masked] 
--> >>>--> [mailto:[email-masked]]On
--> >>>--> Behalf Of Guillermo Ib??ez
--> >>>--> Sent: Thursday, October 20, 2005 4:19 PM
--> >>>--> To: Developing a hybrid router/bridge.
--> >>>--> Subject: Re: [rbridge] RBridge/bridge interaction
--> >>>--> 
--> >>>--> 
--> >>>--> I volunteer for some work on the capture, although my 
--> >>>--> english might be 
--> >>>--> not too understandable.  From what date should the capture 
--> >>>--> to be done?
--> >>>--> 
--> >>>--> Regarding PARTICIPATE PER PORT:
--> >>>--> Although I do not have a clear position, and it 
--> requires detailed 
--> >>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
--> >>>--> better integrated 
--> >>>--> with spanning tree, while maintaining the basic decoupling 
--> >>>--> that BLOCK 
--> >>>--> provides.
--> >>>--> With PARTICIPATE PER PORT it would be possible to 
--> force the elected 
--> >>>--> Rbridge to become the sbridge root of the bridged domain by 
--> >>>--> modifying 
--> >>>--> its bridge priority when it gets elected as Designated by 
--> >>>--> IS-IS (this 
--> >>>--> could be an optimization). In this way the path length is 
--> >>>--> minimum  from 
--> >>>--> all bridges of bridged domain to the DR.
--> >>>-->  
--> >>>--> 
--> >>>--> Erik Nordmark wrote:
--> >>>--> 
--> >>>--> >We've had some useful discussion on this mailing list.
--> >>>--> >It would be good if somebody can capture the results 
--> >>>--> (perhaps as a long 
--> >>>--> >email) that we can fold into the draft(s) later. 
--> Any volunteers?
--> >>>--> >
--> >>>--> >I don't know if we will have additional issues in this 
--> >>>--> space or that it 
--> >>>--> >otherwise makes sense devoting agenda time to it in 
--> Vancouver.
--> >>>--> >
--> >>>--> >For instance, while I'm convinced that BLOCK works, I 
--> >>>--> wonder if there is 
--> >>>--> >something in PARTICIPATE PER PORT that can make the 
--> >>>--> interaction work better.
--> >>>--> >
--> >>>--> >Two cases to consider:
--> >>>--> >1. The elected forwarder dies and a new one gets elected. 
--> >>>--> How quickly 
--> >>>--> >can packets sent by stations in the bridged cloud fail 
--> >>>--> over to go to the 
--> >>>--> >new elected forwarder?
--> >>>--> >
--> >>>--> >  
--> >>>--> >
--> >>>--> My understanding is that if the forwarded dies, the 
--> sbridge domain 
--> >>>--> should handle  it as  a topology change 
--> notification, tables   of 
--> >>>--> sbridges should be  flushed according to the spanning tree 
--> >>>--> rules, so the 
--> >>>--> sbridge domain must know the DR will not forward frames as 
--> >>>--> it used to. 
--> >>>--> It seems Rbridge shall issue a Topology Change Notification 
--> >>>--> via sbridge 
--> >>>--> domain to flush MAC tables. Is a fast analysis, probably I 
--> >>>--> miss details.
--> >>>-->  
--> >>>--> 
--> >>>--> >2. We have two separate bridged domains, each with 
--> their elected 
--> >>>--> >forwarder. Somebody connects the two bridged domains 
--> >>>--> together with a 
--> >>>--> >wire. This can cause a temporary loop until a single 
--> >>>--> elected forwarder 
--> >>>--> >is picked by the RBridges.
--> >>>--> >
--> >>>--> >  
--> >>>--> >
--> >>>--> In this case the PARTICIPATE PER PORT seems superior, as 
--> >>>--> the two merged 
--> >>>--> bridged domains will merge their spanning trees into one 
--> >>>--> and both DRs 
--> >>>--> will compete to be the root of the merged tree, this 
--> mechanism will 
--> >>>--> likely be faster (via RSTP fast transit to forwarding state 
--> >>>--> over the 
--> >>>--> bridged domain)  than  Designation to select the unique DR. 
--> >>>--> In other 
--> >>>--> words , the mechanism of root election in sbridge could be 
--> >>>--> used to help 
--> >>>--> in DR designation and/or viceversa.
--> >>>--> So I see in PARTICIPATE PER PORT, some coupling between DR 
--> >>>--> status and 
--> >>>--> root status of sbridge domain that can be used
--> >>>-->  to speed up convergence and coherence of both domains. It 
--> >>>--> seems that 
--> >>>--> sbridge domains should be under the control of  
--> Rbridges, but the 
--> >>>--> sbridge mechanims should be used by Rbridges to keep 
--> the network 
--> >>>--> consistency and reconfiguration capabilities of RSTP.
--> >>>--> Guillermo
--> >>>--> 
--> >>>-->  
--> >>>--> _______________________________________________
--> >>>--> rbridge mailing list
--> >>>--> [email-masked]
--> >>>--> http://www.postel.org/mailman/listinfo/rbridge
--> >>>--> 
--> >>>_______________________________________________
--> >>>rbridge mailing list
--> >>>[email-masked]
--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>_______________________________________________
--> >>rbridge mailing list
--> >>[email-masked]
--> >>http://www.postel.org/mailman/listinfo/rbridge
--> >>    
--> >>
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >
--> >  
--> >
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Fri, 21 Oct 2005 00:29:33 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 13036

If you have to beat a horse, it's more humane to beat a dead one.

Yes...the whole idea of a tree is that each RBridge knows, for each 
port, which ports are
"in" or "out" of that particular spanning tree. If a port is "in" then 
you receive and forward multicasts onto
that port. If it's "out" then you neither receive multicasts or send 
multicasts on that port.

And I can't resist pointing out interesting technical tidbits...with the 
bridge spanning tree, the packets
go on all the links, even if no other bridges will be picking up the 
packet. Whereas with RBridges,
if the link-state-computed tree indicates no downstream receivers, then 
the packet is not sent onto
that port.

Radia

Larry Kreeger (kreeger) wrote:

>Radia,
>
>Sorry if I'm beating a dead horse.  It sounds like RB2 would receive the
>frame sent by RB1 to the "all RBridges" Ethernet DA, but would then know
>to drop it.  So, it sounds like RBridges will need some mechanisms to
>"block" ports on the "ingress spanning tree" of each RBridge sourcing
>broadcasts and multicasts - in other words for every RBridge in the
>network.
>
> - Larry
>
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Radia Perlman
>Sent: Thursday, October 20, 2005 11:07 AM
>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
>thread
>
>In the picture, it's clear it would have to go encapsulated over the
>bridged link. However, if that was just a subset of the topology, it
>might be the case that there is some other path to RB3 and RB4.
>
>It is possible that the shortest path tree to RB2 would be over the
>direct link, and the shortest path to RB3 and RB4 over the bridged link.
>
>In that case, RB1 would send it encapsulated over the bridged link, and
>RB3 and RB4 would receive it, but RB2 would not, since that port of RB2
>is not in the "ingress RB1 spanning tree".
>
>Radia
>
>
>
>Larry Kreeger (kreeger) wrote On 10/20/05 08:46,:
>  
>
>> Radia,
>>
>>OK, after I replied and re-read your reply, I realized that you must 
>>have been answering a different question.  That part made sense.
>>
>>I don't understand why it would be zero if the RBridge broadcast 
>>distribution tree from RB1 used the new link I added to between RB1 
>>and RB2.  It still needs to get to RB3 and RB4.  In this case, does 
>>the frame get multicast onto the Bridged link and discarded by RB2 due
>>    
>>
>
>  
>
>>to some type of RPF check, or is it multicast to a "RB3 and RB4" 
>>address, or does it get unicast twice to RB3 and RB4 respectively?  
>>I'm just trying to understand how many times the same frame goes 
>>across the Bridged network.  It seems like a minimum of once (just 
>>from A) if the RB's have less cost path reachability than the Bridged 
>>network, or up to
>>3 in the example I just gave.
>>
>>It seems like a good model for these links may be to model them as a 
>>single access link (iff a RB is the DR for the link) plus a tunnel 
>>link to every other RB on the link.
>>
>>Since Rbridges don't look at STP BPDUs, the RBs may use these tunnel 
>>links across any size of Bridged network, which would be sub-optimal.
>>Manual configuration would be needed to raise the link cost so that 
>>the RBridges would prefer links that were actually links, and not 
>>Bridged networks.  If they peaked into the BPDUs, they could probably 
>>figure this out themselves.
>>
>> - Larry
>>
>>From: [email-masked] [mailto:[email-masked]] 
>>On Behalf Of Radia Perlman
>>Sent: Wednesday, October 19, 2005 9:10 PM
>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>thread
>>
>>When I say "it is sent twice", I mean that the first time it is sent 
>>by A, natively. RB1 does not send it natively, just encapsulated. So 
>>perhaps I misparsed your question. I was answering "how many times 
>>does the packet get sent on that link" and from this question I guess 
>>you were asking "how many times does RB1 transmit the packet on the
>>    
>>
>link."
>  
>
>>The answer to THAT question is "once", and it will be encapsulated.
>>
>>Though with you extra link that you added now, it might be zero, 
>>depending on whether the spanning tree the RBridges calculated from 
>>the link state database, for ingress RBridge RB1, includes that link
>>    
>>
>or not.
>  
>
>>So, for your first question:
>>
>>
>>    
>>
>>>Why does RB1 send it onto the Bridged link with a "native" DA
>>>      
>>>
>>Broadcast?
>>
>>    
>>
>>>If, as you said, F will receive the frame directly from A, then 
>>>wouldn't this cause F to get two copies?
>>>
>>>      
>>>
>>No. RB1 does not send the packet natively. If it did, then F will 
>>receive two copies. But it doesn't. This misunderstanding is that I 
>>was answering a different question than you were asking, apparently.
>>
>>
>>For your second question:
>>
>>
>>    
>>
>>>Now, the broadcast distribution tree may be (and would probably be
>>>better) calculated to use the direct link between RB1--RB2 instead of 
>>>through the Bridged network.  Unfortunately, RB1 probably cannot tell 
>>>the difference between a direct connection and a Bridged network 
>>>connection, but let's say it chooses this link.  Now, wouldn't RB2 get
>>>      
>>>
>>    
>>
>>>two copies of the broadcast...or is there more to this - such as some 
>>>kind of RPF check that is needed.
>>>      
>>>
>>The RBridges use the link state database to calculate a tree of 
>>shortest paths from RB1. So packets only arrive once.
>>
>>Radia
>>
>>
>>
>>
>>Larry Kreeger (kreeger) wrote On 10/19/05 17:53,:
>>
>>    
>>
>>>Radia,
>>>
>>>Why does RB1 send it onto the Bridged link with a "native" DA
>>>      
>>>
>>Broadcast?
>>
>>    
>>
>>>If, as you said, F will receive the frame directly from A, then 
>>>wouldn't this cause F to get two copies?
>>>
>>>Also, I'm not sure if using an "all RBridges" DA would work if the 
>>>RBridges had other connectivity.  For example, if I add a link in the 
>>>topology between RB1 and RB2,
>>>
>>>
>>> B    C    D    E
>>> |    |    |    |
>>>RB1--RB2  RB3  RB4
>>> |    |    |    |
>>>---------------------
>>>     |           |
>>>     F           A
>>>
>>>Now, the broadcast distribution tree may be (and would probably be
>>>better) calculated to use the direct link between RB1--RB2 instead of 
>>>through the Bridged network.  Unfortunately, RB1 probably cannot tell 
>>>the difference between a direct connection and a Bridged network 
>>>connection, but let's say it chooses this link.  Now, wouldn't RB2 get
>>>      
>>>
>>    
>>
>>>two copies of the broadcast...or is there more to this - such as some 
>>>kind of RPF check that is needed.
>>>
>>>- Larry
>>>
>>>From: Radia Perlman [mailto:[email-masked]]
>>>Sent: Wednesday, October 19, 2005 4:24 PM
>>>To: Larry Kreeger (kreeger)
>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>>thread
>>>
>>>It is sent twice.
>>>The first time it is "native", with DA=broadcast
>>>
>>>The second time is encapsulated by RB1, so the packet has outer header
>>>      
>>>
>>    
>>
>>>DA="all RBridges", a shim header with "ingress=RB1", and the inner 
>>>packet being exactly as transmitted by A.
>>>
>>>Onto other links though...RB1 will transmit it to B unencapsulated, 
>>>i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and
>>>RB4 to E.
>>>
>>>And just a note...in case there were other endnodes on the bridged 
>>>link, the RBridges don't worry about it...those endnodes receive the 
>>>packet directly from A.
>>>
>>>So, for instance, F below will receive the packet when A transmitted
>>>      
>>>
>>it.
>>
>>    
>>
>>> B    C    D    E
>>> |    |    |    |
>>>RB1  RB2  RB3  RB4
>>> |    |    |    |
>>>---------------------
>>>     |           |
>>>     F           A
>>>
>>>
>>>
>>>Radia
>>>
>>>
>>>
>>>
>>>
>>>Larry Kreeger (kreeger) wrote On 10/19/05 16:17,:
>>>
>>>
>>>      
>>>
>>>>Radia,
>>>>
>>>>In Step 6, is the frame sent onto the link between RB1 and B1 once or
>>>>3 times?  If once, what is the Ethernet DA?
>>>>
>>>>Thanks, Larry
>>>>
>>>>From: [email-masked] [mailto:[email-masked]]
>>>>On Behalf Of Radia Perlman
>>>>Sent: Wednesday, October 19, 2005 3:57 PM
>>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>>>thread
>>>>
>>>>Step 1: The bridges create a single broadcast domain, as seen by the 
>>>>RBridges. So the RBridges see the following picture:
>>>>
>>>>B    C    D    E
>>>>|    |    |    |
>>>>RB1  RB2  RB3  RB4
>>>>|    |    |    |
>>>>---------------------
>>>>               |
>>>>               A
>>>>
>>>>Step 2: RB1 is elected DR, so it is the only one that will 
>>>>encapsulate
>>>>        
>>>>
>>>      
>>>
>>>>or decapsulate to/from that link.
>>>>
>>>>Step 3: A transmits a broadcast or multicast packet
>>>>
>>>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since 
>>>>they are not allowed to process native (non-encapsulated) packets
>>>>
>>>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress
>>>>        
>>>>
>>>RB1"
>>>
>>>
>>>      
>>>
>>>>Step 6: RB1 forwards the encapsulated packet onto the link, with an 
>>>>outer header with a multicast address "all RBridges"
>>>>
>>>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it 
>>>>in order to send to their upward link (to C, D, and E, respectively).
>>>>
>>>>Step 8: (which could certainly happen after 5 or 6...doesn't have to 
>>>>be in order). RB1 decapsulates the packet and sends it to B.
>>>>
>>>>************
>>>>Hope that helps...
>>>>
>>>>Radia
>>>>
>>>>
>>>>
>>>>
>>>>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Radia,
>>>>>
>>>>>I think I now understand now that the DR election happens only 
>>>>>between
>>>>>          
>>>>>
>>>>        
>>>>
>>>>>RBridges on a single shared link - and does not require usage of any
>>>>>          
>>>>>
>
>  
>
>>>>>RBridge topology information.  It would help clarify the data flow 
>>>>>for
>>>>>          
>>>>>
>>>>        
>>>>
>>>>>me (and hopefully others) if, given the network diagram below, you 
>>>>>could please give a step by step description of how a broadcast 
>>>>>frame
>>>>>          
>>>>>
>>    
>>
>>>>>sent by host A gets through each Bridge and RBridge in this network 
>>>>>in
>>>>>          
>>>>>
>>>>        
>>>>
>>>>>order to be received by hosts B,C,D,E if we assume that RB1 is the 
>>>>>Designated RBridge on the "link" created by the Bridged network 
>>>>>formed
>>>>>          
>>>>>
>>>>        
>>>>
>>>>>by Bridges B1,B2,B3,B4.
>>>>>
>>>>>B    C    D    E
>>>>>|    |    |    |
>>>>>RB1  RB2  RB3  RB4
>>>>>|    |    |    |
>>>>>B1---B2---B3---B4
>>>>>              |
>>>>>              A
>>>>>
>>>>>Thanks, Larry
>>>>>
>>>>>From: [email-masked] [mailto:[email-masked]]
>>>>>On Behalf Of Radia Perlman
>>>>>Sent: Wednesday, October 19, 2005 9:57 AM
>>>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
>>>>>          
>>>>>
>
>  
>
>>>>>thread
>>>>>
>>>>>The IS-IS Hello protocol is for electing a single unique switch per 
>>>>>link. It doesn't matter which one it is.
>>>>>
>>>>>On the other hand, the spanning tree protocol is picking a special 
>>>>>single unique bridge per link...the one that is closest to the root.
>>>>>
>>>>>The spanning tree algorithm is choosing a tree of shortest paths 
>>>>>from
>>>>>          
>>>>>
>>    
>>
>>>>>the root.
>>>>>
>>>>>IS-IS is not trying to do that. It is just electing one guy on a 
>>>>>link
>>>>>          
>>>>>
>>    
>>
>>>>>to do special link-specific things.
>>>>>
>>>>>Radia
>>>>>[email-masked]
>>>>[email-masked]
>>>[email-masked]
>>[email-masked]
>>[email-masked]
>[email-masked]
>[email-masked]

Date: Fri, 21 Oct 2005 00:25:40 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 12230

I don't think there's any reason, even if most of the traffic on the 
link comes from the DR, for the
DR to be the root of the spanning tree.
What would be bad is if an RBridge, participating in two bridged 
islands, winds up merging
the islands into a bigger island.

The whole point is to make the bridged islands as small as possible, so 
most forwarding is done
protected by hop count, and with optimal routes.

I'll admit that having RBridges *initiate* BPDUs
to vie for being Root is not as harmful as having them *forward* BPDUs 
between
bridged islands (provided an RBridge is careful not to merge two islands 
that would
have been separate if the RBridge had just been blocking BPDUs).

We shouldn't make things more complex in an attempt to come up with a 
"more optimal"
spanning tree within the bridged islands.
With a bidirectional tree, as happens with bridges, there's nothing 
special about the Root.
Also, the traffic pattern might be such that most of the traffic is 
between endnodes within
the island. So there's really no reason to believe that having the 
RBridge DR be the
spanning tree Root will result in better performance. And is certainly 
complicates things.
And it also certainly is dangerous because of the potential of merging 
islands.

Radia

Guillermo Ib??ez wrote:

>I see the standard root election mechanism of spanning tree islands as 
>the fastest and simpler mechanism for DR Rbridge designation. I see the 
>DR Rbridge as being necessarily the ROOT bridge of  that sbridged cloud 
>(or "link"). The root bridge of a standard spanning tree is the 
>"natural" source and sink point for the spanning tree.  To do so, the DR 
>must issue BPDUs to become the root bridge.  This is part of what I 
>mentioned days ago as PARTICIPATE PER PORT, but may be we should call it 
>SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs 
>to contend to be the root bridge of the link).
>The consequence of this DR election mechanism is that the priority 
>configured at Rbridges as bridge ID would determine their also their 
>election priority as DRs. I think this keep both domains coordinated 
>with a single mechanism.
>Guillermo
>
>Radia Perlman wrote:
>
>  
>
>>I don't believe there should be options here.
>>It should be plug and play.
>>RBridges should BLOCK bridge spanning tree messages,
>>and isolate the bridged islands.
>>
>>I absolutely do not understand what people are
>>worried about with BLOCK.
>>
>>I suggest someone that actually thinks there is
>>some reason to do anything other than drop
>>spanning tree messages start a thread with
>>a subject line
>>"why it is good for RBridges to forward BPDUs",
>>and very very carefully explain from scratch
>>what the reasoning is. Not with a long
>>email quoting pieces of other emails, but
>>with a carefully crafted, from scratch explanation
>>of what you perceive as a problem with BLOCk, and
>>what the perceived benefit of ever having
>>RBridges forwarding BPDUs would
>>be.
>>
>>Oh...and there was a much earlier thread of the
>>thread about other devices that might forward
>>or drop BPDUs. There have always been things we
>>referred to as "simple bridges" that forwarded spanning
>>tree messages. I was careful to ensure that the
>>spanning tree would work with such devices. Of course
>>the spanning tree would not prevent a loop of all
>>simple bridges, but if there was at least one spanning
>>tree bridge in the middle of every possible loop, then
>>there would wind up being no loops.
>>
>>You can think of "simple bridges" (ones that mindlessly
>>forward BPDUs) as a layer below bridges. They are
>>invisible to bridges. Bridges see a bunch of
>>segments connected by simple bridges as a single segment.
>>(Just like RBridges will see a bunch of segments connected
>>by bridges as a single segment).
>>
>>Devices that drop BDPUs work if they are really
>>layered on top of bridges, i.e., they let the
>>bridges do their own thing to create isolated
>>broadcast domains, and then these other devices do
>>their own thing to glue these islands together.
>>Like routers do. And like RBridges will do.
>>
>>Radia
>>
>>
>>
>>Guillermo Ib??ez wrote On 10/20/05 14:35,:
>> 
>>
>>    
>>
>>>Eric,
>>>
>>>
>>>Gray, Eric wrote:
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>Guillermo,
>>>>
>>>>	During the discussion, the terms TRANSPARENT, PARTICIPATE
>>>>and BLOCK were used (often in upper-case, exactly as I have used
>>>>them here) as if these would ultimately be options that might be
>>>>supported - either as a complete set, or as some subset.  
>>>>
>>>>	For example, one argument was that TRANSPARENT or PARTICIPATE 
>>>>might be used, but BLOCK should not.
>>>>
>>>>	Also, at certain points in the discussion, there was some
>>>>thought that these might be modes that applied at different states
>>>>during transitions in a network.
>>>>
>>>>	From a practical stand-point - however - it would be best if
>>>>we did not have to support all of these, either as options, or as
>>>>modes.  The mere fact that they were brought up does not mean we
>>>>are committed to including them.
>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>Agreed
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>	In particular, if we start talking about - for instance -
>>>>having a per-interface option for all of these choices (and maybe
>>>>others as well), then we either need to analyze proposals for 
>>>>architecture and design to ensure that the "right things" will
>>>>happen when an arbitrary combination of all of these options is in 
>>>>effect, or we need to define caveats for network operators to avoid 
>>>>specific combinations of options.  For example, we may need to say
>>>>that the same option must be set throughout the network or this and
>>>>that will (or may) happen.  That kind of design begs configuration
>>>>errors to occur.
>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>If you refer as configuration options per interface to the PARTICIPATE 
>>>PER PORT mode as an option per port, it is not the case. If  you refer 
>>>to being the DR the root bridge of the sbridge domain, I think it must 
>>>be analyzed as a real alternative, even if it is not the default 
>>>configuration.
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>	In this case, the fact that we want to make the solution plug
>>>>and play means that we can reduce the potential for disaster if we
>>>>choose (and require) a specific default set of option choices.  If
>>>>we can get away with it, however, we should simply avoid options.
>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>Agreed, but not for the root bridge problem because is a real, practical 
>>>issue.
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>	While having these same values as modes that apply during 
>>>>certain transitional states is cleaner, it would require a well-
>>>>defined finite state-machine (not a particular problem) and a 
>>>>genuine need for these behaviors under certain circumstances.  It
>>>>may well be the case that this turns out to be true.
>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>RSTP port state machines are there, may be they should be taken into 
>>>consideration to make a consistent and integrated, but not interwoven, 
>>>design for Rbridges that work with RSTP trees.
>>>Guillermo. 
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>--
>>>>Eric
>>>>
>>>>--> -----Original Message-----
>>>>--> From: [email-masked] 
>>>>--> [mailto:[email-masked]]On
>>>>--> Behalf Of Guillermo Ib??ez
>>>>--> Sent: Thursday, October 20, 2005 4:19 PM
>>>>--> To: Developing a hybrid router/bridge.
>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction
>>>>--> 
>>>>--> 
>>>>--> I volunteer for some work on the capture, although my 
>>>>--> english might be 
>>>>--> not too understandable.  From what date should the capture 
>>>>--> to be done?
>>>>--> 
>>>>--> Regarding PARTICIPATE PER PORT:
>>>>--> Although I do not have a clear position, and it requires detailed 
>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
>>>>--> better integrated 
>>>>--> with spanning tree, while maintaining the basic decoupling 
>>>>--> that BLOCK 
>>>>--> provides.
>>>>--> With PARTICIPATE PER PORT it would be possible to force the elected 
>>>>--> Rbridge to become the sbridge root of the bridged domain by 
>>>>--> modifying 
>>>>--> its bridge priority when it gets elected as Designated by 
>>>>--> IS-IS (this 
>>>>--> could be an optimization). In this way the path length is 
>>>>--> minimum  from 
>>>>--> all bridges of bridged domain to the DR.
>>>>-->  
>>>>--> 
>>>>--> Erik Nordmark wrote:
>>>>--> 
>>>>--> >We've had some useful discussion on this mailing list.
>>>>--> >It would be good if somebody can capture the results 
>>>>--> (perhaps as a long 
>>>>--> >email) that we can fold into the draft(s) later. Any volunteers?
>>>>--> >
>>>>--> >I don't know if we will have additional issues in this 
>>>>--> space or that it 
>>>>--> >otherwise makes sense devoting agenda time to it in Vancouver.
>>>>--> >
>>>>--> >For instance, while I'm convinced that BLOCK works, I 
>>>>--> wonder if there is 
>>>>--> >something in PARTICIPATE PER PORT that can make the 
>>>>--> interaction work better.
>>>>--> >
>>>>--> >Two cases to consider:
>>>>--> >1. The elected forwarder dies and a new one gets elected. 
>>>>--> How quickly 
>>>>--> >can packets sent by stations in the bridged cloud fail 
>>>>--> over to go to the 
>>>>--> >new elected forwarder?
>>>>--> >
>>>>--> >  
>>>>--> >
>>>>--> My understanding is that if the forwarded dies, the sbridge domain 
>>>>--> should handle  it as  a topology change notification, tables   of 
>>>>--> sbridges should be  flushed according to the spanning tree 
>>>>--> rules, so the 
>>>>--> sbridge domain must know the DR will not forward frames as 
>>>>--> it used to. 
>>>>--> It seems Rbridge shall issue a Topology Change Notification 
>>>>--> via sbridge 
>>>>--> domain to flush MAC tables. Is a fast analysis, probably I 
>>>>--> miss details.
>>>>-->  
>>>>--> 
>>>>--> >2. We have two separate bridged domains, each with their elected 
>>>>--> >forwarder. Somebody connects the two bridged domains 
>>>>--> together with a 
>>>>--> >wire. This can cause a temporary loop until a single 
>>>>--> elected forwarder 
>>>>--> >is picked by the RBridges.
>>>>--> >
>>>>--> >  
>>>>--> >
>>>>--> In this case the PARTICIPATE PER PORT seems superior, as 
>>>>--> the two merged 
>>>>--> bridged domains will merge their spanning trees into one 
>>>>--> and both DRs 
>>>>--> will compete to be the root of the merged tree, this mechanism will 
>>>>--> likely be faster (via RSTP fast transit to forwarding state 
>>>>--> over the 
>>>>--> bridged domain)  than  Designation to select the unique DR. 
>>>>--> In other 
>>>>--> words , the mechanism of root election in sbridge could be 
>>>>--> used to help 
>>>>--> in DR designation and/or viceversa.
>>>>--> So I see in PARTICIPATE PER PORT, some coupling between DR 
>>>>--> status and 
>>>>--> root status of sbridge domain that can be used
>>>>-->  to speed up convergence and coherence of both domains. It 
>>>>--> seems that 
>>>>--> sbridge domains should be under the control of  Rbridges, but the 
>>>>--> sbridge mechanims should be used by Rbridges to keep the network 
>>>>--> consistency and reconfiguration capabilities of RSTP.
>>>>--> Guillermo
>>>>--> 
>>>>-->  
>>>>--> _______________________________________________
>>>>--> rbridge mailing list
>>>>--> [email-masked]
>>>>--> http://www.postel.org/mailman/listinfo/rbridge
>>>>--> 
>>>>[email-masked]
>>>[email-masked]
>>[email-masked]
>[email-masked]

Date: Fri, 21 Oct 2005 08:33:01 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10301

I see the standard root election mechanism of spanning tree islands as 
the fastest and simpler mechanism for DR Rbridge designation. I see the 
DR Rbridge as being necessarily the ROOT bridge of  that sbridged cloud 
(or "link"). The root bridge of a standard spanning tree is the 
"natural" source and sink point for the spanning tree.  To do so, the DR 
must issue BPDUs to become the root bridge.  This is part of what I 
mentioned days ago as PARTICIPATE PER PORT, but may be we should call it 
SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs 
to contend to be the root bridge of the link).
The consequence of this DR election mechanism is that the priority 
configured at Rbridges as bridge ID would determine their also their 
election priority as DRs. I think this keep both domains coordinated 
with a single mechanism.
Guillermo

Radia Perlman wrote:

>I don't believe there should be options here.
>It should be plug and play.
>RBridges should BLOCK bridge spanning tree messages,
>and isolate the bridged islands.
>
>I absolutely do not understand what people are
>worried about with BLOCK.
>
>I suggest someone that actually thinks there is
>some reason to do anything other than drop
>spanning tree messages start a thread with
>a subject line
>"why it is good for RBridges to forward BPDUs",
>and very very carefully explain from scratch
>what the reasoning is. Not with a long
>email quoting pieces of other emails, but
>with a carefully crafted, from scratch explanation
>of what you perceive as a problem with BLOCk, and
>what the perceived benefit of ever having
>RBridges forwarding BPDUs would
>be.
>
>Oh...and there was a much earlier thread of the
>thread about other devices that might forward
>or drop BPDUs. There have always been things we
>referred to as "simple bridges" that forwarded spanning
>tree messages. I was careful to ensure that the
>spanning tree would work with such devices. Of course
>the spanning tree would not prevent a loop of all
>simple bridges, but if there was at least one spanning
>tree bridge in the middle of every possible loop, then
>there would wind up being no loops.
>
>You can think of "simple bridges" (ones that mindlessly
>forward BPDUs) as a layer below bridges. They are
>invisible to bridges. Bridges see a bunch of
>segments connected by simple bridges as a single segment.
>(Just like RBridges will see a bunch of segments connected
>by bridges as a single segment).
>
>Devices that drop BDPUs work if they are really
>layered on top of bridges, i.e., they let the
>bridges do their own thing to create isolated
>broadcast domains, and then these other devices do
>their own thing to glue these islands together.
>Like routers do. And like RBridges will do.
>
>Radia
>
>
>
>Guillermo Ib??ez wrote On 10/20/05 14:35,:
>  
>
>>Eric,
>>
>>
>>Gray, Eric wrote:
>>
>>
>>    
>>
>>>Guillermo,
>>>
>>>	During the discussion, the terms TRANSPARENT, PARTICIPATE
>>>and BLOCK were used (often in upper-case, exactly as I have used
>>>them here) as if these would ultimately be options that might be
>>>supported - either as a complete set, or as some subset.  
>>>
>>>	For example, one argument was that TRANSPARENT or PARTICIPATE 
>>>might be used, but BLOCK should not.
>>>
>>>	Also, at certain points in the discussion, there was some
>>>thought that these might be modes that applied at different states
>>>during transitions in a network.
>>>
>>>	From a practical stand-point - however - it would be best if
>>>we did not have to support all of these, either as options, or as
>>>modes.  The mere fact that they were brought up does not mean we
>>>are committed to including them.
>>>
>>>
>>>
>>>      
>>>
>>Agreed
>>
>>
>>    
>>
>>>	In particular, if we start talking about - for instance -
>>>having a per-interface option for all of these choices (and maybe
>>>others as well), then we either need to analyze proposals for 
>>>architecture and design to ensure that the "right things" will
>>>happen when an arbitrary combination of all of these options is in 
>>>effect, or we need to define caveats for network operators to avoid 
>>>specific combinations of options.  For example, we may need to say
>>>that the same option must be set throughout the network or this and
>>>that will (or may) happen.  That kind of design begs configuration
>>>errors to occur.
>>>
>>>
>>>
>>>      
>>>
>>If you refer as configuration options per interface to the PARTICIPATE 
>>PER PORT mode as an option per port, it is not the case. If  you refer 
>>to being the DR the root bridge of the sbridge domain, I think it must 
>>be analyzed as a real alternative, even if it is not the default 
>>configuration.
>>
>>
>>    
>>
>>>	In this case, the fact that we want to make the solution plug
>>>and play means that we can reduce the potential for disaster if we
>>>choose (and require) a specific default set of option choices.  If
>>>we can get away with it, however, we should simply avoid options.
>>>
>>>
>>>
>>>      
>>>
>>Agreed, but not for the root bridge problem because is a real, practical 
>>issue.
>>
>>
>>    
>>
>>>	While having these same values as modes that apply during 
>>>certain transitional states is cleaner, it would require a well-
>>>defined finite state-machine (not a particular problem) and a 
>>>genuine need for these behaviors under certain circumstances.  It
>>>may well be the case that this turns out to be true.
>>>
>>>
>>>
>>>      
>>>
>>RSTP port state machines are there, may be they should be taken into 
>>consideration to make a consistent and integrated, but not interwoven, 
>>design for Rbridges that work with RSTP trees.
>>Guillermo. 
>>
>>
>>    
>>
>>>--
>>>Eric
>>>
>>>--> -----Original Message-----
>>>--> From: [email-masked] 
>>>--> [mailto:[email-masked]]On
>>>--> Behalf Of Guillermo Ib??ez
>>>--> Sent: Thursday, October 20, 2005 4:19 PM
>>>--> To: Developing a hybrid router/bridge.
>>>--> Subject: Re: [rbridge] RBridge/bridge interaction
>>>--> 
>>>--> 
>>>--> I volunteer for some work on the capture, although my 
>>>--> english might be 
>>>--> not too understandable.  From what date should the capture 
>>>--> to be done?
>>>--> 
>>>--> Regarding PARTICIPATE PER PORT:
>>>--> Although I do not have a clear position, and it requires detailed 
>>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
>>>--> better integrated 
>>>--> with spanning tree, while maintaining the basic decoupling 
>>>--> that BLOCK 
>>>--> provides.
>>>--> With PARTICIPATE PER PORT it would be possible to force the elected 
>>>--> Rbridge to become the sbridge root of the bridged domain by 
>>>--> modifying 
>>>--> its bridge priority when it gets elected as Designated by 
>>>--> IS-IS (this 
>>>--> could be an optimization). In this way the path length is 
>>>--> minimum  from 
>>>--> all bridges of bridged domain to the DR.
>>>-->  
>>>--> 
>>>--> Erik Nordmark wrote:
>>>--> 
>>>--> >We've had some useful discussion on this mailing list.
>>>--> >It would be good if somebody can capture the results 
>>>--> (perhaps as a long 
>>>--> >email) that we can fold into the draft(s) later. Any volunteers?
>>>--> >
>>>--> >I don't know if we will have additional issues in this 
>>>--> space or that it 
>>>--> >otherwise makes sense devoting agenda time to it in Vancouver.
>>>--> >
>>>--> >For instance, while I'm convinced that BLOCK works, I 
>>>--> wonder if there is 
>>>--> >something in PARTICIPATE PER PORT that can make the 
>>>--> interaction work better.
>>>--> >
>>>--> >Two cases to consider:
>>>--> >1. The elected forwarder dies and a new one gets elected. 
>>>--> How quickly 
>>>--> >can packets sent by stations in the bridged cloud fail 
>>>--> over to go to the 
>>>--> >new elected forwarder?
>>>--> >
>>>--> >  
>>>--> >
>>>--> My understanding is that if the forwarded dies, the sbridge domain 
>>>--> should handle  it as  a topology change notification, tables   of 
>>>--> sbridges should be  flushed according to the spanning tree 
>>>--> rules, so the 
>>>--> sbridge domain must know the DR will not forward frames as 
>>>--> it used to. 
>>>--> It seems Rbridge shall issue a Topology Change Notification 
>>>--> via sbridge 
>>>--> domain to flush MAC tables. Is a fast analysis, probably I 
>>>--> miss details.
>>>-->  
>>>--> 
>>>--> >2. We have two separate bridged domains, each with their elected 
>>>--> >forwarder. Somebody connects the two bridged domains 
>>>--> together with a 
>>>--> >wire. This can cause a temporary loop until a single 
>>>--> elected forwarder 
>>>--> >is picked by the RBridges.
>>>--> >
>>>--> >  
>>>--> >
>>>--> In this case the PARTICIPATE PER PORT seems superior, as 
>>>--> the two merged 
>>>--> bridged domains will merge their spanning trees into one 
>>>--> and both DRs 
>>>--> will compete to be the root of the merged tree, this mechanism will 
>>>--> likely be faster (via RSTP fast transit to forwarding state 
>>>--> over the 
>>>--> bridged domain)  than  Designation to select the unique DR. 
>>>--> In other 
>>>--> words , the mechanism of root election in sbridge could be 
>>>--> used to help 
>>>--> in DR designation and/or viceversa.
>>>--> So I see in PARTICIPATE PER PORT, some coupling between DR 
>>>--> status and 
>>>--> root status of sbridge domain that can be used
>>>-->  to speed up convergence and coherence of both domains. It 
>>>--> seems that 
>>>--> sbridge domains should be under the control of  Rbridges, but the 
>>>--> sbridge mechanims should be used by Rbridges to keep the network 
>>>--> consistency and reconfiguration capabilities of RSTP.
>>>--> Guillermo
>>>--> 
>>>-->  
>>>--> _______________________________________________
>>>--> rbridge mailing list
>>>--> [email-masked]
>>>--> http://www.postel.org/mailman/listinfo/rbridge
>>>--> 
>>>[email-masked]
>>[email-masked]
>[email-masked]

Content-class: urn:content-classes:message
Date: Thu, 20 Oct 2005 22:45:28 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 466

> 
> 	During the discussion, the terms TRANSPARENT, PARTICIPATE
> and BLOCK were used (often in upper-case, exactly as I have 
> used them here) as if these would ultimately be options that 
> might be supported - either as a complete set, or as some subset.  

  I am guilty of introducing those terms but it was not with the
intention that they be options but to give concrete terms to the
different points of view that were being debated. 

  Peter Ashwood-Smith

Content-class: urn:content-classes:message
Date: Thu, 20 Oct 2005 17:45:39 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
To: <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9203

Are multicasts also carried over edge rbridge's
per-rbridge-spanning-tree ..? 

If so, assuming all entities (RBx, host A & F) are interested in a
particular multicast group G1, what outer address is used  (for the same
topology discussed in this thread) for multicast originating from host A
..? As I understand multicasts also go on a per-rbridge-spanning-tree.
What outer address would be used by RB1 such that RB3 & RB4 understand
it's a TRILL encpasulated packet, and is a multicast, but at the same
time, such a packet should be thrown away by host F. 

Also, if an IGMP packet seen by any designated rbridge, is sent as a
broadcast to other rbridges, over that rbridge's spanning tree, then I
don't think *traditional* IGMP snooping would work to form the {S,G}
multicast state. (where S == source rbridge). 

-Sanjay

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Radia Perlman
>Sent: Wednesday, October 19, 2005 9:10 PM
>Subject: Re: [rbridge] FW: Time to summarize "forward or 
>block" BPDU thread
>
>When I say "it is sent twice", I mean that the first time it 
>is sent by A, natively. RB1 does not send it natively, just 
>encapsulated. So perhaps I misparsed your question. I was 
>answering "how many times does the packet get sent on that 
>link" and from this question I guess you were asking "how many 
>times does RB1 transmit the packet on the link."
>
>The answer to THAT question is "once", and it will be encapsulated.
>
>Though with you extra link that you added now, it might be 
>zero, depending on whether the spanning tree the RBridges 
>calculated from the link state database, for ingress RBridge 
>RB1, includes that link or not.
>
>So, for your first question:
>
>> Why does RB1 send it onto the Bridged link with a "native" 
>DA Broadcast?
>> If, as you said, F will receive the frame directly from A, then 
>> wouldn't this cause F to get two copies?
>>
>
>No. RB1 does not send the packet natively. If it did, then F 
>will receive two copies. But it doesn't. This misunderstanding 
>is that I was answering a different question than you were 
>asking, apparently.
>
>
>For your second question:
>
>> Now, the broadcast distribution tree may be (and would probably be
>> better) calculated to use the direct link between RB1--RB2 
>instead of 
>> through the Bridged network.  Unfortunately, RB1 probably 
>cannot tell 
>> the difference between a direct connection and a Bridged network 
>> connection, but let's say it chooses this link.  Now, 
>wouldn't RB2 get 
>> two copies of the broadcast...or is there more to this - 
>such as some 
>> kind of RPF check that is needed.
>
>The RBridges use the link state database to calculate a tree 
>of shortest paths from RB1. So packets only arrive once.
>
>Radia
>
>
>
>
>Larry Kreeger (kreeger) wrote On 10/19/05 17:53,:
>> Radia,
>> 
>> Why does RB1 send it onto the Bridged link with a "native" 
>DA Broadcast?
>> If, as you said, F will receive the frame directly from A, then 
>> wouldn't this cause F to get two copies?
>> 
>> Also, I'm not sure if using an "all RBridges" DA would work if the 
>> RBridges had other connectivity.  For example, if I add a 
>link in the 
>> topology between RB1 and RB2,
>> 
>>  
>>   B    C    D    E
>>   |    |    |    |
>>  RB1--RB2  RB3  RB4
>>   |    |    |    |
>>  ---------------------
>>       |           |
>>       F           A
>> 
>> Now, the broadcast distribution tree may be (and would probably be
>> better) calculated to use the direct link between RB1--RB2 
>instead of 
>> through the Bridged network.  Unfortunately, RB1 probably 
>cannot tell 
>> the difference between a direct connection and a Bridged network 
>> connection, but let's say it chooses this link.  Now, 
>wouldn't RB2 get 
>> two copies of the broadcast...or is there more to this - 
>such as some 
>> kind of RPF check that is needed.
>> 
>>  - Larry
>> 
>> From: Radia Perlman [mailto:[email-masked]]
>> Sent: Wednesday, October 19, 2005 4:24 PM
>> To: Larry Kreeger (kreeger)
>> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>> thread
>> 
>> It is sent twice.
>> The first time it is "native", with DA=broadcast
>> 
>> The second time is encapsulated by RB1, so the packet has 
>outer header 
>> DA="all RBridges", a shim header with "ingress=RB1", and the inner 
>> packet being exactly as transmitted by A.
>> 
>> Onto other links though...RB1 will transmit it to B unencapsulated, 
>> i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and 
>> RB4 to E.
>> 
>> And just a note...in case there were other endnodes on the bridged 
>> link, the RBridges don't worry about it...those endnodes receive the 
>> packet directly from A.
>> 
>> So, for instance, F below will receive the packet when A 
>transmitted it.
>> 
>>   B    C    D    E
>>   |    |    |    |
>>  RB1  RB2  RB3  RB4
>>   |    |    |    |
>>  ---------------------
>>       |           |
>>       F           A
>> 
>> 
>> 
>> Radia
>> 
>> 
>> 
>> 
>> 
>> Larry Kreeger (kreeger) wrote On 10/19/05 16:17,:
>> 
>>>Radia,
>>>
>>>In Step 6, is the frame sent onto the link between RB1 and B1 once or
>>>3 times?  If once, what is the Ethernet DA?
>>>
>>>Thanks, Larry
>>>
>>>From: [email-masked] [mailto:[email-masked]]
>>>On Behalf Of Radia Perlman
>>>Sent: Wednesday, October 19, 2005 3:57 PM
>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>>thread
>>>
>>>Step 1: The bridges create a single broadcast domain, as seen by the 
>>>RBridges. So the RBridges see the following picture:
>>>
>>>  B    C    D    E
>>>  |    |    |    |
>>> RB1  RB2  RB3  RB4
>>>  |    |    |    |
>>> ---------------------
>>>                 |
>>>                 A
>>>
>>>Step 2: RB1 is elected DR, so it is the only one that will 
>encapsulate
>> 
>> 
>>>or decapsulate to/from that link.
>>>
>>>Step 3: A transmits a broadcast or multicast packet
>>>
>>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since 
>>>they are not allowed to process native (non-encapsulated) packets
>>>
>>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress
>> 
>> RB1"
>> 
>>>Step 6: RB1 forwards the encapsulated packet onto the link, with an 
>>>outer header with a multicast address "all RBridges"
>>>
>>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it 
>>>in order to send to their upward link (to C, D, and E, respectively).
>>>
>>>Step 8: (which could certainly happen after 5 or 6...doesn't have to 
>>>be in order). RB1 decapsulates the packet and sends it to B.
>>>
>>>************
>>>Hope that helps...
>>>
>>>Radia
>>>
>>>
>>>
>>>
>>>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,:
>>>
>>>
>>>>Radia,
>>>>
>>>>I think I now understand now that the DR election happens only 
>>>>between
>>>
>>>
>>>>RBridges on a single shared link - and does not require 
>usage of any 
>>>>RBridge topology information.  It would help clarify the data flow 
>>>>for
>>>
>>>
>>>>me (and hopefully others) if, given the network diagram below, you 
>>>>could please give a step by step description of how a 
>broadcast frame 
>>>>sent by host A gets through each Bridge and RBridge in this network 
>>>>in
>>>
>>>
>>>>order to be received by hosts B,C,D,E if we assume that RB1 is the 
>>>>Designated RBridge on the "link" created by the Bridged network 
>>>>formed
>>>
>>>
>>>>by Bridges B1,B2,B3,B4.
>>>>
>>>> B    C    D    E
>>>> |    |    |    |
>>>>RB1  RB2  RB3  RB4
>>>> |    |    |    |
>>>> B1---B2---B3---B4
>>>>                |
>>>>                A
>>>>
>>>>Thanks, Larry
>>>>
>>>>From: [email-masked] [mailto:[email-masked]]
>>>>On Behalf Of Radia Perlman
>>>>Sent: Wednesday, October 19, 2005 9:57 AM
>>>>Subject: Re: [rbridge] FW: Time to summarize "forward or 
>block" BPDU 
>>>>thread
>>>>
>>>>The IS-IS Hello protocol is for electing a single unique switch per 
>>>>link. It doesn't matter which one it is.
>>>>
>>>>On the other hand, the spanning tree protocol is picking a special 
>>>>single unique bridge per link...the one that is closest to the root.
>>>>
>>>>The spanning tree algorithm is choosing a tree of shortest 
>paths from 
>>>>the root.
>>>>
>>>>IS-IS is not trying to do that. It is just electing one guy 
>on a link 
>>>>to do special link-specific things.
>>>>
>>>>Radia
>>>>[email-masked]
>>>[email-masked]
>> [email-masked]
>[email-masked]

Content-class: urn:content-classes:message
Date: Thu, 20 Oct 2005 16:59:48 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 11330

Radia,

Sorry if I'm beating a dead horse.  It sounds like RB2 would receive the
frame sent by RB1 to the "all RBridges" Ethernet DA, but would then know
to drop it.  So, it sounds like RBridges will need some mechanisms to
"block" ports on the "ingress spanning tree" of each RBridge sourcing
broadcasts and multicasts - in other words for every RBridge in the
network.

 - Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Thursday, October 20, 2005 11:07 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
thread

In the picture, it's clear it would have to go encapsulated over the
bridged link. However, if that was just a subset of the topology, it
might be the case that there is some other path to RB3 and RB4.

It is possible that the shortest path tree to RB2 would be over the
direct link, and the shortest path to RB3 and RB4 over the bridged link.

In that case, RB1 would send it encapsulated over the bridged link, and
RB3 and RB4 would receive it, but RB2 would not, since that port of RB2
is not in the "ingress RB1 spanning tree".

Radia

Larry Kreeger (kreeger) wrote On 10/20/05 08:46,:
>  Radia,
> 
> OK, after I replied and re-read your reply, I realized that you must 
> have been answering a different question.  That part made sense.
> 
> I don't understand why it would be zero if the RBridge broadcast 
> distribution tree from RB1 used the new link I added to between RB1 
> and RB2.  It still needs to get to RB3 and RB4.  In this case, does 
> the frame get multicast onto the Bridged link and discarded by RB2 due

> to some type of RPF check, or is it multicast to a "RB3 and RB4" 
> address, or does it get unicast twice to RB3 and RB4 respectively?  
> I'm just trying to understand how many times the same frame goes 
> across the Bridged network.  It seems like a minimum of once (just 
> from A) if the RB's have less cost path reachability than the Bridged 
> network, or up to
> 3 in the example I just gave.
> 
> It seems like a good model for these links may be to model them as a 
> single access link (iff a RB is the DR for the link) plus a tunnel 
> link to every other RB on the link.
> 
> Since Rbridges don't look at STP BPDUs, the RBs may use these tunnel 
> links across any size of Bridged network, which would be sub-optimal.
> Manual configuration would be needed to raise the link cost so that 
> the RBridges would prefer links that were actually links, and not 
> Bridged networks.  If they peaked into the BPDUs, they could probably 
> figure this out themselves.
> 
>  - Larry
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Radia Perlman
> Sent: Wednesday, October 19, 2005 9:10 PM
> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
> thread
> 
> When I say "it is sent twice", I mean that the first time it is sent 
> by A, natively. RB1 does not send it natively, just encapsulated. So 
> perhaps I misparsed your question. I was answering "how many times 
> does the packet get sent on that link" and from this question I guess 
> you were asking "how many times does RB1 transmit the packet on the
link."
> 
> The answer to THAT question is "once", and it will be encapsulated.
> 
> Though with you extra link that you added now, it might be zero, 
> depending on whether the spanning tree the RBridges calculated from 
> the link state database, for ingress RBridge RB1, includes that link
or not.
> 
> So, for your first question:
> 
> 
>>Why does RB1 send it onto the Bridged link with a "native" DA
> 
> Broadcast?
> 
>>If, as you said, F will receive the frame directly from A, then 
>>wouldn't this cause F to get two copies?
>>
> 
> 
> No. RB1 does not send the packet natively. If it did, then F will 
> receive two copies. But it doesn't. This misunderstanding is that I 
> was answering a different question than you were asking, apparently.
> 
> 
> For your second question:
> 
> 
>>Now, the broadcast distribution tree may be (and would probably be
>>better) calculated to use the direct link between RB1--RB2 instead of 
>>through the Bridged network.  Unfortunately, RB1 probably cannot tell 
>>the difference between a direct connection and a Bridged network 
>>connection, but let's say it chooses this link.  Now, wouldn't RB2 get
> 
> 
>>two copies of the broadcast...or is there more to this - such as some 
>>kind of RPF check that is needed.
> 
> 
> The RBridges use the link state database to calculate a tree of 
> shortest paths from RB1. So packets only arrive once.
> 
> Radia
> 
> 
> 
> 
> Larry Kreeger (kreeger) wrote On 10/19/05 17:53,:
> 
>>Radia,
>>
>>Why does RB1 send it onto the Bridged link with a "native" DA
> 
> Broadcast?
> 
>>If, as you said, F will receive the frame directly from A, then 
>>wouldn't this cause F to get two copies?
>>
>>Also, I'm not sure if using an "all RBridges" DA would work if the 
>>RBridges had other connectivity.  For example, if I add a link in the 
>>topology between RB1 and RB2,
>>
>> 
>>  B    C    D    E
>>  |    |    |    |
>> RB1--RB2  RB3  RB4
>>  |    |    |    |
>> ---------------------
>>      |           |
>>      F           A
>>
>>Now, the broadcast distribution tree may be (and would probably be
>>better) calculated to use the direct link between RB1--RB2 instead of 
>>through the Bridged network.  Unfortunately, RB1 probably cannot tell 
>>the difference between a direct connection and a Bridged network 
>>connection, but let's say it chooses this link.  Now, wouldn't RB2 get
> 
> 
>>two copies of the broadcast...or is there more to this - such as some 
>>kind of RPF check that is needed.
>>
>> - Larry
>>
>>From: Radia Perlman [mailto:[email-masked]]
>>Sent: Wednesday, October 19, 2005 4:24 PM
>>To: Larry Kreeger (kreeger)
>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>thread
>>
>>It is sent twice.
>>The first time it is "native", with DA=broadcast
>>
>>The second time is encapsulated by RB1, so the packet has outer header
> 
> 
>>DA="all RBridges", a shim header with "ingress=RB1", and the inner 
>>packet being exactly as transmitted by A.
>>
>>Onto other links though...RB1 will transmit it to B unencapsulated, 
>>i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and
>>RB4 to E.
>>
>>And just a note...in case there were other endnodes on the bridged 
>>link, the RBridges don't worry about it...those endnodes receive the 
>>packet directly from A.
>>
>>So, for instance, F below will receive the packet when A transmitted
> 
> it.
> 
>>  B    C    D    E
>>  |    |    |    |
>> RB1  RB2  RB3  RB4
>>  |    |    |    |
>> ---------------------
>>      |           |
>>      F           A
>>
>>
>>
>>Radia
>>
>>
>>
>>
>>
>>Larry Kreeger (kreeger) wrote On 10/19/05 16:17,:
>>
>>
>>>Radia,
>>>
>>>In Step 6, is the frame sent onto the link between RB1 and B1 once or
>>>3 times?  If once, what is the Ethernet DA?
>>>
>>>Thanks, Larry
>>>
>>>From: [email-masked] [mailto:[email-masked]]
>>>On Behalf Of Radia Perlman
>>>Sent: Wednesday, October 19, 2005 3:57 PM
>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>>thread
>>>
>>>Step 1: The bridges create a single broadcast domain, as seen by the 
>>>RBridges. So the RBridges see the following picture:
>>>
>>> B    C    D    E
>>> |    |    |    |
>>>RB1  RB2  RB3  RB4
>>> |    |    |    |
>>>---------------------
>>>                |
>>>                A
>>>
>>>Step 2: RB1 is elected DR, so it is the only one that will 
>>>encapsulate
>>
>>
>>>or decapsulate to/from that link.
>>>
>>>Step 3: A transmits a broadcast or multicast packet
>>>
>>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since 
>>>they are not allowed to process native (non-encapsulated) packets
>>>
>>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress
>>
>>RB1"
>>
>>
>>>Step 6: RB1 forwards the encapsulated packet onto the link, with an 
>>>outer header with a multicast address "all RBridges"
>>>
>>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it 
>>>in order to send to their upward link (to C, D, and E, respectively).
>>>
>>>Step 8: (which could certainly happen after 5 or 6...doesn't have to 
>>>be in order). RB1 decapsulates the packet and sends it to B.
>>>
>>>************
>>>Hope that helps...
>>>
>>>Radia
>>>
>>>
>>>
>>>
>>>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,:
>>>
>>>
>>>
>>>>Radia,
>>>>
>>>>I think I now understand now that the DR election happens only 
>>>>between
>>>
>>>
>>>>RBridges on a single shared link - and does not require usage of any

>>>>RBridge topology information.  It would help clarify the data flow 
>>>>for
>>>
>>>
>>>>me (and hopefully others) if, given the network diagram below, you 
>>>>could please give a step by step description of how a broadcast 
>>>>frame
> 
> 
>>>>sent by host A gets through each Bridge and RBridge in this network 
>>>>in
>>>
>>>
>>>>order to be received by hosts B,C,D,E if we assume that RB1 is the 
>>>>Designated RBridge on the "link" created by the Bridged network 
>>>>formed
>>>
>>>
>>>>by Bridges B1,B2,B3,B4.
>>>>
>>>>B    C    D    E
>>>>|    |    |    |
>>>>RB1  RB2  RB3  RB4
>>>>|    |    |    |
>>>>B1---B2---B3---B4
>>>>               |
>>>>               A
>>>>
>>>>Thanks, Larry
>>>>
>>>>From: [email-masked] [mailto:[email-masked]]
>>>>On Behalf Of Radia Perlman
>>>>Sent: Wednesday, October 19, 2005 9:57 AM
>>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU

>>>>thread
>>>>
>>>>The IS-IS Hello protocol is for electing a single unique switch per 
>>>>link. It doesn't matter which one it is.
>>>>
>>>>On the other hand, the spanning tree protocol is picking a special 
>>>>single unique bridge per link...the one that is closest to the root.
>>>>
>>>>The spanning tree algorithm is choosing a tree of shortest paths 
>>>>from
> 
> 
>>>>the root.
>>>>
>>>>IS-IS is not trying to do that. It is just electing one guy on a 
>>>>link
> 
> 
>>>>to do special link-specific things.
>>>>
>>>>Radia
>>>>[email-masked]
>>>[email-masked]
>>[email-masked]
> [email-masked]
> [email-masked]

[email-masked]

Date: Thu, 20 Oct 2005 15:10:08 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8935

I don't believe there should be options here.
It should be plug and play.
RBridges should BLOCK bridge spanning tree messages,
and isolate the bridged islands.

I absolutely do not understand what people are
worried about with BLOCK.

I suggest someone that actually thinks there is
some reason to do anything other than drop
spanning tree messages start a thread with
a subject line
"why it is good for RBridges to forward BPDUs",
and very very carefully explain from scratch
what the reasoning is. Not with a long
email quoting pieces of other emails, but
with a carefully crafted, from scratch explanation
of what you perceive as a problem with BLOCk, and
what the perceived benefit of ever having
RBridges forwarding BPDUs would
be.

Oh...and there was a much earlier thread of the
thread about other devices that might forward
or drop BPDUs. There have always been things we
referred to as "simple bridges" that forwarded spanning
tree messages. I was careful to ensure that the
spanning tree would work with such devices. Of course
the spanning tree would not prevent a loop of all
simple bridges, but if there was at least one spanning
tree bridge in the middle of every possible loop, then
there would wind up being no loops.

You can think of "simple bridges" (ones that mindlessly
forward BPDUs) as a layer below bridges. They are
invisible to bridges. Bridges see a bunch of
segments connected by simple bridges as a single segment.
(Just like RBridges will see a bunch of segments connected
by bridges as a single segment).

Devices that drop BDPUs work if they are really
layered on top of bridges, i.e., they let the
bridges do their own thing to create isolated
broadcast domains, and then these other devices do
their own thing to glue these islands together.
Like routers do. And like RBridges will do.

Radia

Guillermo Ib??ez wrote On 10/20/05 14:35,:
> Eric,
> 
> 
> Gray, Eric wrote:
> 
> 
>>Guillermo,
>>
>>	During the discussion, the terms TRANSPARENT, PARTICIPATE
>>and BLOCK were used (often in upper-case, exactly as I have used
>>them here) as if these would ultimately be options that might be
>>supported - either as a complete set, or as some subset.  
>>
>>	For example, one argument was that TRANSPARENT or PARTICIPATE 
>>might be used, but BLOCK should not.
>>
>>	Also, at certain points in the discussion, there was some
>>thought that these might be modes that applied at different states
>>during transitions in a network.
>>
>>	From a practical stand-point - however - it would be best if
>>we did not have to support all of these, either as options, or as
>>modes.  The mere fact that they were brought up does not mean we
>>are committed to including them.
>>
>> 
>>
> 
> Agreed
> 
> 
>>	In particular, if we start talking about - for instance -
>>having a per-interface option for all of these choices (and maybe
>>others as well), then we either need to analyze proposals for 
>>architecture and design to ensure that the "right things" will
>>happen when an arbitrary combination of all of these options is in 
>>effect, or we need to define caveats for network operators to avoid 
>>specific combinations of options.  For example, we may need to say
>>that the same option must be set throughout the network or this and
>>that will (or may) happen.  That kind of design begs configuration
>>errors to occur.
>>
>> 
>>
> 
> If you refer as configuration options per interface to the PARTICIPATE 
> PER PORT mode as an option per port, it is not the case. If  you refer 
> to being the DR the root bridge of the sbridge domain, I think it must 
> be analyzed as a real alternative, even if it is not the default 
> configuration.
> 
> 
>>	In this case, the fact that we want to make the solution plug
>>and play means that we can reduce the potential for disaster if we
>>choose (and require) a specific default set of option choices.  If
>>we can get away with it, however, we should simply avoid options.
>>
>> 
>>
> 
> Agreed, but not for the root bridge problem because is a real, practical 
> issue.
> 
> 
>>	While having these same values as modes that apply during 
>>certain transitional states is cleaner, it would require a well-
>>defined finite state-machine (not a particular problem) and a 
>>genuine need for these behaviors under certain circumstances.  It
>>may well be the case that this turns out to be true.
>>
>> 
>>
> 
> RSTP port state machines are there, may be they should be taken into 
> consideration to make a consistent and integrated, but not interwoven, 
> design for Rbridges that work with RSTP trees.
> Guillermo. 
> 
> 
>>--
>>Eric
>>
>>--> -----Original Message-----
>>--> From: [email-masked] 
>>--> [mailto:[email-masked]]On
>>--> Behalf Of Guillermo Ib??ez
>>--> Sent: Thursday, October 20, 2005 4:19 PM
>>--> To: Developing a hybrid router/bridge.
>>--> Subject: Re: [rbridge] RBridge/bridge interaction
>>--> 
>>--> 
>>--> I volunteer for some work on the capture, although my 
>>--> english might be 
>>--> not too understandable.  From what date should the capture 
>>--> to be done?
>>--> 
>>--> Regarding PARTICIPATE PER PORT:
>>--> Although I do not have a clear position, and it requires detailed 
>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
>>--> better integrated 
>>--> with spanning tree, while maintaining the basic decoupling 
>>--> that BLOCK 
>>--> provides.
>>--> With PARTICIPATE PER PORT it would be possible to force the elected 
>>--> Rbridge to become the sbridge root of the bridged domain by 
>>--> modifying 
>>--> its bridge priority when it gets elected as Designated by 
>>--> IS-IS (this 
>>--> could be an optimization). In this way the path length is 
>>--> minimum  from 
>>--> all bridges of bridged domain to the DR.
>>-->  
>>--> 
>>--> Erik Nordmark wrote:
>>--> 
>>--> >We've had some useful discussion on this mailing list.
>>--> >It would be good if somebody can capture the results 
>>--> (perhaps as a long 
>>--> >email) that we can fold into the draft(s) later. Any volunteers?
>>--> >
>>--> >I don't know if we will have additional issues in this 
>>--> space or that it 
>>--> >otherwise makes sense devoting agenda time to it in Vancouver.
>>--> >
>>--> >For instance, while I'm convinced that BLOCK works, I 
>>--> wonder if there is 
>>--> >something in PARTICIPATE PER PORT that can make the 
>>--> interaction work better.
>>--> >
>>--> >Two cases to consider:
>>--> >1. The elected forwarder dies and a new one gets elected. 
>>--> How quickly 
>>--> >can packets sent by stations in the bridged cloud fail 
>>--> over to go to the 
>>--> >new elected forwarder?
>>--> >
>>--> >  
>>--> >
>>--> My understanding is that if the forwarded dies, the sbridge domain 
>>--> should handle  it as  a topology change notification, tables   of 
>>--> sbridges should be  flushed according to the spanning tree 
>>--> rules, so the 
>>--> sbridge domain must know the DR will not forward frames as 
>>--> it used to. 
>>--> It seems Rbridge shall issue a Topology Change Notification 
>>--> via sbridge 
>>--> domain to flush MAC tables. Is a fast analysis, probably I 
>>--> miss details.
>>-->  
>>--> 
>>--> >2. We have two separate bridged domains, each with their elected 
>>--> >forwarder. Somebody connects the two bridged domains 
>>--> together with a 
>>--> >wire. This can cause a temporary loop until a single 
>>--> elected forwarder 
>>--> >is picked by the RBridges.
>>--> >
>>--> >  
>>--> >
>>--> In this case the PARTICIPATE PER PORT seems superior, as 
>>--> the two merged 
>>--> bridged domains will merge their spanning trees into one 
>>--> and both DRs 
>>--> will compete to be the root of the merged tree, this mechanism will 
>>--> likely be faster (via RSTP fast transit to forwarding state 
>>--> over the 
>>--> bridged domain)  than  Designation to select the unique DR. 
>>--> In other 
>>--> words , the mechanism of root election in sbridge could be 
>>--> used to help 
>>--> in DR designation and/or viceversa.
>>--> So I see in PARTICIPATE PER PORT, some coupling between DR 
>>--> status and 
>>--> root status of sbridge domain that can be used
>>-->  to speed up convergence and coherence of both domains. It 
>>--> seems that 
>>--> sbridge domains should be under the control of  Rbridges, but the 
>>--> sbridge mechanims should be used by Rbridges to keep the network 
>>--> consistency and reconfiguration capabilities of RSTP.
>>--> Guillermo
>>--> 
>>-->  
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [email-masked]
>>--> http://www.postel.org/mailman/listinfo/rbridge
>>--> 
>>[email-masked]
> [email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Thu, 20 Oct 2005 18:55:37 -0300
Subject: [rbridge] R-Bridge Routing Requirements draft is now available
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 497

The draft "Routing Requirements in Support of R-Bridges" - submitted last 
Friday - is now available at:

http://www.ietf.org/internet-drafts/draft-gray-rbridge-routing-reqs-00.txt

This draft borrows heavily from the earlier draft-perlman-rbridge-03.txt
and is very preliminary.  I am looking for input for the various sections
- particularly those that currently only contain "TBD" :-)

This was one of the drafts that the working group felt would be required
at the last meeting.

--
Eric Gray

Date: Thu, 20 Oct 2005 23:35:20 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 6687

Eric,

Gray, Eric wrote:

>Guillermo,
>
>	During the discussion, the terms TRANSPARENT, PARTICIPATE
>and BLOCK were used (often in upper-case, exactly as I have used
>them here) as if these would ultimately be options that might be
>supported - either as a complete set, or as some subset.  
>
>	For example, one argument was that TRANSPARENT or PARTICIPATE 
>might be used, but BLOCK should not.
>
>	Also, at certain points in the discussion, there was some
>thought that these might be modes that applied at different states
>during transitions in a network.
>
>	From a practical stand-point - however - it would be best if
>we did not have to support all of these, either as options, or as
>modes.  The mere fact that they were brought up does not mean we
>are committed to including them.
>
>  
>
Agreed

>	In particular, if we start talking about - for instance -
>having a per-interface option for all of these choices (and maybe
>others as well), then we either need to analyze proposals for 
>architecture and design to ensure that the "right things" will
>happen when an arbitrary combination of all of these options is in 
>effect, or we need to define caveats for network operators to avoid 
>specific combinations of options.  For example, we may need to say
>that the same option must be set throughout the network or this and
>that will (or may) happen.  That kind of design begs configuration
>errors to occur.
>
>  
>
If you refer as configuration options per interface to the PARTICIPATE 
PER PORT mode as an option per port, it is not the case. If  you refer 
to being the DR the root bridge of the sbridge domain, I think it must 
be analyzed as a real alternative, even if it is not the default 
configuration.

>	In this case, the fact that we want to make the solution plug
>and play means that we can reduce the potential for disaster if we
>choose (and require) a specific default set of option choices.  If
>we can get away with it, however, we should simply avoid options.
>
>  
>
Agreed, but not for the root bridge problem because is a real, practical 
issue.

>	While having these same values as modes that apply during 
>certain transitional states is cleaner, it would require a well-
>defined finite state-machine (not a particular problem) and a 
>genuine need for these behaviors under certain circumstances.  It
>may well be the case that this turns out to be true.
>
>  
>
RSTP port state machines are there, may be they should be taken into 
consideration to make a consistent and integrated, but not interwoven, 
design for Rbridges that work with RSTP trees.
Guillermo. 

>--
>Eric
>
>--> -----Original Message-----
>--> From: [email-masked] 
>--> [mailto:[email-masked]]On
>--> Behalf Of Guillermo Ib??ez
>--> Sent: Thursday, October 20, 2005 4:19 PM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] RBridge/bridge interaction
>--> 
>--> 
>--> I volunteer for some work on the capture, although my 
>--> english might be 
>--> not too understandable.  From what date should the capture 
>--> to be done?
>--> 
>--> Regarding PARTICIPATE PER PORT:
>--> Although I do not have a clear position, and it requires detailed 
>--> analysis, it seems to me that PARTICIPATE PER PORT is 
>--> better integrated 
>--> with spanning tree, while maintaining the basic decoupling 
>--> that BLOCK 
>--> provides.
>--> With PARTICIPATE PER PORT it would be possible to force the elected 
>--> Rbridge to become the sbridge root of the bridged domain by 
>--> modifying 
>--> its bridge priority when it gets elected as Designated by 
>--> IS-IS (this 
>--> could be an optimization). In this way the path length is 
>--> minimum  from 
>--> all bridges of bridged domain to the DR.
>-->  
>--> 
>--> Erik Nordmark wrote:
>--> 
>--> >We've had some useful discussion on this mailing list.
>--> >It would be good if somebody can capture the results 
>--> (perhaps as a long 
>--> >email) that we can fold into the draft(s) later. Any volunteers?
>--> >
>--> >I don't know if we will have additional issues in this 
>--> space or that it 
>--> >otherwise makes sense devoting agenda time to it in Vancouver.
>--> >
>--> >For instance, while I'm convinced that BLOCK works, I 
>--> wonder if there is 
>--> >something in PARTICIPATE PER PORT that can make the 
>--> interaction work better.
>--> >
>--> >Two cases to consider:
>--> >1. The elected forwarder dies and a new one gets elected. 
>--> How quickly 
>--> >can packets sent by stations in the bridged cloud fail 
>--> over to go to the 
>--> >new elected forwarder?
>--> >
>--> >  
>--> >
>--> My understanding is that if the forwarded dies, the sbridge domain 
>--> should handle  it as  a topology change notification, tables   of 
>--> sbridges should be  flushed according to the spanning tree 
>--> rules, so the 
>--> sbridge domain must know the DR will not forward frames as 
>--> it used to. 
>--> It seems Rbridge shall issue a Topology Change Notification 
>--> via sbridge 
>--> domain to flush MAC tables. Is a fast analysis, probably I 
>--> miss details.
>-->  
>--> 
>--> >2. We have two separate bridged domains, each with their elected 
>--> >forwarder. Somebody connects the two bridged domains 
>--> together with a 
>--> >wire. This can cause a temporary loop until a single 
>--> elected forwarder 
>--> >is picked by the RBridges.
>--> >
>--> >  
>--> >
>--> In this case the PARTICIPATE PER PORT seems superior, as 
>--> the two merged 
>--> bridged domains will merge their spanning trees into one 
>--> and both DRs 
>--> will compete to be the root of the merged tree, this mechanism will 
>--> likely be faster (via RSTP fast transit to forwarding state 
>--> over the 
>--> bridged domain)  than  Designation to select the unique DR. 
>--> In other 
>--> words , the mechanism of root election in sbridge could be 
>--> used to help 
>--> in DR designation and/or viceversa.
>--> So I see in PARTICIPATE PER PORT, some coupling between DR 
>--> status and 
>--> root status of sbridge domain that can be used
>-->  to speed up convergence and coherence of both domains. It 
>--> seems that 
>--> sbridge domains should be under the control of  Rbridges, but the 
>--> sbridge mechanims should be used by Rbridges to keep the network 
>--> consistency and reconfiguration capabilities of RSTP.
>--> Guillermo
>--> 
>-->  
>--> _______________________________________________
>--> rbridge mailing list
>--> [email-masked]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Thu, 20 Oct 2005 18:07:43 -0300
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5816

Radia,

	Does that mean you're looking for someone to volunteer to give
that tutorial at the next IETF meeting?  :-)

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Radia Perlman
--> Sent: Thursday, October 20, 2005 4:43 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> Well, actually, I don't think he meant capturing the whole
--> discussion. The problem is that no mortal can really follow
--> a long discussion in email. It needs to be periodically summarized.
--> Ideally, once someone does a summary of a thread, people can start
--> with that note, and ignore all the previous ones. And if 
--> the summarizer
--> missed anything, people can respond to the summary.
--> 
--> So I do think it is useful to summarize again. Though if I were to
--> write the summary, I'd say the same thing I did in the last summary,
--> since I don't think there's anything too new technically.
--> 
--> What I will volunteer to do is write a tutorial, going through
--> cases like the topologies I was asked about, and exactly what
--> happens in them, since I think that actually does help people
--> visualize it. Having people ask questions is actually helpful, by
--> the way, since sometimes it's hard to see what might confuse
--> people unless people do ask questions. So thank you, people who
--> have asked questions...it's really helpful.
--> 
--> By the way, I will not be at the next IETF.
--> 
--> Radia
--> 
--> Gray, Eric wrote On 10/20/05 13:22,:
--> > Peter/Erik,
--> > 
--> > 	Perhaps it might be a good idea to summarize the discussion,
--> > but I was under the impression that has been tried already in this
--> > thread.  If Peter wants to give it a try, that's fine with me.
--> > 
--> > 	As for capturing the discussion, short of reproducing it, it
--> > is unlikely that we would benefit from such an effort - especially
--> > given that is what an E-Mail archive is for.  
--> > 
--> > 	I certainly hope we are not planning to include all of the 
--> > discussion in a draft - unless you are referring to the framework
--> > or requirements draft.  As commedable as the idea is to capture a
--> > thought process so that we can avoid having to hash it out again,
--> > a specification is not the place to do that.  It can be extremely 
--> > difficult to parse a specification if it contains every 
--> crufty idea 
--> > that was considered in various brain-storming sessions.
--> > 
--> > 	In the worst case, such a specification may imply a need to
--> > implement all of those things and end up sinking implementations
--> > from an excessive burden of options.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: [email-masked] 
--> > --> [mailto:[email-masked]]On
--> > --> Behalf Of Peter Ashwood-Smith
--> > --> Sent: Thursday, October 20, 2005 11:39 AM
--> > --> To: Developing a hybrid router/bridge.
--> > --> Subject: Re: [rbridge] RBridge/bridge interaction
--> > --> 
--> > --> 
--> > --> If nobody else wants to I'm happy to give it a whirl.
--> > --> Any objections? or anybody else prefer to do it?
--> > --> 
--> > --> Peter
--> > --> 
--> > --> > -----Original Message-----
--> > --> > From: [email-masked] 
--> > --> > [mailto:[email-masked]] On Behalf Of 
--> Erik Nordmark
--> > --> > Sent: Thursday, October 20, 2005 10:24 AM
--> > --> > To: Developing a hybrid router/bridge.
--> > --> > Subject: [rbridge] RBridge/bridge interaction
--> > --> > 
--> > --> > 
--> > --> > 
--> > --> > We've had some useful discussion on this mailing list.
--> > --> > It would be good if somebody can capture the 
--> results (perhaps 
--> > --> > as a long 
--> > --> > email) that we can fold into the draft(s) later. 
--> Any volunteers?
--> > --> > 
--> > --> > I don't know if we will have additional issues in 
--> this space 
--> > --> > or that it 
--> > --> > otherwise makes sense devoting agenda time to it in 
--> Vancouver.
--> > --> > 
--> > --> > For instance, while I'm convinced that BLOCK works, 
--> I wonder 
--> > --> > if there is 
--> > --> > something in PARTICIPATE PER PORT that can make the 
--> > --> > interaction work better.
--> > --> > 
--> > --> > Two cases to consider:
--> > --> > 1. The elected forwarder dies and a new one gets elected. 
--> > --> How quickly 
--> > --> > can packets sent by stations in the bridged cloud fail over 
--> > --> > to go to the 
--> > --> > new elected forwarder?
--> > --> > 
--> > --> > 2. We have two separate bridged domains, each with 
--> their elected 
--> > --> > forwarder. Somebody connects the two bridged domains 
--> > --> together with a 
--> > --> > wire. This can cause a temporary loop until a 
--> single elected 
--> > --> > forwarder 
--> > --> > is picked by the RBridges.
--> > --> > 
--> > --> > Can some form of PARTICIPATE PER PORT scheme makes 
--> things work 
--> > --> > better/faster in those two cases?
--> > --> > 
--> > --> >     Erik
--> > --> > 
--> > --> > _______________________________________________
--> > --> > rbridge mailing list
--> > --> > [email-masked] 
--> http://www.postel.org/mailman/listinfo/rbridge
--> > --> > 
--> > --> > 
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> [email-masked]
--> > --> http://www.postel.org/mailman/listinfo/rbridge
--> > --> 
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked]
--> > http://www.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Thu, 20 Oct 2005 18:02:47 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5750

Guillermo,

	During the discussion, the terms TRANSPARENT, PARTICIPATE
and BLOCK were used (often in upper-case, exactly as I have used
them here) as if these would ultimately be options that might be
supported - either as a complete set, or as some subset.  

	For example, one argument was that TRANSPARENT or PARTICIPATE 
might be used, but BLOCK should not.

	Also, at certain points in the discussion, there was some
thought that these might be modes that applied at different states
during transitions in a network.

	From a practical stand-point - however - it would be best if
we did not have to support all of these, either as options, or as
modes.  The mere fact that they were brought up does not mean we
are committed to including them.

	In particular, if we start talking about - for instance -
having a per-interface option for all of these choices (and maybe
others as well), then we either need to analyze proposals for 
architecture and design to ensure that the "right things" will
happen when an arbitrary combination of all of these options is in 
effect, or we need to define caveats for network operators to avoid 
specific combinations of options.  For example, we may need to say
that the same option must be set throughout the network or this and
that will (or may) happen.  That kind of design begs configuration
errors to occur.

	In this case, the fact that we want to make the solution plug
and play means that we can reduce the potential for disaster if we
choose (and require) a specific default set of option choices.  If
we can get away with it, however, we should simply avoid options.

	While having these same values as modes that apply during 
certain transitional states is cleaner, it would require a well-
defined finite state-machine (not a particular problem) and a 
genuine need for these behaviors under certain circumstances.  It
may well be the case that this turns out to be true.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Thursday, October 20, 2005 4:19 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> I volunteer for some work on the capture, although my 
--> english might be 
--> not too understandable.  From what date should the capture 
--> to be done?
--> 
--> Regarding PARTICIPATE PER PORT:
--> Although I do not have a clear position, and it requires detailed 
--> analysis, it seems to me that PARTICIPATE PER PORT is 
--> better integrated 
--> with spanning tree, while maintaining the basic decoupling 
--> that BLOCK 
--> provides.
--> With PARTICIPATE PER PORT it would be possible to force the elected 
--> Rbridge to become the sbridge root of the bridged domain by 
--> modifying 
--> its bridge priority when it gets elected as Designated by 
--> IS-IS (this 
--> could be an optimization). In this way the path length is 
--> minimum  from 
--> all bridges of bridged domain to the DR.
-->  
--> 
--> Erik Nordmark wrote:
--> 
--> >We've had some useful discussion on this mailing list.
--> >It would be good if somebody can capture the results 
--> (perhaps as a long 
--> >email) that we can fold into the draft(s) later. Any volunteers?
--> >
--> >I don't know if we will have additional issues in this 
--> space or that it 
--> >otherwise makes sense devoting agenda time to it in Vancouver.
--> >
--> >For instance, while I'm convinced that BLOCK works, I 
--> wonder if there is 
--> >something in PARTICIPATE PER PORT that can make the 
--> interaction work better.
--> >
--> >Two cases to consider:
--> >1. The elected forwarder dies and a new one gets elected. 
--> How quickly 
--> >can packets sent by stations in the bridged cloud fail 
--> over to go to the 
--> >new elected forwarder?
--> >
--> >  
--> >
--> My understanding is that if the forwarded dies, the sbridge domain 
--> should handle  it as  a topology change notification, tables   of 
--> sbridges should be  flushed according to the spanning tree 
--> rules, so the 
--> sbridge domain must know the DR will not forward frames as 
--> it used to. 
--> It seems Rbridge shall issue a Topology Change Notification 
--> via sbridge 
--> domain to flush MAC tables. Is a fast analysis, probably I 
--> miss details.
-->  
--> 
--> >2. We have two separate bridged domains, each with their elected 
--> >forwarder. Somebody connects the two bridged domains 
--> together with a 
--> >wire. This can cause a temporary loop until a single 
--> elected forwarder 
--> >is picked by the RBridges.
--> >
--> >  
--> >
--> In this case the PARTICIPATE PER PORT seems superior, as 
--> the two merged 
--> bridged domains will merge their spanning trees into one 
--> and both DRs 
--> will compete to be the root of the merged tree, this mechanism will 
--> likely be faster (via RSTP fast transit to forwarding state 
--> over the 
--> bridged domain)  than  Designation to select the unique DR. 
--> In other 
--> words , the mechanism of root election in sbridge could be 
--> used to help 
--> in DR designation and/or viceversa.
--> So I see in PARTICIPATE PER PORT, some coupling between DR 
--> status and 
--> root status of sbridge domain that can be used
-->  to speed up convergence and coherence of both domains. It 
--> seems that 
--> sbridge domains should be under the control of  Rbridges, but the 
--> sbridge mechanims should be used by Rbridges to keep the network 
--> consistency and reconfiguration capabilities of RSTP.
--> Guillermo
--> 
-->  
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Thu, 20 Oct 2005 13:42:49 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4702

Well, actually, I don't think he meant capturing the whole
discussion. The problem is that no mortal can really follow
a long discussion in email. It needs to be periodically summarized.
Ideally, once someone does a summary of a thread, people can start
with that note, and ignore all the previous ones. And if the summarizer
missed anything, people can respond to the summary.

So I do think it is useful to summarize again. Though if I were to
write the summary, I'd say the same thing I did in the last summary,
since I don't think there's anything too new technically.

What I will volunteer to do is write a tutorial, going through
cases like the topologies I was asked about, and exactly what
happens in them, since I think that actually does help people
visualize it. Having people ask questions is actually helpful, by
the way, since sometimes it's hard to see what might confuse
people unless people do ask questions. So thank you, people who
have asked questions...it's really helpful.

By the way, I will not be at the next IETF.

Radia

Gray, Eric wrote On 10/20/05 13:22,:
> Peter/Erik,
> 
> 	Perhaps it might be a good idea to summarize the discussion,
> but I was under the impression that has been tried already in this
> thread.  If Peter wants to give it a try, that's fine with me.
> 
> 	As for capturing the discussion, short of reproducing it, it
> is unlikely that we would benefit from such an effort - especially
> given that is what an E-Mail archive is for.  
> 
> 	I certainly hope we are not planning to include all of the 
> discussion in a draft - unless you are referring to the framework
> or requirements draft.  As commedable as the idea is to capture a
> thought process so that we can avoid having to hash it out again,
> a specification is not the place to do that.  It can be extremely 
> difficult to parse a specification if it contains every crufty idea 
> that was considered in various brain-storming sessions.
> 
> 	In the worst case, such a specification may imply a need to
> implement all of those things and end up sinking implementations
> from an excessive burden of options.
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked] 
> --> [mailto:[email-masked]]On
> --> Behalf Of Peter Ashwood-Smith
> --> Sent: Thursday, October 20, 2005 11:39 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] RBridge/bridge interaction
> --> 
> --> 
> --> If nobody else wants to I'm happy to give it a whirl.
> --> Any objections? or anybody else prefer to do it?
> --> 
> --> Peter
> --> 
> --> > -----Original Message-----
> --> > From: [email-masked] 
> --> > [mailto:[email-masked]] On Behalf Of Erik Nordmark
> --> > Sent: Thursday, October 20, 2005 10:24 AM
> --> > To: Developing a hybrid router/bridge.
> --> > Subject: [rbridge] RBridge/bridge interaction
> --> > 
> --> > 
> --> > 
> --> > We've had some useful discussion on this mailing list.
> --> > It would be good if somebody can capture the results (perhaps 
> --> > as a long 
> --> > email) that we can fold into the draft(s) later. Any volunteers?
> --> > 
> --> > I don't know if we will have additional issues in this space 
> --> > or that it 
> --> > otherwise makes sense devoting agenda time to it in Vancouver.
> --> > 
> --> > For instance, while I'm convinced that BLOCK works, I wonder 
> --> > if there is 
> --> > something in PARTICIPATE PER PORT that can make the 
> --> > interaction work better.
> --> > 
> --> > Two cases to consider:
> --> > 1. The elected forwarder dies and a new one gets elected. 
> --> How quickly 
> --> > can packets sent by stations in the bridged cloud fail over 
> --> > to go to the 
> --> > new elected forwarder?
> --> > 
> --> > 2. We have two separate bridged domains, each with their elected 
> --> > forwarder. Somebody connects the two bridged domains 
> --> together with a 
> --> > wire. This can cause a temporary loop until a single elected 
> --> > forwarder 
> --> > is picked by the RBridges.
> --> > 
> --> > Can some form of PARTICIPATE PER PORT scheme makes things work 
> --> > better/faster in those two cases?
> --> > 
> --> >     Erik
> --> > 
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [email-masked] http://www.postel.org/mailman/listinfo/rbridge
> --> > 
> --> > 
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://www.postel.org/mailman/listinfo/rbridge
> --> 
> [email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Thu, 20 Oct 2005 17:22:50 -0300
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3290

Peter/Erik,

	Perhaps it might be a good idea to summarize the discussion,
but I was under the impression that has been tried already in this
thread.  If Peter wants to give it a try, that's fine with me.

	As for capturing the discussion, short of reproducing it, it
is unlikely that we would benefit from such an effort - especially
given that is what an E-Mail archive is for.  

	I certainly hope we are not planning to include all of the 
discussion in a draft - unless you are referring to the framework
or requirements draft.  As commedable as the idea is to capture a
thought process so that we can avoid having to hash it out again,
a specification is not the place to do that.  It can be extremely 
difficult to parse a specification if it contains every crufty idea 
that was considered in various brain-storming sessions.

	In the worst case, such a specification may imply a need to
implement all of those things and end up sinking implementations
from an excessive burden of options.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Peter Ashwood-Smith
--> Sent: Thursday, October 20, 2005 11:39 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> If nobody else wants to I'm happy to give it a whirl.
--> Any objections? or anybody else prefer to do it?
--> 
--> Peter
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> > [mailto:[email-masked]] On Behalf Of Erik Nordmark
--> > Sent: Thursday, October 20, 2005 10:24 AM
--> > To: Developing a hybrid router/bridge.
--> > Subject: [rbridge] RBridge/bridge interaction
--> > 
--> > 
--> > 
--> > We've had some useful discussion on this mailing list.
--> > It would be good if somebody can capture the results (perhaps 
--> > as a long 
--> > email) that we can fold into the draft(s) later. Any volunteers?
--> > 
--> > I don't know if we will have additional issues in this space 
--> > or that it 
--> > otherwise makes sense devoting agenda time to it in Vancouver.
--> > 
--> > For instance, while I'm convinced that BLOCK works, I wonder 
--> > if there is 
--> > something in PARTICIPATE PER PORT that can make the 
--> > interaction work better.
--> > 
--> > Two cases to consider:
--> > 1. The elected forwarder dies and a new one gets elected. 
--> How quickly 
--> > can packets sent by stations in the bridged cloud fail over 
--> > to go to the 
--> > new elected forwarder?
--> > 
--> > 2. We have two separate bridged domains, each with their elected 
--> > forwarder. Somebody connects the two bridged domains 
--> together with a 
--> > wire. This can cause a temporary loop until a single elected 
--> > forwarder 
--> > is picked by the RBridges.
--> > 
--> > Can some form of PARTICIPATE PER PORT scheme makes things work 
--> > better/faster in those two cases?
--> > 
--> >     Erik
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked] http://www.postel.org/mailman/listinfo/rbridge
--> > 
--> > 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Thu, 20 Oct 2005 22:19:29 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2971

I volunteer for some work on the capture, although my english might be 
not too understandable.  From what date should the capture to be done?

Regarding PARTICIPATE PER PORT:
Although I do not have a clear position, and it requires detailed 
analysis, it seems to me that PARTICIPATE PER PORT is better integrated 
with spanning tree, while maintaining the basic decoupling that BLOCK 
provides.
With PARTICIPATE PER PORT it would be possible to force the elected 
Rbridge to become the sbridge root of the bridged domain by modifying 
its bridge priority when it gets elected as Designated by IS-IS (this 
could be an optimization). In this way the path length is minimum  from 
all bridges of bridged domain to the DR.

Erik Nordmark wrote:

>We've had some useful discussion on this mailing list.
>It would be good if somebody can capture the results (perhaps as a long 
>email) that we can fold into the draft(s) later. Any volunteers?
>
>I don't know if we will have additional issues in this space or that it 
>otherwise makes sense devoting agenda time to it in Vancouver.
>
>For instance, while I'm convinced that BLOCK works, I wonder if there is 
>something in PARTICIPATE PER PORT that can make the interaction work better.
>
>Two cases to consider:
>1. The elected forwarder dies and a new one gets elected. How quickly 
>can packets sent by stations in the bridged cloud fail over to go to the 
>new elected forwarder?
>
>  
>
My understanding is that if the forwarded dies, the sbridge domain 
should handle  it as  a topology change notification, tables   of 
sbridges should be  flushed according to the spanning tree rules, so the 
sbridge domain must know the DR will not forward frames as it used to. 
It seems Rbridge shall issue a Topology Change Notification via sbridge 
domain to flush MAC tables. Is a fast analysis, probably I miss details.

>2. We have two separate bridged domains, each with their elected 
>forwarder. Somebody connects the two bridged domains together with a 
>wire. This can cause a temporary loop until a single elected forwarder 
>is picked by the RBridges.
>
>  
>
In this case the PARTICIPATE PER PORT seems superior, as the two merged 
bridged domains will merge their spanning trees into one and both DRs 
will compete to be the root of the merged tree, this mechanism will 
likely be faster (via RSTP fast transit to forwarding state over the 
bridged domain)  than  Designation to select the unique DR. In other 
words , the mechanism of root election in sbridge could be used to help 
in DR designation and/or viceversa.
So I see in PARTICIPATE PER PORT, some coupling between DR status and 
root status of sbridge domain that can be used
 to speed up convergence and coherence of both domains. It seems that 
sbridge domains should be under the control of  Rbridges, but the 
sbridge mechanims should be used by Rbridges to keep the network 
consistency and reconfiguration capabilities of RSTP.
Guillermo

Date: Thu, 20 Oct 2005 11:06:35 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10485

In the picture, it's clear it would have to go encapsulated over
the bridged link. However, if that was just a subset of the topology,
it might be the case that there is some other path to RB3 and
RB4.

It is possible that the shortest path tree to RB2 would be over the direct
link, and the shortest path to RB3 and RB4 over the bridged link.

In that case, RB1 would send it encapsulated over the bridged link,
and RB3 and RB4 would receive it, but RB2 would not, since that
port of RB2 is not in the "ingress RB1 spanning tree".

Radia

Larry Kreeger (kreeger) wrote On 10/20/05 08:46,:
>  Radia,
> 
> OK, after I replied and re-read your reply, I realized that you must
> have been answering a different question.  That part made sense.
> 
> I don't understand why it would be zero if the RBridge broadcast
> distribution tree from RB1 used the new link I added to between RB1 and
> RB2.  It still needs to get to RB3 and RB4.  In this case, does the
> frame get multicast onto the Bridged link and discarded by RB2 due to
> some type of RPF check, or is it multicast to a "RB3 and RB4" address,
> or does it get unicast twice to RB3 and RB4 respectively?  I'm just
> trying to understand how many times the same frame goes across the
> Bridged network.  It seems like a minimum of once (just from A) if the
> RB's have less cost path reachability than the Bridged network, or up to
> 3 in the example I just gave.
> 
> It seems like a good model for these links may be to model them as a
> single access link (iff a RB is the DR for the link) plus a tunnel link
> to every other RB on the link.
> 
> Since Rbridges don't look at STP BPDUs, the RBs may use these tunnel
> links across any size of Bridged network, which would be sub-optimal.
> Manual configuration would be needed to raise the link cost so that the
> RBridges would prefer links that were actually links, and not Bridged
> networks.  If they peaked into the BPDUs, they could probably figure
> this out themselves.
> 
>  - Larry
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Radia Perlman
> Sent: Wednesday, October 19, 2005 9:10 PM
> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
> thread
> 
> When I say "it is sent twice", I mean that the first time it is sent by
> A, natively. RB1 does not send it natively, just encapsulated. So
> perhaps I misparsed your question. I was answering "how many times does
> the packet get sent on that link" and from this question I guess you
> were asking "how many times does RB1 transmit the packet on the link."
> 
> The answer to THAT question is "once", and it will be encapsulated.
> 
> Though with you extra link that you added now, it might be zero,
> depending on whether the spanning tree the RBridges calculated from the
> link state database, for ingress RBridge RB1, includes that link or not.
> 
> So, for your first question:
> 
> 
>>Why does RB1 send it onto the Bridged link with a "native" DA
> 
> Broadcast?
> 
>>If, as you said, F will receive the frame directly from A, then 
>>wouldn't this cause F to get two copies?
>>
> 
> 
> No. RB1 does not send the packet natively. If it did, then F will
> receive two copies. But it doesn't. This misunderstanding is that I was
> answering a different question than you were asking, apparently.
> 
> 
> For your second question:
> 
> 
>>Now, the broadcast distribution tree may be (and would probably be
>>better) calculated to use the direct link between RB1--RB2 instead of 
>>through the Bridged network.  Unfortunately, RB1 probably cannot tell 
>>the difference between a direct connection and a Bridged network 
>>connection, but let's say it chooses this link.  Now, wouldn't RB2 get
> 
> 
>>two copies of the broadcast...or is there more to this - such as some 
>>kind of RPF check that is needed.
> 
> 
> The RBridges use the link state database to calculate a tree of shortest
> paths from RB1. So packets only arrive once.
> 
> Radia
> 
> 
> 
> 
> Larry Kreeger (kreeger) wrote On 10/19/05 17:53,:
> 
>>Radia,
>>
>>Why does RB1 send it onto the Bridged link with a "native" DA
> 
> Broadcast?
> 
>>If, as you said, F will receive the frame directly from A, then 
>>wouldn't this cause F to get two copies?
>>
>>Also, I'm not sure if using an "all RBridges" DA would work if the 
>>RBridges had other connectivity.  For example, if I add a link in the 
>>topology between RB1 and RB2,
>>
>> 
>>  B    C    D    E
>>  |    |    |    |
>> RB1--RB2  RB3  RB4
>>  |    |    |    |
>> ---------------------
>>      |           |
>>      F           A
>>
>>Now, the broadcast distribution tree may be (and would probably be
>>better) calculated to use the direct link between RB1--RB2 instead of 
>>through the Bridged network.  Unfortunately, RB1 probably cannot tell 
>>the difference between a direct connection and a Bridged network 
>>connection, but let's say it chooses this link.  Now, wouldn't RB2 get
> 
> 
>>two copies of the broadcast...or is there more to this - such as some 
>>kind of RPF check that is needed.
>>
>> - Larry
>>
>>From: Radia Perlman [mailto:[email-masked]]
>>Sent: Wednesday, October 19, 2005 4:24 PM
>>To: Larry Kreeger (kreeger)
>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>thread
>>
>>It is sent twice.
>>The first time it is "native", with DA=broadcast
>>
>>The second time is encapsulated by RB1, so the packet has outer header
> 
> 
>>DA="all RBridges", a shim header with "ingress=RB1", and the inner 
>>packet being exactly as transmitted by A.
>>
>>Onto other links though...RB1 will transmit it to B unencapsulated, 
>>i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and 
>>RB4 to E.
>>
>>And just a note...in case there were other endnodes on the bridged 
>>link, the RBridges don't worry about it...those endnodes receive the 
>>packet directly from A.
>>
>>So, for instance, F below will receive the packet when A transmitted
> 
> it.
> 
>>  B    C    D    E
>>  |    |    |    |
>> RB1  RB2  RB3  RB4
>>  |    |    |    |
>> ---------------------
>>      |           |
>>      F           A
>>
>>
>>
>>Radia
>>
>>
>>
>>
>>
>>Larry Kreeger (kreeger) wrote On 10/19/05 16:17,:
>>
>>
>>>Radia,
>>>
>>>In Step 6, is the frame sent onto the link between RB1 and B1 once or
>>>3 times?  If once, what is the Ethernet DA?
>>>
>>>Thanks, Larry
>>>
>>>From: [email-masked] [mailto:[email-masked]]
>>>On Behalf Of Radia Perlman
>>>Sent: Wednesday, October 19, 2005 3:57 PM
>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>>thread
>>>
>>>Step 1: The bridges create a single broadcast domain, as seen by the 
>>>RBridges. So the RBridges see the following picture:
>>>
>>> B    C    D    E
>>> |    |    |    |
>>>RB1  RB2  RB3  RB4
>>> |    |    |    |
>>>---------------------
>>>                |
>>>                A
>>>
>>>Step 2: RB1 is elected DR, so it is the only one that will encapsulate
>>
>>
>>>or decapsulate to/from that link.
>>>
>>>Step 3: A transmits a broadcast or multicast packet
>>>
>>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since 
>>>they are not allowed to process native (non-encapsulated) packets
>>>
>>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress
>>
>>RB1"
>>
>>
>>>Step 6: RB1 forwards the encapsulated packet onto the link, with an 
>>>outer header with a multicast address "all RBridges"
>>>
>>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it 
>>>in order to send to their upward link (to C, D, and E, respectively).
>>>
>>>Step 8: (which could certainly happen after 5 or 6...doesn't have to 
>>>be in order). RB1 decapsulates the packet and sends it to B.
>>>
>>>************
>>>Hope that helps...
>>>
>>>Radia
>>>
>>>
>>>
>>>
>>>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,:
>>>
>>>
>>>
>>>>Radia,
>>>>
>>>>I think I now understand now that the DR election happens only 
>>>>between
>>>
>>>
>>>>RBridges on a single shared link - and does not require usage of any 
>>>>RBridge topology information.  It would help clarify the data flow 
>>>>for
>>>
>>>
>>>>me (and hopefully others) if, given the network diagram below, you 
>>>>could please give a step by step description of how a broadcast frame
> 
> 
>>>>sent by host A gets through each Bridge and RBridge in this network 
>>>>in
>>>
>>>
>>>>order to be received by hosts B,C,D,E if we assume that RB1 is the 
>>>>Designated RBridge on the "link" created by the Bridged network 
>>>>formed
>>>
>>>
>>>>by Bridges B1,B2,B3,B4.
>>>>
>>>>B    C    D    E
>>>>|    |    |    |
>>>>RB1  RB2  RB3  RB4
>>>>|    |    |    |
>>>>B1---B2---B3---B4
>>>>               |
>>>>               A
>>>>
>>>>Thanks, Larry
>>>>
>>>>From: [email-masked] [mailto:[email-masked]]
>>>>On Behalf Of Radia Perlman
>>>>Sent: Wednesday, October 19, 2005 9:57 AM
>>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>>>thread
>>>>
>>>>The IS-IS Hello protocol is for electing a single unique switch per 
>>>>link. It doesn't matter which one it is.
>>>>
>>>>On the other hand, the spanning tree protocol is picking a special 
>>>>single unique bridge per link...the one that is closest to the root.
>>>>
>>>>The spanning tree algorithm is choosing a tree of shortest paths from
> 
> 
>>>>the root.
>>>>
>>>>IS-IS is not trying to do that. It is just electing one guy on a link
> 
> 
>>>>to do special link-specific things.
>>>>
>>>>Radia
>>>>[email-masked]
>>>[email-masked]
>>[email-masked]
> [email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Thu, 20 Oct 2005 08:46:19 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9414

 Radia,

OK, after I replied and re-read your reply, I realized that you must
have been answering a different question.  That part made sense.

I don't understand why it would be zero if the RBridge broadcast
distribution tree from RB1 used the new link I added to between RB1 and
RB2.  It still needs to get to RB3 and RB4.  In this case, does the
frame get multicast onto the Bridged link and discarded by RB2 due to
some type of RPF check, or is it multicast to a "RB3 and RB4" address,
or does it get unicast twice to RB3 and RB4 respectively?  I'm just
trying to understand how many times the same frame goes across the
Bridged network.  It seems like a minimum of once (just from A) if the
RB's have less cost path reachability than the Bridged network, or up to
3 in the example I just gave.

It seems like a good model for these links may be to model them as a
single access link (iff a RB is the DR for the link) plus a tunnel link
to every other RB on the link.

Since Rbridges don't look at STP BPDUs, the RBs may use these tunnel
links across any size of Bridged network, which would be sub-optimal.
Manual configuration would be needed to raise the link cost so that the
RBridges would prefer links that were actually links, and not Bridged
networks.  If they peaked into the BPDUs, they could probably figure
this out themselves.

 - Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Wednesday, October 19, 2005 9:10 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
thread

When I say "it is sent twice", I mean that the first time it is sent by
A, natively. RB1 does not send it natively, just encapsulated. So
perhaps I misparsed your question. I was answering "how many times does
the packet get sent on that link" and from this question I guess you
were asking "how many times does RB1 transmit the packet on the link."

The answer to THAT question is "once", and it will be encapsulated.

Though with you extra link that you added now, it might be zero,
depending on whether the spanning tree the RBridges calculated from the
link state database, for ingress RBridge RB1, includes that link or not.

So, for your first question:

> Why does RB1 send it onto the Bridged link with a "native" DA
Broadcast?
> If, as you said, F will receive the frame directly from A, then 
> wouldn't this cause F to get two copies?
>

No. RB1 does not send the packet natively. If it did, then F will
receive two copies. But it doesn't. This misunderstanding is that I was
answering a different question than you were asking, apparently.

For your second question:

> Now, the broadcast distribution tree may be (and would probably be
> better) calculated to use the direct link between RB1--RB2 instead of 
> through the Bridged network.  Unfortunately, RB1 probably cannot tell 
> the difference between a direct connection and a Bridged network 
> connection, but let's say it chooses this link.  Now, wouldn't RB2 get

> two copies of the broadcast...or is there more to this - such as some 
> kind of RPF check that is needed.

The RBridges use the link state database to calculate a tree of shortest
paths from RB1. So packets only arrive once.

Radia

Larry Kreeger (kreeger) wrote On 10/19/05 17:53,:
> Radia,
> 
> Why does RB1 send it onto the Bridged link with a "native" DA
Broadcast?
> If, as you said, F will receive the frame directly from A, then 
> wouldn't this cause F to get two copies?
> 
> Also, I'm not sure if using an "all RBridges" DA would work if the 
> RBridges had other connectivity.  For example, if I add a link in the 
> topology between RB1 and RB2,
> 
>  
>   B    C    D    E
>   |    |    |    |
>  RB1--RB2  RB3  RB4
>   |    |    |    |
>  ---------------------
>       |           |
>       F           A
> 
> Now, the broadcast distribution tree may be (and would probably be
> better) calculated to use the direct link between RB1--RB2 instead of 
> through the Bridged network.  Unfortunately, RB1 probably cannot tell 
> the difference between a direct connection and a Bridged network 
> connection, but let's say it chooses this link.  Now, wouldn't RB2 get

> two copies of the broadcast...or is there more to this - such as some 
> kind of RPF check that is needed.
> 
>  - Larry
> 
> From: Radia Perlman [mailto:[email-masked]]
> Sent: Wednesday, October 19, 2005 4:24 PM
> To: Larry Kreeger (kreeger)
> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
> thread
> 
> It is sent twice.
> The first time it is "native", with DA=broadcast
> 
> The second time is encapsulated by RB1, so the packet has outer header

> DA="all RBridges", a shim header with "ingress=RB1", and the inner 
> packet being exactly as transmitted by A.
> 
> Onto other links though...RB1 will transmit it to B unencapsulated, 
> i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and 
> RB4 to E.
> 
> And just a note...in case there were other endnodes on the bridged 
> link, the RBridges don't worry about it...those endnodes receive the 
> packet directly from A.
> 
> So, for instance, F below will receive the packet when A transmitted
it.
> 
>   B    C    D    E
>   |    |    |    |
>  RB1  RB2  RB3  RB4
>   |    |    |    |
>  ---------------------
>       |           |
>       F           A
> 
> 
> 
> Radia
> 
> 
> 
> 
> 
> Larry Kreeger (kreeger) wrote On 10/19/05 16:17,:
> 
>>Radia,
>>
>>In Step 6, is the frame sent onto the link between RB1 and B1 once or
>>3 times?  If once, what is the Ethernet DA?
>>
>>Thanks, Larry
>>
>>From: [email-masked] [mailto:[email-masked]]
>>On Behalf Of Radia Perlman
>>Sent: Wednesday, October 19, 2005 3:57 PM
>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>thread
>>
>>Step 1: The bridges create a single broadcast domain, as seen by the 
>>RBridges. So the RBridges see the following picture:
>>
>>  B    C    D    E
>>  |    |    |    |
>> RB1  RB2  RB3  RB4
>>  |    |    |    |
>> ---------------------
>>                 |
>>                 A
>>
>>Step 2: RB1 is elected DR, so it is the only one that will encapsulate
> 
> 
>>or decapsulate to/from that link.
>>
>>Step 3: A transmits a broadcast or multicast packet
>>
>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since 
>>they are not allowed to process native (non-encapsulated) packets
>>
>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress
> 
> RB1"
> 
>>Step 6: RB1 forwards the encapsulated packet onto the link, with an 
>>outer header with a multicast address "all RBridges"
>>
>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it 
>>in order to send to their upward link (to C, D, and E, respectively).
>>
>>Step 8: (which could certainly happen after 5 or 6...doesn't have to 
>>be in order). RB1 decapsulates the packet and sends it to B.
>>
>>************
>>Hope that helps...
>>
>>Radia
>>
>>
>>
>>
>>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,:
>>
>>
>>>Radia,
>>>
>>>I think I now understand now that the DR election happens only 
>>>between
>>
>>
>>>RBridges on a single shared link - and does not require usage of any 
>>>RBridge topology information.  It would help clarify the data flow 
>>>for
>>
>>
>>>me (and hopefully others) if, given the network diagram below, you 
>>>could please give a step by step description of how a broadcast frame

>>>sent by host A gets through each Bridge and RBridge in this network 
>>>in
>>
>>
>>>order to be received by hosts B,C,D,E if we assume that RB1 is the 
>>>Designated RBridge on the "link" created by the Bridged network 
>>>formed
>>
>>
>>>by Bridges B1,B2,B3,B4.
>>>
>>> B    C    D    E
>>> |    |    |    |
>>>RB1  RB2  RB3  RB4
>>> |    |    |    |
>>> B1---B2---B3---B4
>>>                |
>>>                A
>>>
>>>Thanks, Larry
>>>
>>>From: [email-masked] [mailto:[email-masked]]
>>>On Behalf Of Radia Perlman
>>>Sent: Wednesday, October 19, 2005 9:57 AM
>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>>thread
>>>
>>>The IS-IS Hello protocol is for electing a single unique switch per 
>>>link. It doesn't matter which one it is.
>>>
>>>On the other hand, the spanning tree protocol is picking a special 
>>>single unique bridge per link...the one that is closest to the root.
>>>
>>>The spanning tree algorithm is choosing a tree of shortest paths from

>>>the root.
>>>
>>>IS-IS is not trying to do that. It is just electing one guy on a link

>>>to do special link-specific things.
>>>
>>>Radia
>>>[email-masked]
>>[email-masked]
> [email-masked]

[email-masked]

Content-class: urn:content-classes:message
Date: Thu, 20 Oct 2005 11:39:06 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1618

If nobody else wants to I'm happy to give it a whirl.
Any objections? or anybody else prefer to do it?

Peter

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: Thursday, October 20, 2005 10:24 AM
> Subject: [rbridge] RBridge/bridge interaction
> 
> 
> 
> We've had some useful discussion on this mailing list.
> It would be good if somebody can capture the results (perhaps 
> as a long 
> email) that we can fold into the draft(s) later. Any volunteers?
> 
> I don't know if we will have additional issues in this space 
> or that it 
> otherwise makes sense devoting agenda time to it in Vancouver.
> 
> For instance, while I'm convinced that BLOCK works, I wonder 
> if there is 
> something in PARTICIPATE PER PORT that can make the 
> interaction work better.
> 
> Two cases to consider:
> 1. The elected forwarder dies and a new one gets elected. How quickly 
> can packets sent by stations in the bridged cloud fail over 
> to go to the 
> new elected forwarder?
> 
> 2. We have two separate bridged domains, each with their elected 
> forwarder. Somebody connects the two bridged domains together with a 
> wire. This can cause a temporary loop until a single elected 
> forwarder 
> is picked by the RBridges.
> 
> Can some form of PARTICIPATE PER PORT scheme makes things work 
> better/faster in those two cases?
> 
>     Erik
> 
> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
> 
> 

Date: Thu, 20 Oct 2005 07:23:34 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] RBridge/bridge interaction
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1021

We've had some useful discussion on this mailing list.
It would be good if somebody can capture the results (perhaps as a long 
email) that we can fold into the draft(s) later. Any volunteers?

I don't know if we will have additional issues in this space or that it 
otherwise makes sense devoting agenda time to it in Vancouver.

For instance, while I'm convinced that BLOCK works, I wonder if there is 
something in PARTICIPATE PER PORT that can make the interaction work better.

Two cases to consider:
1. The elected forwarder dies and a new one gets elected. How quickly 
can packets sent by stations in the bridged cloud fail over to go to the 
new elected forwarder?

2. We have two separate bridged domains, each with their elected 
forwarder. Somebody connects the two bridged domains together with a 
wire. This can cause a temporary loop until a single elected forwarder 
is picked by the RBridges.

Can some form of PARTICIPATE PER PORT scheme makes things work 
better/faster in those two cases?

    Erik

Date: Wed, 19 Oct 2005 21:09:50 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7609

When I say "it is sent twice", I mean that the first time
it is sent by A, natively. RB1 does not send it natively, just
encapsulated. So perhaps I misparsed your question. I was answering
"how many times does the packet get sent on that link" and
from this question I guess you were asking "how many times
does RB1 transmit the packet on the link."

The answer to THAT question is "once", and it will be encapsulated.

Though with you extra link that you added now, it might be zero,
depending on whether the spanning tree the RBridges calculated
from the link state database, for ingress RBridge RB1, includes
that link or not.

So, for your first question:

> Why does RB1 send it onto the Bridged link with a "native" DA Broadcast?
> If, as you said, F will receive the frame directly from A, then wouldn't
> this cause F to get two copies?
>

No. RB1 does not send the packet natively. If it did, then F
will receive two copies. But it doesn't. This misunderstanding is
that I was answering a different question than you were asking,
apparently.

For your second question:

> Now, the broadcast distribution tree may be (and would probably be
> better) calculated to use the direct link between RB1--RB2 instead of
> through the Bridged network.  Unfortunately, RB1 probably cannot tell
> the difference between a direct connection and a Bridged network
> connection, but let's say it chooses this link.  Now, wouldn't RB2 get
> two copies of the broadcast...or is there more to this - such as some
> kind of RPF check that is needed.

The RBridges use the link state database to calculate a tree of
shortest paths from RB1. So packets only arrive once.

Radia

Larry Kreeger (kreeger) wrote On 10/19/05 17:53,:
> Radia,
> 
> Why does RB1 send it onto the Bridged link with a "native" DA Broadcast?
> If, as you said, F will receive the frame directly from A, then wouldn't
> this cause F to get two copies?
> 
> Also, I'm not sure if using an "all RBridges" DA would work if the
> RBridges had other connectivity.  For example, if I add a link in the
> topology between RB1 and RB2,
> 
>  
>   B    C    D    E
>   |    |    |    |
>  RB1--RB2  RB3  RB4
>   |    |    |    |
>  ---------------------
>       |           |
>       F           A
> 
> Now, the broadcast distribution tree may be (and would probably be
> better) calculated to use the direct link between RB1--RB2 instead of
> through the Bridged network.  Unfortunately, RB1 probably cannot tell
> the difference between a direct connection and a Bridged network
> connection, but let's say it chooses this link.  Now, wouldn't RB2 get
> two copies of the broadcast...or is there more to this - such as some
> kind of RPF check that is needed.
> 
>  - Larry
> 
> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Wednesday, October 19, 2005 4:24 PM
> To: Larry Kreeger (kreeger)
> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
> thread
> 
> It is sent twice.
> The first time it is "native", with DA=broadcast
> 
> The second time is encapsulated by RB1, so the packet has outer header
> DA="all RBridges", a shim header with "ingress=RB1", and the inner
> packet being exactly as transmitted by A.
> 
> Onto other links though...RB1 will transmit it to B unencapsulated,
> i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and RB4
> to E.
> 
> And just a note...in case there were other endnodes on the bridged link,
> the RBridges don't worry about it...those endnodes receive the packet
> directly from A.
> 
> So, for instance, F below will receive the packet when A transmitted it.
> 
>   B    C    D    E
>   |    |    |    |
>  RB1  RB2  RB3  RB4
>   |    |    |    |
>  ---------------------
>       |           |
>       F           A
> 
> 
> 
> Radia
> 
> 
> 
> 
> 
> Larry Kreeger (kreeger) wrote On 10/19/05 16:17,:
> 
>>Radia,
>>
>>In Step 6, is the frame sent onto the link between RB1 and B1 once or 
>>3 times?  If once, what is the Ethernet DA?
>>
>>Thanks, Larry
>>
>>From: [email-masked] [mailto:[email-masked]] 
>>On Behalf Of Radia Perlman
>>Sent: Wednesday, October 19, 2005 3:57 PM
>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>thread
>>
>>Step 1: The bridges create a single broadcast domain, as seen by the 
>>RBridges. So the RBridges see the following picture:
>>
>>  B    C    D    E
>>  |    |    |    |
>> RB1  RB2  RB3  RB4
>>  |    |    |    |
>> ---------------------
>>                 |
>>                 A
>>
>>Step 2: RB1 is elected DR, so it is the only one that will encapsulate
> 
> 
>>or decapsulate to/from that link.
>>
>>Step 3: A transmits a broadcast or multicast packet
>>
>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since 
>>they are not allowed to process native (non-encapsulated) packets
>>
>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress
> 
> RB1"
> 
>>Step 6: RB1 forwards the encapsulated packet onto the link, with an 
>>outer header with a multicast address "all RBridges"
>>
>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it 
>>in order to send to their upward link (to C, D, and E, respectively).
>>
>>Step 8: (which could certainly happen after 5 or 6...doesn't have to 
>>be in order). RB1 decapsulates the packet and sends it to B.
>>
>>************
>>Hope that helps...
>>
>>Radia
>>
>>
>>
>>
>>Larry Kreeger (kreeger) wrote On 10/19/05 15:25,:
>>
>>
>>>Radia,
>>>
>>>I think I now understand now that the DR election happens only between
>>
>>
>>>RBridges on a single shared link - and does not require usage of any 
>>>RBridge topology information.  It would help clarify the data flow for
>>
>>
>>>me (and hopefully others) if, given the network diagram below, you 
>>>could please give a step by step description of how a broadcast frame 
>>>sent by host A gets through each Bridge and RBridge in this network in
>>
>>
>>>order to be received by hosts B,C,D,E if we assume that RB1 is the 
>>>Designated RBridge on the "link" created by the Bridged network formed
>>
>>
>>>by Bridges B1,B2,B3,B4.
>>>
>>> B    C    D    E
>>> |    |    |    |
>>>RB1  RB2  RB3  RB4
>>> |    |    |    |
>>> B1---B2---B3---B4
>>>                |
>>>                A
>>>
>>>Thanks, Larry
>>>
>>>From: [email-masked] [mailto:[email-masked]]
>>>On Behalf Of Radia Perlman
>>>Sent: Wednesday, October 19, 2005 9:57 AM
>>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>>thread
>>>
>>>The IS-IS Hello protocol is for electing a single unique switch per 
>>>link. It doesn't matter which one it is.
>>>
>>>On the other hand, the spanning tree protocol is picking a special 
>>>single unique bridge per link...the one that is closest to the root.
>>>
>>>The spanning tree algorithm is choosing a tree of shortest paths from 
>>>the root.
>>>
>>>IS-IS is not trying to do that. It is just electing one guy on a link 
>>>to do special link-specific things.
>>>
>>>Radia
>>>[email-masked]
>>[email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 19 Oct 2005 17:53:37 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5545

Radia,

Why does RB1 send it onto the Bridged link with a "native" DA Broadcast?
If, as you said, F will receive the frame directly from A, then wouldn't
this cause F to get two copies?

Also, I'm not sure if using an "all RBridges" DA would work if the
RBridges had other connectivity.  For example, if I add a link in the
topology between RB1 and RB2,

  B    C    D    E
  |    |    |    |
 RB1--RB2  RB3  RB4
  |    |    |    |
 ---------------------
      |           |
      F           A

Now, the broadcast distribution tree may be (and would probably be
better) calculated to use the direct link between RB1--RB2 instead of
through the Bridged network.  Unfortunately, RB1 probably cannot tell
the difference between a direct connection and a Bridged network
connection, but let's say it chooses this link.  Now, wouldn't RB2 get
two copies of the broadcast...or is there more to this - such as some
kind of RPF check that is needed.

 - Larry

-----Original Message-----
From: Radia Perlman [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2005 4:24 PM
To: Larry Kreeger (kreeger)
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
thread

It is sent twice.
The first time it is "native", with DA=broadcast

The second time is encapsulated by RB1, so the packet has outer header
DA="all RBridges", a shim header with "ingress=RB1", and the inner
packet being exactly as transmitted by A.

Onto other links though...RB1 will transmit it to B unencapsulated,
i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and RB4
to E.

And just a note...in case there were other endnodes on the bridged link,
the RBridges don't worry about it...those endnodes receive the packet
directly from A.

So, for instance, F below will receive the packet when A transmitted it.

  B    C    D    E
  |    |    |    |
 RB1  RB2  RB3  RB4
  |    |    |    |
 ---------------------
      |           |
      F           A

Radia

Larry Kreeger (kreeger) wrote On 10/19/05 16:17,:
> Radia,
> 
> In Step 6, is the frame sent onto the link between RB1 and B1 once or 
> 3 times?  If once, what is the Ethernet DA?
> 
> Thanks, Larry
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Radia Perlman
> Sent: Wednesday, October 19, 2005 3:57 PM
> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
> thread
> 
> Step 1: The bridges create a single broadcast domain, as seen by the 
> RBridges. So the RBridges see the following picture:
> 
>   B    C    D    E
>   |    |    |    |
>  RB1  RB2  RB3  RB4
>   |    |    |    |
>  ---------------------
>                  |
>                  A
> 
> Step 2: RB1 is elected DR, so it is the only one that will encapsulate

> or decapsulate to/from that link.
> 
> Step 3: A transmits a broadcast or multicast packet
> 
> Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since 
> they are not allowed to process native (non-encapsulated) packets
> 
> Step 5: RB1 encapsulates it to be sent over spanning tree "ingress
RB1"
> 
> Step 6: RB1 forwards the encapsulated packet onto the link, with an 
> outer header with a multicast address "all RBridges"
> 
> Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it 
> in order to send to their upward link (to C, D, and E, respectively).
> 
> Step 8: (which could certainly happen after 5 or 6...doesn't have to 
> be in order). RB1 decapsulates the packet and sends it to B.
> 
> ************
> Hope that helps...
> 
> Radia
> 
> 
> 
> 
> Larry Kreeger (kreeger) wrote On 10/19/05 15:25,:
> 
>>Radia,
>>
>>I think I now understand now that the DR election happens only between
> 
> 
>>RBridges on a single shared link - and does not require usage of any 
>>RBridge topology information.  It would help clarify the data flow for
> 
> 
>>me (and hopefully others) if, given the network diagram below, you 
>>could please give a step by step description of how a broadcast frame 
>>sent by host A gets through each Bridge and RBridge in this network in
> 
> 
>>order to be received by hosts B,C,D,E if we assume that RB1 is the 
>>Designated RBridge on the "link" created by the Bridged network formed
> 
> 
>>by Bridges B1,B2,B3,B4.
>>
>>  B    C    D    E
>>  |    |    |    |
>> RB1  RB2  RB3  RB4
>>  |    |    |    |
>>  B1---B2---B3---B4
>>                 |
>>                 A
>>
>>Thanks, Larry
>>
>>From: [email-masked] [mailto:[email-masked]]
>>On Behalf Of Radia Perlman
>>Sent: Wednesday, October 19, 2005 9:57 AM
>>Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
>>thread
>>
>>The IS-IS Hello protocol is for electing a single unique switch per 
>>link. It doesn't matter which one it is.
>>
>>On the other hand, the spanning tree protocol is picking a special 
>>single unique bridge per link...the one that is closest to the root.
>>
>>The spanning tree algorithm is choosing a tree of shortest paths from 
>>the root.
>>
>>IS-IS is not trying to do that. It is just electing one guy on a link 
>>to do special link-specific things.
>>
>>Radia
>>[email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 19 Oct 2005 16:17:33 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3376

Radia,

In Step 6, is the frame sent onto the link between RB1 and B1 once or 3
times?  If once, what is the Ethernet DA? 

Thanks, Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Wednesday, October 19, 2005 3:57 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
thread

Step 1: The bridges create a single broadcast domain, as seen by the
RBridges. So the RBridges see the following picture:

  B    C    D    E
  |    |    |    |
 RB1  RB2  RB3  RB4
  |    |    |    |
 ---------------------
                 |
                 A

Step 2: RB1 is elected DR, so it is the only one that will encapsulate
or decapsulate to/from that link.

Step 3: A transmits a broadcast or multicast packet

Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since they
are not allowed to process native (non-encapsulated) packets

Step 5: RB1 encapsulates it to be sent over spanning tree "ingress RB1"

Step 6: RB1 forwards the encapsulated packet onto the link, with an
outer header with a multicast address "all RBridges"

Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it in
order to send to their upward link (to C, D, and E, respectively).

Step 8: (which could certainly happen after 5 or 6...doesn't have to be
in order). RB1 decapsulates the packet and sends it to B.

************
Hope that helps...

Radia

Larry Kreeger (kreeger) wrote On 10/19/05 15:25,:
> Radia,
> 
> I think I now understand now that the DR election happens only between

> RBridges on a single shared link - and does not require usage of any 
> RBridge topology information.  It would help clarify the data flow for

> me (and hopefully others) if, given the network diagram below, you 
> could please give a step by step description of how a broadcast frame 
> sent by host A gets through each Bridge and RBridge in this network in

> order to be received by hosts B,C,D,E if we assume that RB1 is the 
> Designated RBridge on the "link" created by the Bridged network formed

> by Bridges B1,B2,B3,B4.
>   B    C    D    E
>   |    |    |    |
>  RB1  RB2  RB3  RB4
>   |    |    |    |
>   B1---B2---B3---B4
>                  |
>                  A
> Thanks, Larry
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Radia Perlman
> Sent: Wednesday, October 19, 2005 9:57 AM
> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
> thread
> 
> The IS-IS Hello protocol is for electing a single unique switch per 
> link. It doesn't matter which one it is.
> 
> On the other hand, the spanning tree protocol is picking a special 
> single unique bridge per link...the one that is closest to the root.
> 
> The spanning tree algorithm is choosing a tree of shortest paths from 
> the root.
> 
> IS-IS is not trying to do that. It is just electing one guy on a link 
> to do special link-specific things.
> 
> Radia
> [email-masked]

[email-masked]

Date: Wed, 19 Oct 2005 15:56:45 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2807

Step 1: The bridges create a single broadcast domain, as seen by the
RBridges. So the RBridges see the following picture:

  B    C    D    E
  |    |    |    |
 RB1  RB2  RB3  RB4
  |    |    |    |
 ---------------------
                 |
                 A

Step 2: RB1 is elected DR, so it is the only one that will
encapsulate or decapsulate to/from that link.

Step 3: A transmits a broadcast or multicast packet

Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it
away since they are not allowed to process native (non-encapsulated)
packets

Step 5: RB1 encapsulates it to be sent over spanning tree
"ingress RB1"

Step 6: RB1 forwards the encapsulated packet onto the link,
with an outer header with a multicast address "all RBridges"

Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate
it in order to send to their upward link (to C, D, and E,
respectively).

Step 8: (which could certainly happen after 5 or 6...doesn't have
to be in order). RB1 decapsulates the packet and sends it to B.

************
Hope that helps...

Radia

Larry Kreeger (kreeger) wrote On 10/19/05 15:25,:
> Radia,
> 
> I think I now understand now that the DR election happens only between
> RBridges on a single shared link - and does not require usage of any
> RBridge topology information.  It would help clarify the data flow for
> me (and hopefully others) if, given the network diagram below, you could
> please give a step by step description of how a broadcast frame sent by
> host A gets through each Bridge and RBridge in this network in order to
> be received by hosts B,C,D,E if we assume that RB1 is the Designated
> RBridge on the "link" created by the Bridged network formed by Bridges
> B1,B2,B3,B4.
> 
>   B    C    D    E
>   |    |    |    |
>  RB1  RB2  RB3  RB4
>   |    |    |    |
>   B1---B2---B3---B4
>                  |
>                  A
> 
> Thanks, Larry
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Radia Perlman
> Sent: Wednesday, October 19, 2005 9:57 AM
> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
> thread
> 
> The IS-IS Hello protocol is for electing a single unique switch per
> link. It doesn't matter which one it is.
> 
> On the other hand, the spanning tree protocol is picking a special
> single unique bridge per link...the one that is closest to the root.
> 
> The spanning tree algorithm is choosing a tree of shortest paths from
> the root.
> 
> IS-IS is not trying to do that. It is just electing one guy on a link to
> do special link-specific things.
> 
> Radia
> [email-masked]

Content-class: urn:content-classes:message
Date: Wed, 19 Oct 2005 15:25:37 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1463

Radia,

I think I now understand now that the DR election happens only between
RBridges on a single shared link - and does not require usage of any
RBridge topology information.  It would help clarify the data flow for
me (and hopefully others) if, given the network diagram below, you could
please give a step by step description of how a broadcast frame sent by
host A gets through each Bridge and RBridge in this network in order to
be received by hosts B,C,D,E if we assume that RB1 is the Designated
RBridge on the "link" created by the Bridged network formed by Bridges
B1,B2,B3,B4.

  B    C    D    E
  |    |    |    |
 RB1  RB2  RB3  RB4
  |    |    |    |
  B1---B2---B3---B4
                 |
                 A

Thanks, Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Wednesday, October 19, 2005 9:57 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
thread

The IS-IS Hello protocol is for electing a single unique switch per
link. It doesn't matter which one it is.

On the other hand, the spanning tree protocol is picking a special
single unique bridge per link...the one that is closest to the root.

The spanning tree algorithm is choosing a tree of shortest paths from
the root.

IS-IS is not trying to do that. It is just electing one guy on a link to
do special link-specific things.

Radia

Date: Wed, 19 Oct 2005 09:57:00 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3633

The IS-IS Hello protocol is for electing a single unique switch per 
link. It doesn't matter which one it is.

On the other hand, the spanning tree protocol is picking a special 
single unique bridge per link...the
one that is closest to the root.

The spanning tree algorithm is choosing a tree of shortest paths from 
the root.

IS-IS is not trying to do that. It is just electing one guy on a link to 
do special link-specific things.

Radia

Joe Touch wrote:

>Saikat Ray wrote:
>  
>
>>Saikat Ray wrote:
>>
>>    
>>
>>>Now you can have an rbridge and an sbridge in the same L2 (how do you
>>>know you don't?). They form an undetectable, uncorrectable loop.
>>>
>>>
>>>[Saikat] I do not see how this happens. First I am assuming that if
>>>"sbridges" are connected by physical links, then they know how to avoid
>>>packet loops by some mechanism they choose to implement. Now, as far as
>>>"sbridges" are concerned, the network consisting of RBridges, STP-running
>>>bridges, physical links etc., is simply a "link". In other words, the
>>>      
>>>
>>entire
>>
>>    
>>
>>>network (consisting of RBridges, STP-running bridges, physical links etc.)
>>>could be replaced by a physical link. Thus even in this case, there would
>>>      
>>>
>>be
>>
>>    
>>
>>>no packet loop in the steady state.
>>>
>>>Another way of looking at this argument is the following. Suppose you
>>>      
>>>
>>remove
>>
>>    
>>
>>>all the RBridges from the network. sBridges and legacy bridges are left,
>>>      
>>>
>>and
>>
>>    
>>
>>>the assumption is that in that case, at least, a loop-free network
>>>      
>>>
>>results.
>>
>>    
>>
>>>Then when you add RBridges (in their original position), the rest of the
>>>network is simply one or more "link"s, and RBridges would ensure that
>>>      
>>>
>>there
>>
>>    
>>
>>>would be no loops.
>>>      
>>>
>>Except that the rbridges add a 'link' between themselves - that's the
>>extra 'link' that can cause the loop.
>>
>>Joe
>>
>>[Saikat] We discussed this possibility before (Radia and I exchanged a
>>couple of emails). When RBbridges add a "link" between themselves (actually
>>you need to consider only the scenario when "designated" RBridges add a
>>"link" between themselves), there will be a temporary loop. Then the
>>designated RBridges will start seeing each others' hello messages, and they
>>will know that there is a loop. In that case, all but one designated
>>RBridges (who are connected to themselves by a single "link") will
>>"de-designate" themselves. Thus in the steady state there would be no loop.
>>
>>Thinking more about the problem of "Lateral compatibility"---i.e. when there
>>is a third protocol (the one your imaginary "sBridge" implements) that do
>>not know about RBridges and vice versa---I am quite convinced that *if* all
>>the protocols jointly converge to a steady state, there will be no loop in
>>the system. This basically follows from the fact that in the steady state,
>>each given protocol can view the rest of the network as one or more "links".
>>However, in the presence of 3 or more protocols, it is not clear to me
>>whether joint convergence to a steady state is guaranteed in all cases (I
>>posted a message regarding this before). I tend to believe that in
>>"ordinary" cases it should, but there may exist special cases...
>>    
>>
>
>If all this is true, why not do this for ordinary bridges?
>
>Joe
>  
>
>------------------------------------------------------------------------
>
>[email-masked]

From: "Saikat Ray" <[email-masked]>
To: "'Joe Touch'" <[email-masked]>
Date: Wed, 19 Oct 2005 10:36:24 -0400
Organization: University of Pennsylvania
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3693

>>Now you can have an rbridge and an sbridge in the same L2 (how do you
>>know you don't?). They form an undetectable, uncorrectable loop.
>>
>>
>>[Saikat] I do not see how this happens. First I am assuming that if
>>"sbridges" are connected by physical links, then they know how to avoid
>>packet loops by some mechanism they choose to implement. Now, as far as
>>"sbridges" are concerned, the network consisting of RBridges, STP-running
>>bridges, physical links etc., is simply a "link". In other words, the
> 
> entire
> 
>>network (consisting of RBridges, STP-running bridges, physical links etc.)
>>could be replaced by a physical link. Thus even in this case, there would
> 
> be
> 
>>no packet loop in the steady state.
>>
>>Another way of looking at this argument is the following. Suppose you
> 
> remove
> 
>>all the RBridges from the network. sBridges and legacy bridges are left,
> 
> and
> 
>>the assumption is that in that case, at least, a loop-free network
> 
> results.
> 
>>Then when you add RBridges (in their original position), the rest of the
>>network is simply one or more "link"s, and RBridges would ensure that
> 
> there
> 
>>would be no loops.
> 
> 
> Except that the rbridges add a 'link' between themselves - that's the
> extra 'link' that can cause the loop.
> 
> Joe
> 
> [Saikat] We discussed this possibility before (Radia and I exchanged a
> couple of emails). When RBbridges add a "link" between themselves
(actually
> you need to consider only the scenario when "designated" RBridges add a
> "link" between themselves), there will be a temporary loop. Then the
> designated RBridges will start seeing each others' hello messages, and
they
> will know that there is a loop. In that case, all but one designated
> RBridges (who are connected to themselves by a single "link") will
> "de-designate" themselves. Thus in the steady state there would be no
loop.
> 
> Thinking more about the problem of "Lateral compatibility"---i.e. when
there
> is a third protocol (the one your imaginary "sBridge" implements) that do
> not know about RBridges and vice versa---I am quite convinced that *if*
all
> the protocols jointly converge to a steady state, there will be no loop in
> the system. This basically follows from the fact that in the steady state,
> each given protocol can view the rest of the network as one or more
"links".
> However, in the presence of 3 or more protocols, it is not clear to me
> whether joint convergence to a steady state is guaranteed in all cases (I
> posted a message regarding this before). I tend to believe that in
> "ordinary" cases it should, but there may exist special cases...

If all this is true, why not do this for ordinary bridges?

Joe

[Saikat] I just sent an email yesterday to the list regarding the situation
if ordinary bridges simply choose an arbitrary "designated" bridge per LAN
without regard to its distance from a given bridge (the "root"). Probably
you missed it. You can check it here.

http://www.postel.org/pipermail/rbridge/2005-October/000744.html

Basically, loops are avoided, but the network may end up disconnected! This
does not happen in RBridges because RBridges send *encapsulated* packets
without any restriction, which preserve connectivity. In other words, if you
allow ordinary bridges to encapsulate packets and send them without any
topological restriction, then you could as well use an arbitrary designated
bridge per LAN, but then ordinary bridges would simply become RBridges! In
other words, the critical difference between the ordinary bridge and RBridge
(in my mind, at least) is that ordinary bridges are not allowed to modify
the data packets in any way, but RBridges are.

Date: Tue, 18 Oct 2005 18:40:16 -0700
From: Joe Touch <[email-masked]>
To: [email-masked]
Cc: "'Developing a hybrid router/bridge.'" <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3450

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1FC76960D69853CF464B7017
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Saikat Ray wrote:
> Saikat Ray wrote:
> 
>>Now you can have an rbridge and an sbridge in the same L2 (how do you
>>know you don't?). They form an undetectable, uncorrectable loop.
>>
>>
>>[Saikat] I do not see how this happens. First I am assuming that if
>>"sbridges" are connected by physical links, then they know how to avoid
>>packet loops by some mechanism they choose to implement. Now, as far as
>>"sbridges" are concerned, the network consisting of RBridges, STP-running
>>bridges, physical links etc., is simply a "link". In other words, the
> 
> entire
> 
>>network (consisting of RBridges, STP-running bridges, physical links etc.)
>>could be replaced by a physical link. Thus even in this case, there would
> 
> be
> 
>>no packet loop in the steady state.
>>
>>Another way of looking at this argument is the following. Suppose you
> 
> remove
> 
>>all the RBridges from the network. sBridges and legacy bridges are left,
> 
> and
> 
>>the assumption is that in that case, at least, a loop-free network
> 
> results.
> 
>>Then when you add RBridges (in their original position), the rest of the
>>network is simply one or more "link"s, and RBridges would ensure that
> 
> there
> 
>>would be no loops.
> 
> 
> Except that the rbridges add a 'link' between themselves - that's the
> extra 'link' that can cause the loop.
> 
> Joe
> 
> [Saikat] We discussed this possibility before (Radia and I exchanged a
> couple of emails). When RBbridges add a "link" between themselves (actually
> you need to consider only the scenario when "designated" RBridges add a
> "link" between themselves), there will be a temporary loop. Then the
> designated RBridges will start seeing each others' hello messages, and they
> will know that there is a loop. In that case, all but one designated
> RBridges (who are connected to themselves by a single "link") will
> "de-designate" themselves. Thus in the steady state there would be no loop.
> 
> Thinking more about the problem of "Lateral compatibility"---i.e. when there
> is a third protocol (the one your imaginary "sBridge" implements) that do
> not know about RBridges and vice versa---I am quite convinced that *if* all
> the protocols jointly converge to a steady state, there will be no loop in
> the system. This basically follows from the fact that in the steady state,
> each given protocol can view the rest of the network as one or more "links".
> However, in the presence of 3 or more protocols, it is not clear to me
> whether joint convergence to a steady state is guaranteed in all cases (I
> posted a message regarding this before). I tend to believe that in
> "ordinary" cases it should, but there may exist special cases...

If all this is true, why not do this for ordinary bridges?

Joe

--------------enig1FC76960D69853CF464B7017
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig1FC76960D69853CF464B7017--

Date: Wed, 19 Oct 2005 06:04:31 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1712

Thanks for doing the summaries.

Radia Perlman wrote:

> I'm assuming Peter is saying the same thing I am. But without speaking 
> for him, let me say
> a) RBridges have to block. That's a nice simple clean thing to do. It works
> b) I don't understand why people think there is a problem, and I don't 
> think they've
> stated what they are worried about clearly enough, at least for me to 
> understand it

Having caught up on trill email, it seems like the root of the concern 
that Joe has (and I haven't seen others express it) is that things are 
simple to understand if the rbridged cloud can be abstracted as a single 
bridge. I would agree that things are harder to understand if this is 
not the case.

My take is that there can be different abstractions in the data plane 
and the control plane. In the data plane I think we all want the 
rbridged cloud to behave as a single bridge (for instance, a packet to 
an unknown destination would be flooded to all ports of this conceptual 
bridge).

But for the control plane we have (at least) two choices:
  - make the rbridge cloud behave exactly as a single bridge from the 
perspective of an observer that can look at all the ports of this 
conceptual bridge
  - make the rbridge cloud behave in a way that interoperates with (does 
not violate any assumptions of) the bridged networks they interconnect.

My understanding is that Joe has been arguing for the former.
But this seems to lead to undesirable behavior due to the 
interdependency of 802.1D and RBridges. For instance, the bridges would 
pick a single root bridge for the whole campus, and should the root 
bridge fail it will affect the whole campus until 802.1D has converged.

    Erik

Date: Wed, 19 Oct 2005 05:11:04 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 415

Joe Touch wrote:

> What exactly are rbridges 'like' if they BLOCK?

I think they would be like IP multicast routers, but operating at L2 
instead of L3. Multicast routers, unlike IP unicast routers, need to be 
concerned with multiple next-hops picking up the same packet. Same issue 
appears for RBridges. The proposed solution for RBridges is what we have 
for multicast (a single elected forwarder).

    Erik

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 18 Oct 2005 19:39:07 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2074

This I believe is what he was alluding too in his example. In
Particular he was asserting that if the DR mechanism can work without
looking at BPDUS then why can't it work in a regular bridge without BPDUS.
The answer I believe to that question is that it could but you would lose
the ability to compute a shortest path first tree to a preferred root. You'd
just converge on some tree.

[Saikat] In the legacy network, if you choose an arbitrary bridge connected
to a LAN segment as its designated bridge, then you do avoid loops, but you
may end up in a disconnected network! I am not good at ASCII art, but I will
try to show an example.
                      ___
                      |_|
                       | 
                _______|_________
                       |
                      _|_
                      | |
                     /---\
      ______________/     \__________________
               _|_                _|__
               |_|                |__|

Assume that there are three LAN segments (the straight lines) and 4 bridges
(the boxes). One of the bridges is connected to all the 3 LAN segments; the
rest 3 bridges connect these three LAN segments to the rest of the network
(i.e. the network has more LAN segments). Now if there is an arbitrary
bridge designation process that does not look into the distance from root,
then all the three LANs may choose the middle bridge as their designated
bridge, and then this part of the network would be disconnected from the
rest because the other three bridges will not send/receive packets to/from
these LAN segments.

In the RBridge case, of course, the system works because RBridges send
encapsulated packets without restriction. Legacy bridges did not have that
luxury, I guess!

Hopefully some of this or the previous explanation is enough to 
convince folks that BLOCK does indeed work. .. if not ... well I'm 
out of ideas too.

  Peter

[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 18 Oct 2005 17:47:51 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2421

Well if you need help with the drafts I do have a bit of bandwidth
at the moment and would be happy to help out if I can.

Peter

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gray, Eric
> Sent: Tuesday, October 18, 2005 4:05 PM
> To: 'Developing a hybrid router/bridge.'
> Subject: Re: [rbridge] Time to summarize "forward or block" 
> BPDU thread
> 
> 
> Joe,
> 
> 	I am deeply concerned that there seems to be some 
> differences in opinion between those that are working on the 
> draft(s?) and a lot of the rest of the working group.
> 
> 	More-over, I am not sure that the differences are 
> entirely in terminology.  But I guess we'll just have to wait 
> and see...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]]On
> --> Behalf Of Joe Touch
> --> Sent: Monday, October 17, 2005 10:27 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] Time to summarize "forward or block" 
> --> BPDU thread
> --> 
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
> --> 
> 
> Earlier you wrote (and by the way I wish I didn't have to do it 
> this way, but your E-Mail is broken :-):
> 
> 
> 
> Harald Tveit Alvestrand wrote:
> > 
> > 
> > --On 17. oktober 2005 05:17 -0700 Joe Touch <[email-masked]> wrote:
> > 
> >> WHEN (note the use of 'when', not 'if', since there's 
> *nothing* that 
> >> can be done to enforce this) this isn't the case, the following 
> >> problems
> >> arise:
> >>
> >>     a) there is no way to detect the error
> >>
> >>     b) loops *will* occur
> > 
> > 
> > You know, I really can't tell whether this is true or not without 
> > looking at the protocol specification that says how the RBridges 
> > detect each other.
> > 
> > Should this discussion wait for the drafts to come out?
> 
> As someone trying to write the drafts, I'm trying to 
> understand the terminology that will determine this.
> 
> I have a MUCH better idea of how to explain things now - 
> whether I agree with them at all levels or not, so this 
> discussion IS helping, FWIW.
> 
> Joe
> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
> 
> 

Date: Tue, 18 Oct 2005 23:40:53 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: [rbridge] Non-Spanning-Tree bridges do exist
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1606

--==========B12939CA737273ACCFFD==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

My curiosity got the better of me....

I remembered that the el-cheapo switch I'm using as a junction box in my=20
office had 2 spare ports.
So I crawled under my desk and connected a wire between the two.

Sure enough, in a little while the two lamps turned green; a little later=20
the lamps started flashing, and just a few moments later, ALL the lamps on=20
the box started flashing.

I had created a broadcast storm.

I hurriedly disconnected the link, and the network went back to normal. End =

of experiment.

Conclusion:
Not all bridges implement spanning tree.
Users who have physical access to such a device, and connect wires without=20
thinking, can create broadcast storms.
But as long as the physical topology is a tree, they do no harm.

Not sure what implications this has for this group.

(note: Either this device is in category BLOCK, or it's TRANSPARENT, and=20
ALL the switches in my house, which are of about 4 different makes, all of=20
them cheap, fail to implement any form of ST - because I don't see any=20
BPDUs on the wire).

                  Harald

--==========B12939CA737273ACCFFD==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========B12939CA737273ACCFFD==========--

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 18 Oct 2005 18:17:48 -0300
Subject: Re: [rbridge] MAN scale and future uses of Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 12217

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5D429.0D39D04C
Content-Type: text/plain;
	charset="iso-8859-1"

Alia,
 
    Slightly larger is large enough for people who are just a little too
large
to have a simple bridged network.  It may also be large enough if routing
table size is forcing larger L2 networks to be as large as possible and no
other choices exist.
 
--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Alia Atlas
Sent: Monday, October 17, 2005 3:02 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] MAN scale and future uses of Rbridge

On 10/17/05, Peter Ashwood-Smith < [email-masked]
<mailto:[email-masked]> > wrote: 

I think the main impediment to very large scale is the large flat address
space and its rate of change. Not the number or Rbridge nodes and
networks/links. While use of IS-IS or OSPF areas can help when addressing is
hierarchical, they are not going to help much when you cannot aggregate the
addresses into specific areas.

There are environments where the rate of change could be reasonably bounded,
so that brings it back to the flat address space...

Then again I don't think that Rbridge needs to scale that large to be
enormously useful. If it pushes the attainable size out a bit, gives better
routes, is more stable and allows future innovations based on the topology
it is going to be very useful. After that .. well its routers all the way
down ;)

What do you think is large enough?  (I remember the discussion earlier, but
not specific numbers.)

Alia 

Peter 

-----Original Message-----
From: [email-masked] <mailto:[email-masked]>
[mailto:  <mailto:[email-masked]> [email-masked]] On
Behalf Of Alia Atlas
Sent: Monday, October 17, 2005 2:37 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] MAN scale and future uses of Rbridge

On 10/17/05, Sofia, Rute < [email-masked]
<mailto:[email-masked]> > wrote: 

Considering Rbridges application from a MAN scope, other scalability
issues relate to:
-  storage cost (the price of flat addressing and of having every
Rbridge learning both requested and unrequested MAC destination 
addresses) may be decreased, but is something that has not be considered
up until now, given that the scope is limited to a campus...

 What number of MAC addresses is the target for the rbridge campus?   Do you
think the constraints are on the memory or on the notifications required due
to changes? 

- scalability related to the IS-IS tuning. On this point, (I am not
completely sure about the price but...), there is a price to pay to tune 
IS-IS in order to achieve convergence in the order of hundreds of
seconds. This is another issue to be checked.

Is there a reason that different areas couldn't be used in the IS-IS
instance for rbridges?
Do you think this would be adequate?  Are the topological restrictions (i.e.
hub and spoke)
acceptable?  Could we work around that?

Summing up, these are issues to be considered *if* Rbridges is to be
extended to something larger than a campus. But going back to the 
participate vs. non-participate in the ST issue, then the scope is
something that may help in deciding this issue. As I said, I do not see
that Rbridges need to intervene *if* the scope is limited to a campus.
Why? Because as stated in Radia's paper, Rbridges can simply terminate
STs, which makes all the sense given that a Rbridge is a hybrid router.
But this scenario does not seem to make the same sense, if a MAN scope
is considered...

While improving the scalability may not be immediately in scope, I think it
is
worthwhile to consider where the restrictions are coming from.

Alia

_______________________________________________
rbridge mailing list
[email-masked] <mailto:[email-masked]> 
http://www.postel.org/mailman/listinfo/rbridge
<http://www.postel.org/mailman/listinfo/rbridge> 

------_=_NextPart_001_01C5D429.0D39D04C
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 6.00.2800.1515" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff 
size=2>Alia,</FONT></SPAN></DIV>
<DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=186231521-18102005>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>Slightly larger is large enough for people who are just a 
little too large</FONT></SPAN></DIV>
<DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2>to 
have a simple bridged network.&nbsp; It may also be large enough 
if&nbsp;routing</FONT></SPAN></DIV>
<DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2>table 
size is forcing larger L2 networks to be as large as possible and 
no</FONT></SPAN></DIV>
<DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff size=2>other 
choices exist.</FONT></SPAN></DIV>
<DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff 
size=2>--</FONT></SPAN></DIV>
<DIV><SPAN class=186231521-18102005><FONT face=Arial color=#0000ff 
size=2>Eric</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [email-masked] 
  [mailto:[email-masked]]<B>On Behalf Of </B>Alia 
  Atlas<BR><B>Sent:</B> Monday, October 17, 2005 3:02 PM<BR><B>To:</B> 
  Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] MAN scale 
  and future uses of Rbridge<BR><BR></FONT></DIV>On 10/17/05, <B 
  class=gmail_sendername>Peter Ashwood-Smith</B> &lt;<A 
  href="mailto:[email-masked]">[email-masked]</A>&gt; wrote:
  <DIV><SPAN class=gmail_quote></SPAN>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
    <DIV><SPAN><FONT face=Arial color=#0000ff size=2>I think the main impediment 
    to very large scale is the large flat address space and its rate of change. 
    Not the number or Rbridge nodes and networks/links.&nbsp;While use of IS-IS 
    or OSPF areas can help when addressing is hierarchical, they are not going 
    to help much when you cannot aggregate the addresses into specific 
    areas.</FONT></SPAN></DIV></BLOCKQUOTE>
  <DIV><BR>There are environments where the rate of change could be reasonably 
  bounded, so that brings it back to the flat address space...<BR></DIV><BR>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
    <DIV><SPAN><FONT face=Arial color=#0000ff size=2>Then again I don't think 
    that Rbridge needs to scale that large to be enormously useful. If it pushes 
    the attainable size out a bit, gives better routes, is more stable&nbsp;and 
    allows future innovations based on the topology it is going to be very 
    useful. After that .. well its routers all the way down 
    ;)</FONT></SPAN></DIV></BLOCKQUOTE>
  <DIV><BR>What do you think is large enough?&nbsp; (I remember the discussion 
  earlier, but not specific numbers.)<BR><BR>Alia <BR></DIV><BR>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><SPAN 
    class=sg>
    <DIV><SPAN><FONT face=Arial color=#0000ff size=2>Peter</FONT> 
    </SPAN></DIV></SPAN>
    <DIV><SPAN class=e id=q_106ffefd56937552_2>
    <BLOCKQUOTE 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(0,0,255) 2px solid; MARGIN-RIGHT: 0px">
      <DIV></DIV>
      <DIV lang=en-us dir=ltr align=left><FONT face=Tahoma size=2>-----Original 
      Message-----<BR><B>From:</B> <A 
      onclick="return top.js.OpenExtLink(window,event,this)" 
      href="mailto:[email-masked]" 
      target=_blank>[email-masked]</A> [mailto:<A 
      onclick="return top.js.OpenExtLink(window,event,this)" 
      href="mailto:[email-masked]" target=_blank> 
      [email-masked]</A>] <B>On Behalf Of </B>Alia 
      Atlas<BR><B>Sent:</B> Monday, October 17, 2005 2:37 PM<BR><B>To:</B> 
      Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] MAN 
      scale and future uses of Rbridge<BR><BR></FONT></DIV><BR><BR>
      <DIV><SPAN class=gmail_quote>On 10/17/05, <B class=gmail_sendername>Sofia, 
      Rute</B> &lt;<A onclick="return top.js.OpenExtLink(window,event,this)" 
      href="mailto:[email-masked]" 
      target=_blank>[email-masked]</A>&gt; wrote:</SPAN> 
      <BLOCKQUOTE class=gmail_quote 
      style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Considering 
        Rbridges application from a MAN scope, other scalability<BR>issues 
        relate to:<BR>-&nbsp;&nbsp;storage cost (the price of flat addressing 
        and of having every<BR>Rbridge learning both requested and unrequested 
        MAC destination <BR>addresses) may be decreased, but is something that 
        has not be considered<BR>up until now, given that the scope is limited 
        to a campus...</BLOCKQUOTE>
      <DIV><BR>&nbsp;What number of MAC addresses is the target for the rbridge 
      campus?&nbsp;&nbsp; Do you<BR>think the constraints are on the memory or 
      on the notifications required due to changes? <BR><BR></DIV>
      <BLOCKQUOTE class=gmail_quote 
      style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">- 
        scalability related to the IS-IS tuning. On this point, (I am 
        not<BR>completely sure about the price but...), there is a price to pay 
        to tune <BR>IS-IS in order to achieve convergence in the order of 
        hundreds of<BR>seconds. This is another issue to be checked.</BLOCKQUOTE>
      <DIV><BR>Is there a reason that different areas couldn't be used in the 
      IS-IS instance for rbridges?<BR>Do you think this would be adequate?&nbsp; 
      Are the topological restrictions (i.e. hub and spoke)<BR>acceptable?&nbsp; 
      Could we work around that?<BR></DIV><BR>
      <BLOCKQUOTE class=gmail_quote 
      style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Summing 
        up, these are issues to be considered *if* Rbridges is to be<BR>extended 
        to something larger than a campus. But going back to the <BR>participate 
        vs. non-participate in the ST issue, then the scope is<BR>something that 
        may help in deciding this issue. As I said, I do not see<BR>that 
        Rbridges need to intervene *if* the scope is limited to a 
        campus.<BR>Why? Because as stated in Radia's paper, Rbridges can simply 
        terminate<BR>STs, which makes all the sense given that a Rbridge is a 
        hybrid router.<BR>But this scenario does not seem to make the same 
        sense, if a MAN scope<BR>is considered...<BR></BLOCKQUOTE></DIV><BR>While 
      improving the scalability may not be immediately in scope, I think it 
      is<BR>worthwhile to consider where the restrictions are coming 
      from.<BR><BR>Alia<BR></BLOCKQUOTE></SPAN></DIV><BR>_______________________________________________<BR>rbridge 
    mailing list<BR><A onclick="return top.js.OpenExtLink(window,event,this)" 
    href="mailto:[email-masked]">[email-masked]</A><BR><A 
    onclick="return top.js.OpenExtLink(window,event,this)" 
    href="http://www.postel.org/mailman/listinfo/rbridge" 
    target=_blank>http://www.postel.org/mailman/listinfo/rbridge</A><BR><BR><BR><BR 
    clear=all></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C5D429.0D39D04C--

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 18 Oct 2005 17:43:47 -0300
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4135

Joe,

	Assuming that discovery of another RBridge on a link
means that the link is internal, then any link that connects
two RBridges is internal.  That in turn forces the formation
of a single campus - unless another behavior is configured.

	Conceded.

	However, we do not have to worry about an environment
in which mythical devices that also block STP exist.  That's
because we never could avoid those environments and therefore
always had to allow for them.

	Also, we do not have to worry about a loop external to
the RBridges.  The existence of such a loop indicates either
that there are two ports of the same RBridge on a bridged 
network segment (which the RBridge could handle itself), or 
that the loop is not external (because more than one RBridge 
is on the same bridged network segment).

	If we consider how an RBridge looks to the existing L2
network, if it does block STP, what we find is that the rest
of the network will see each distinct port of an Rbridge as 
a separate Hub with a possibly large number of MAC addresses
attached to it.  It's important to understand this, because
it will have serious effects on bridge stability, both for
STP and bridge learning, if we do not handle this correctly 
in specifying RBridge behavior.

	One simple approach might be to have the whole RBridge
campus behave exactly as a bridge would behave - including 
STP, port blocking, etc.  But that is neither a necessity, 
nor necessarily a good idea.  And, it may not be the simplest 
approach either.

	I think this is the perspective from which many are
currently arguing.  There are at least a couple of reasons
why this perspective makes sense:

1) behaving exactly like a bridge is exactly what we hope
   to get away from, and
2) getting an RBridge campus to behave as one large bridge
   is not itself a simple goal

	The simplest approach - to A) improve on the behavior
of bridges and B) avoid trying to look like a single large
bridge - is to simply block STP.

	As far as what happens if some other device(s) also
block STP, we have to expect that a network having those
devices is expected to work - because otherwise we cannot
improve the situation.  

	If it works, then RBridges will not make the situation 
worse.

	If these - possibly mythical - devices are capable of
creating a loop for frame transport, then the RBridges are
better off not relying on STP as a mechanism to detect this.
If such a loop exists, then it should be easily detected by
sending some form of limited broadcast message.  If it blocks
STP, then what good would it do to participate in STP?  If it
doesn't forward broadcast messages, then what's the problem?

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Monday, October 17, 2005 10:22 AM
--> To: [email-masked]; Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Time to summarize "forward or block" 
--> BPDU thread
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
-->

Earlier you wrote:

Saikat Ray wrote:
> AFAICT, this all works when there is at most one rbridge campus in an L2.
> 
> [Saikat] I think that the assumption (definition) is that if two RBridges
> are connected directly (i.e. no IP router in between), then they are parts
> of a single campus, thus must talk to each other. If that is true, then
how
> would you have more than one campuses that are not separated by an IP
> router?

You won't - the rbridge campuses will merge.

But we're the IETF, and we're making 'rbridges', which will BLOCK.

Let's say the IEEE decides to allow another group to make 'sbridges',
which also decide to BLOCK.

Now you can have an rbridge and an sbridge in the same L2 (how do you
know you don't?). They form an undetectable, uncorrectable loop.

--

I.e. - this all works only if everyone plays by OUR rules. Since we're
NOT the IEEE, how is it that we can decide to create a protocol that
relies on us being the ONLY exception?

Joe 

Date: Tue, 18 Oct 2005 22:24:18 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Optimizing Performance Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1598

One way, although somewhat restrictive, to achieve optimality in paths 
and high performance, is to restrict the Rbridges to connect between 
themselves, forming the core of the campus network, sbridges not allowed 
inside the core, only outside. In this way, all paths in the core go 
throug per ingress bridge tree and are optimal. Besides this, the paths 
through the sbridges spanning tree  to the ingress and egress Rbridge 
are also optimal.
Guillermo

Radia Perlman wrote:

>Right. I wasn't saying something other than that.
>What I'm saying is that if there's just a single shared tree, and 
>multiple transmitters,
>then it's not clear what the optimal tree would be...probably one would 
>have to know the
>volume of traffic between each pair of speakers.
>
>So at any rate, I don't think we should be trying for "optimal", even if 
>we knew what we were
>optimizing, since it would be really expensive to try to get the extra 
>tiny bit of possible
>performance by going from simple, easy, and pretty good, to optimal.
>
>But per-ingress trees is pretty close to optimal anyway. It will be a 
>tree of shortest paths from
>the sender to each receiver.
>
>Radia
>
>
>
>Ghanwani, Anoop wrote:
>
>  
>
>>This is not necessarily true.  Depending on which ports
>>block, traffic sourced from some nodes will have to 
>>travel more hops to get to all of the links.  The tree 
>>is optimal only for the root node.
>>
>>Anoop
>>
>> 
>>
>>    
>>
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 18 Oct 2005 16:16:01 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8340

> Peter,
> 
> 	Privately I agree strongly with your first statement and
> would extend it to include understanding of STP, bridge 
> learning and a slew of other things.  I have this 
> understanding from my 
> days working at Cabletron, and I suspect that a few of the 
> other people in this discussion do as well.  But I don't 
> think it is ever going to be true generally in this venue.  
> And this was why 
> I questioned the wisdom of trying to do this in the IETF - and 
> especially trying to do it in the IETF in the Internet Area.

  Unfortunately if you do it somewhere else you get the reverse
problem. Expertise at L2 but not as much understanding of L3 
protocols. 

> 	I also want to thank you for fielding Joe's questions in
> the last few days.  I have been unable to get connected to my 
> company network (and it's Exchange server) for the last couple days...

  Well let's hope I did not add to the confusion.

  Peter

> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]]On
> --> Behalf Of Peter Ashwood-Smith
> --> Sent: Sunday, October 16, 2005 9:10 PM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] Time to summarize "forward or block" 
> --> BPDU thread
> --> 
> --> 
> --> 
> -->   This lack of understanding of the DRs seems to be the
> --> cause of a lot
> --> of this debate. 
> --> 
> -->   Also, the 'problems' that people are attributing to
> --> blocking and not
> --> processing BPDUs [BLOCK] are also 'problems' when no STP 
> is running.
> --> In the case where two broadcast domains are rbridged 
> --> together in such a
> --> way
> --> as to create a loop, the DR mechanism will detect and 
> --> prevent it, so it
> --> works
> --> even when BPDUs are not present. 
> --> 
> -->   So far the only reason I can think of to allow BPDUs to
> --> passively pass
> --> is for migration purposes. To keep the tree from changing 
> --> 'just yet' but
> --> it certainly won't speed anything up, fix anything or do 
> --> more to prevent
> --> loops than blocking will.
> --> 
> -->   Peter Ashwood-Smith
> --> 
> --> > -----Original Message-----
> --> > From: [email-masked]
> --> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> --> > Sent: Sunday, October 16, 2005 8:46 PM
> --> > To: [email-masked]; Developing a hybrid router/bridge.
> --> > Subject: Re: [rbridge] Time to summarize "forward or block" 
> --> > BPDU thread
> --> > 
> --> > 
> --> > The scenario you mention is where there is temporarily
> --> two Designated
> --> > RBridges (DRs), because
> --> > two links were merged.
> --> > 
> --> > The DRs will notice this when they start seeing each other's
> --> > IS-IS Hello 
> --> > messages, and that
> --> > will break the loop.
> --> > 
> --> > I don't think this case is that much of a problem, and
> --> > certainly would 
> --> > not be helped by trying to run a big
> --> > global spanning tree. The big global spanning tree would 
> --> > converge much 
> --> > slower than the RBridge
> --> > DR election protocol would. So attempting to avoid a 
> --> > temporary loop when 
> --> > two bridged domains
> --> > are merged, by running a big global instance
> --> > of the spanning tree algorithm, will not solve the 
> --> problem, and will
> --> > actually
> --> > make things worse.
> --> > 
> --> > Radia
> --> > 
> --> > 
> --> > 
> --> > 
> --> > Saikat Ray wrote:
> --> > 
> --> > >It is probably a standard scenario in IS-IS protocol (and
> --> > consequently
> --> > >a standard solution is known), but I was thinking that if
> --> > the RBridges
> --> > >disregards BPDUs entirely, then in some situations loops may
> --> > form for
> --> > >some period. For example, suppose $T_1$ and $T_2$ are
> --> disjoint trees
> --> > >formed entirely by legacy elements. $R_1$ and $R_2$ are the
> --> > designated
> --> > >RBridges for the "links" $T_1$ and $T_2$, respectively. At
> --> > this point,
> --> > >there is no loop in the system. Now suppose that a physical
> --> > link (or a
> --> > >legacy bridge) is added that connects a legacy bridge of
> --> $T_1$ to a
> --> > >legacy bridge of $T_2$. This addition will trigger a new
> --> > Spanning tree
> --> > >computation, which will result into a single spanning tree
> --> > that spans
> --> > >the nodes of $T_1$ and $T_2$. At this point, effectively the
> --> > RBridges
> --> > >$R_1$ and $R_2$ are connected by a single "link" and until
> --> > one of the
> --> > >RBridge gets "de-designated", there would exist a loop. Two
> --> > questions
> --> > >arise in my mind: (i) how fast would that "de-designation"
> --> > process be?
> --> > >And (ii) would it be useful (i.e. would it accelerate the
> --> > convergence)
> --> > >if RBridges "listen" to the BPDUs?
> --> > >
> --> > >-----Original Message-----
> --> > >From: [email-masked]
> --> > [mailto:[email-masked]] On
> --> > >Behalf Of Radia Perlman
> --> > >Sent: Sunday, October 16, 2005 7:12 PM
> --> > >To: Developing a hybrid router/bridge.
> --> > >Subject: [rbridge] Time to summarize "forward or block"
> --> BPDU thread
> --> > >
> --> > >It looks like this thread was discussed with two
> --> different subject
> --> > >lines, and it's also
> --> > >gone on long enough it's time for someone to summarize it.
> --> > >
> --> > >I strongly believe that things will be more stable if
> --> RBridges do NOT
> --> > >forward BPDUs...that
> --> > >we decouple the protocols.
> --> > >
> --> > >That TRILL is kind of like a layer between bridging 
> and routing.
> --> > >
> --> > >If RBridges do not forward BPDUs, then whether or not
> --> the TRILL link
> --> > >state protocol is
> --> > >converged, it won't affect the little spanning tree inside a
> --> > particular
> --> > >bridged segment.
> --> > >
> --> > >That way, the little spanning trees will converge as quickly as
> --> > >possible
> --> > >(because it's small),
> --> > >and cannot possibly be disrupted by RBridges wormholing BPDUs.
> --> > >
> --> > >I do not understand the reasons why people want to
> --> forward BPDUs. I
> --> > >think the arguments (which
> --> > >I may not be presenting fairly because I don't
> --> understand them) are:
> --> > >a) you'll get a more optimal combined spanning tree on which
> --> > >unknown/broadcast frames will
> --> > >be sent if it is one global spanning tree, rather than little 
> --> > >independent spanning trees hooked together
> --> > >by the independently computed spanning tree calculated 
> by IS-IS.
> --> > >b) forwarding BPDUs, and having a global spanning tree, will 
> --> > prevent loops.
> --> > >
> --> > >I strongly disagree with both those arguments. For a)
> --> What do people
> --> > >think is more optimal about a tree
> --> > >computed that way vs having independent trees inside
> --> each bridged
> --> > >island? And besides, there isn't
> --> > >a single spanning tree...it's a spanning tree per
> --> ingress RBridge.
> --> > >For b) no...I believe that having both the RBridge
> --> algorithm and the
> --> > >bridge algorithm feeding into
> --> > >each other will create much slower convergence.
> --> > >
> --> > >If I haven't summarized correctly, then someone else can try
> --> > to capture
> --> > >the arguments, but I do
> --> > >think we should merge discussion under one subject line,
> --> and restart
> --> > >with a summary.
> --> > >
> --> > >Radia
> --> > >
> --> > >_______________________________________________
> --> > >rbridge mailing list
> --> > >[email-masked] 
> --> > >
> --> > 
> --> > >rbridge mailing list
> --> > >[email-masked] 
> --> > >  
> --> 
> --> > 
> --> > _______________________________________________
> --> > rbridge mailing list
> --> > [email-masked] 
> --> > 
> --> > 
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
> --> 
> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
> 
> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 18 Oct 2005 17:04:31 -0300
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1712

Joe,

	I am deeply concerned that there seems to be some differences
in opinion between those that are working on the draft(s?) and a lot
of the rest of the working group.

	More-over, I am not sure that the differences are entirely in
terminology.  But I guess we'll just have to wait and see...

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Monday, October 17, 2005 10:27 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Time to summarize "forward or block" 
--> BPDU thread
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier you wrote (and by the way I wish I didn't have to do it 
this way, but your E-Mail is broken :-):

Harald Tveit Alvestrand wrote:
> 
> 
> --On 17. oktober 2005 05:17 -0700 Joe Touch <[email-masked]> wrote:
> 
>> WHEN (note the use of 'when', not 'if', since there's *nothing* that can
>> be done to enforce this) this isn't the case, the following problems
>> arise:
>>
>>     a) there is no way to detect the error
>>
>>     b) loops *will* occur
> 
> 
> You know, I really can't tell whether this is true or not without
> looking at the protocol specification that says how the RBridges detect
> each other.
> 
> Should this discussion wait for the drafts to come out?

As someone trying to write the drafts, I'm trying to understand the
terminology that will determine this.

I have a MUCH better idea of how to explain things now - whether I agree
with them at all levels or not, so this discussion IS helping, FWIW.

Joe

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 18 Oct 2005 16:50:57 -0300
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7595

Peter,

	Privately I agree strongly with your first statement and
would extend it to include understanding of STP, bridge learning
and a slew of other things.  I have this understanding from my 
days working at Cabletron, and I suspect that a few of the other
people in this discussion do as well.  But I don't think it is
ever going to be true generally in this venue.  And this was why 
I questioned the wisdom of trying to do this in the IETF - and 
especially trying to do it in the IETF in the Internet Area.

	I also want to thank you for fielding Joe's questions in
the last few days.  I have been unable to get connected to my
company network (and it's Exchange server) for the last couple
days...

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Peter Ashwood-Smith
--> Sent: Sunday, October 16, 2005 9:10 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Time to summarize "forward or block" 
--> BPDU thread
--> 
--> 
--> 
-->   This lack of understanding of the DRs seems to be the 
--> cause of a lot
--> of this debate. 
--> 
-->   Also, the 'problems' that people are attributing to 
--> blocking and not
--> processing BPDUs [BLOCK] are also 'problems' when no STP is running.
--> In the case where two broadcast domains are rbridged 
--> together in such a
--> way
--> as to create a loop, the DR mechanism will detect and 
--> prevent it, so it
--> works
--> even when BPDUs are not present. 
--> 
-->   So far the only reason I can think of to allow BPDUs to 
--> passively pass
--> is for migration purposes. To keep the tree from changing 
--> 'just yet' but
--> it certainly won't speed anything up, fix anything or do 
--> more to prevent
--> loops than blocking will.
--> 
-->   Peter Ashwood-Smith
--> 
--> > -----Original Message-----
--> > From: [email-masked] 
--> > [mailto:[email-masked]] On Behalf Of Radia Perlman
--> > Sent: Sunday, October 16, 2005 8:46 PM
--> > To: [email-masked]; Developing a hybrid router/bridge.
--> > Subject: Re: [rbridge] Time to summarize "forward or block" 
--> > BPDU thread
--> > 
--> > 
--> > The scenario you mention is where there is temporarily 
--> two Designated 
--> > RBridges (DRs), because
--> > two links were merged.
--> > 
--> > The DRs will notice this when they start seeing each other's 
--> > IS-IS Hello 
--> > messages, and that
--> > will break the loop.
--> > 
--> > I don't think this case is that much of a problem, and 
--> > certainly would 
--> > not be helped by trying to run a big
--> > global spanning tree. The big global spanning tree would 
--> > converge much 
--> > slower than the RBridge
--> > DR election protocol would. So attempting to avoid a 
--> > temporary loop when 
--> > two bridged domains
--> > are merged, by running a big global instance
--> > of the spanning tree algorithm, will not solve the 
--> problem, and will 
--> > actually
--> > make things worse.
--> > 
--> > Radia
--> > 
--> > 
--> > 
--> > 
--> > Saikat Ray wrote:
--> > 
--> > >It is probably a standard scenario in IS-IS protocol (and 
--> > consequently 
--> > >a standard solution is known), but I was thinking that if 
--> > the RBridges 
--> > >disregards BPDUs entirely, then in some situations loops may 
--> > form for 
--> > >some period. For example, suppose $T_1$ and $T_2$ are 
--> disjoint trees 
--> > >formed entirely by legacy elements. $R_1$ and $R_2$ are the 
--> > designated 
--> > >RBridges for the "links" $T_1$ and $T_2$, respectively. At 
--> > this point, 
--> > >there is no loop in the system. Now suppose that a physical 
--> > link (or a 
--> > >legacy bridge) is added that connects a legacy bridge of 
--> $T_1$ to a 
--> > >legacy bridge of $T_2$. This addition will trigger a new 
--> > Spanning tree 
--> > >computation, which will result into a single spanning tree 
--> > that spans 
--> > >the nodes of $T_1$ and $T_2$. At this point, effectively the 
--> > RBridges 
--> > >$R_1$ and $R_2$ are connected by a single "link" and until 
--> > one of the 
--> > >RBridge gets "de-designated", there would exist a loop. Two 
--> > questions 
--> > >arise in my mind: (i) how fast would that "de-designation" 
--> > process be? 
--> > >And (ii) would it be useful (i.e. would it accelerate the 
--> > convergence) 
--> > >if RBridges "listen" to the BPDUs?
--> > >
--> > >-----Original Message-----
--> > >From: [email-masked] 
--> > [mailto:[email-masked]] On 
--> > >Behalf Of Radia Perlman
--> > >Sent: Sunday, October 16, 2005 7:12 PM
--> > >To: Developing a hybrid router/bridge.
--> > >Subject: [rbridge] Time to summarize "forward or block" 
--> BPDU thread
--> > >
--> > >It looks like this thread was discussed with two 
--> different subject
--> > >lines, and it's also
--> > >gone on long enough it's time for someone to summarize it.
--> > >
--> > >I strongly believe that things will be more stable if 
--> RBridges do NOT
--> > >forward BPDUs...that
--> > >we decouple the protocols.
--> > >
--> > >That TRILL is kind of like a layer between bridging and routing.
--> > >
--> > >If RBridges do not forward BPDUs, then whether or not 
--> the TRILL link
--> > >state protocol is
--> > >converged, it won't affect the little spanning tree inside a 
--> > particular 
--> > >bridged segment.
--> > >
--> > >That way, the little spanning trees will converge as quickly as 
--> > >possible
--> > >(because it's small),
--> > >and cannot possibly be disrupted by RBridges wormholing BPDUs.
--> > >
--> > >I do not understand the reasons why people want to 
--> forward BPDUs. I
--> > >think the arguments (which
--> > >I may not be presenting fairly because I don't 
--> understand them) are:
--> > >a) you'll get a more optimal combined spanning tree on which 
--> > >unknown/broadcast frames will
--> > >be sent if it is one global spanning tree, rather than little 
--> > >independent spanning trees hooked together
--> > >by the independently computed spanning tree calculated by IS-IS.
--> > >b) forwarding BPDUs, and having a global spanning tree, will 
--> > prevent loops.
--> > >
--> > >I strongly disagree with both those arguments. For a) 
--> What do people
--> > >think is more optimal about a tree
--> > >computed that way vs having independent trees inside 
--> each bridged 
--> > >island? And besides, there isn't
--> > >a single spanning tree...it's a spanning tree per 
--> ingress RBridge.
--> > >For b) no...I believe that having both the RBridge 
--> algorithm and the 
--> > >bridge algorithm feeding into
--> > >each other will create much slower convergence.
--> > >
--> > >If I haven't summarized correctly, then someone else can try 
--> > to capture
--> > >the arguments, but I do
--> > >think we should merge discussion under one subject line, 
--> and restart 
--> > >with a summary.
--> > >
--> > >Radia
--> > >
--> > >_______________________________________________
--> > >rbridge mailing list
--> > >[email-masked] http://www.postel.org/mailman/listinfo/rbridge
--> > >
--> > >_______________________________________________
--> > >rbridge mailing list
--> > >[email-masked] http://www.postel.org/mailman/listinfo/rbridge
--> > >  
--> > >
--> > 
--> > _______________________________________________
--> > rbridge mailing list
--> > [email-masked] http://www.postel.org/mailman/listinfo/rbridge
--> > 
--> > 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 18 Oct 2005 16:44:40 -0300
Subject: Re: [rbridge] seeking input on abstract for problem and applicabi	 lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4629

Joe,

	There are two ways to look at what we are doing.  One is to
start with the conclusion that we don't want an RBridge to do any
thing different than a bridge.  The other is that we do want the
RBridge to do something different than a bridge but we want it to
be compatible in a "drop-in" mode with bridges.

	I doubt that the former is the correct perspective, as the
immediate question that comes to my mind (at least) is why are we
doing anything at all then?

	For the latter, we have to work from a better understanding
than "[STP] is there for a reason."  STP is there to establish a
_single_ path for full network connectivity among devices that do
not have any other protection against forwarding loops.

	If we plan to design RBridges with the specific intent of
A) having more than one path for full connectivity and B) provide 
appropriate additional protection against forwarding loops, then 
we have to analyze how this impacts STP and vice versa.  We do not
have to blindly accept STP as the only answer - nor should we, at
least among RBridges, as the intent of STP works directly against
the intention of developing RBridges.

	The answers given already show that it is straight-forward
for a RBridge to determine it has a loop through the bridges in
the network - via, for example, a hello protocol.  That takes care
of the case where a connected set of bridges, hubs and lower-level
layer two devices are all that is between one port and another of
the same RBridge.  The case where the path between two ports of an
RBridge also includes another (one or more) RBridge(s), only makes
this slightly harder.

	In order to solve the slightly harder case, it is sufficient
- for example - to simply say that the only RBridge that does not
forward "Hello" message is the one that originated it.  What this
would mean is that all of the RBridges have to forward some type 
of "Hello" message unless they originated it (meaining - obviously
- that we need to come up with an essentially fool proof way to 
allow them to determine which messages they originated), rather 
than simply receiving and consuming it.

	It may be the case that there is more than one type of 
"hello" message in the "hello protocol" - loop detection hello
messages and peer discovery hello messages.  I don't know that
it will be necessary to make this distinction, but it will be
simpler.  There may be other approaches that work just as well, 
but - as I said earlier - it is sufficient to show that at least 
one solution exists.

	Note that this approach relies on exactly the same thing
as you're concerned about - the fact that broadcast messages
will be broadcast throughout a broadcast domain, irrespective
of what equipment is used and what cheats each equipment uses.

	If that is not true, then the network is already broken
and we're not making it worse.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Sunday, October 16, 2005 3:33 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstract for problem and
--> applicabi lity statement
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier, you wrote:

Harald Tveit Alvestrand wrote:
> 
> --On s?ndag, oktober 16, 2005 09:21:57 -0700 Joe Touch <[email-masked]> 
> wrote:
> 
> 
>>>What we should be thinking of (to my mind) is "how do we discover that
>>>we're up the creek" - for this particular disaster, sending out a
>>>broadcast packet and watching it come back should be quite sufficient
>>>for the "detect" part....
>>
>>What if you send a packet and it creates a broadcast storm? Sure, you
>>know you're up the creek, but how do you paddle back?
> 
> if I have an one-packet answer to "how to take down a network", that 
> network is certainly in trouble without me..... but others have certainly 
> suggested forms of probing (hello packets?) that might be more gentle.

My concern is that every reason for allowing BLOCK for rbridges is a
reason to allow them for bridges as well.

SPT is there for a reason - to avoid the possibility of loops, and thus
such one-packet problems (deliberate or otherwise). I don't understand
why that's the required default for bridges (AFACT - regardless of
vendor offerings) but can be relaxed here.

> I'd very much like to design a network that is stable in the presence of a

> person with a laptop, an ordinary bridge port and no conscience....

Agreed.

Joe

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 18 Oct 2005 16:02:26 -0300
Subject: Re: [rbridge] seeking input on abstract for problem and applicabi	 lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1051

Joe,

	Typically, a broadcast storm that is a "real problem" is one
in which the broadcast message goes around and around.

	As we are positing that a "hello" message seen on a different
interface than the one it was sent on is an indication of a loop, 
we are also assuming (I hope) that this is the only broadcast that
should be handled by RBridges until loop-free forwarding has been
determined.  It would be a fairly lame RBridge that 1) saw a "hello" 
message that it originated and reforwarded it irrespective of what 
interface it receives it on.

--
Eric 

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Sunday, October 16, 2005 12:22 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstract for problem and
--> applicabi lity statement
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Tue, 18 Oct 2005 14:51:50 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3657

> 
> Hopefully nobody will interpret "out of ideas" as "giving in and 
> accepting that we have
> to have a single huge merged spanning tree because we've been 
> convinced 
> that BLOCK
> won't work".

  Lets hope not, clearly I meant "out of ideas" as to how to convince
folks that block really does work. At least not without a white board
and colored markers...

> I'm assuming Peter is saying the same thing I am. But without 
> speaking 
> for him, 

  Close enough ... yes. However I do feel it is worth enumerating the
different
approaches (even if we strongly disagree with them) so that they have
names and there is a place to attach the conclusions regarding their
desirability/correctness or lack thereof etc. Otherwise 3 months from
now we'll get the same set of questions. If they are already answered
/debated it saves time down the road.

  Peter

> let me say
> a) RBridges have to block. That's a nice simple clean thing 
> to do. It works
> b) I don't understand why people think there is a problem, 
> and I don't 
> think they've
> stated what they are worried about clearly enough, at least for me to 
> understand it
> c) It's really hard to argue when I don't understand what the 
> issue is.
> d) forwarding BPDUs is a really really bad, scary idea, and 
> will have no 
> advantages.
> 
> I'm guessing the anti-BLOCK folk are confused about where a packet 
> enters a bridged island, and where it
> leaves the bridged island. Perhaps there's no way to explain it in 
> email, and perhaps it could be
> all cleared up with a little off-list telephone conversation. 
> If anyone 
> wants to talk to me by phone, let me know,
> since hopefully it will clear things up and we can get on to other 
> issues, if there are any.
> 
> But I'll try to explain it yet another way.
> 
> Within the bridged island there is just a single tree. 
> Traffic can enter 
> that tree anywhere, and leave it
> anywhere. The only job of bridges within that island is to make that 
> happen....to accept traffic anywhere,
> and let it leave anywhere. Just as if the link were a token 
> ring, or token bus. The magic inside the link is irrelevant 
> to anything working on top of the link. Just so long as the 
> link creates 
> a fully connected, broadcast domain.
> 
> So the bridged island can be thought of, to RBridges, as a single 
> physical link.
> 
> Now try to imagine RBridges in a world without bridges, since the 
> bridges are inside the links,
> and successfully doing their job of creating a fully 
> connected broadcast 
> domain within the
> bridged island. As long as BPDUs are blocked, and the island 
> really is 
> isolated from the rest
> of the world except for devices that act as stations on that island 
> (like RBridges or routers or endnodes),
> any of the following are equivalent models of the link: a 
> single wire, a 
> bridged Ethernet, a token ring,
> a bridged token ring, a token bus, ....
> 
> If there's a problem with providing service on top of a link 
> which is a 
> fully
> connected broadcast domain, then IP routers have the same problem.
> 
> Radia
> 
> 
> 
> 
> 
> Peter Ashwood-Smith wrote:
> 
> >
> >
> >  Hopefully some of this or the previous explanation is enough to
> >convince folks that BLOCK does indeed work. .. if not ... well I'm 
> >out of ideas too.
> >
> >  Peter
> >
> >
> >
> >  
> >
> >[email-masked] http://www.postel.org/mailman/listinfo/rbridge
> >  
> >
> 
> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
> 
> 

Date: Tue, 18 Oct 2005 11:32:47 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2731

Hopefully nobody will interpret "out of ideas" as "giving in and 
accepting that we have
to have a single huge merged spanning tree because we've been convinced 
that BLOCK
won't work".

I'm assuming Peter is saying the same thing I am. But without speaking 
for him, let me say
a) RBridges have to block. That's a nice simple clean thing to do. It works
b) I don't understand why people think there is a problem, and I don't 
think they've
stated what they are worried about clearly enough, at least for me to 
understand it
c) It's really hard to argue when I don't understand what the issue is.
d) forwarding BPDUs is a really really bad, scary idea, and will have no 
advantages.

I'm guessing the anti-BLOCK folk are confused about where a packet 
enters a bridged island, and where it
leaves the bridged island. Perhaps there's no way to explain it in 
email, and perhaps it could be
all cleared up with a little off-list telephone conversation. If anyone 
wants to talk to me by phone, let me know,
since hopefully it will clear things up and we can get on to other 
issues, if there are any.

But I'll try to explain it yet another way.

Within the bridged island there is just a single tree. Traffic can enter 
that tree anywhere, and leave it
anywhere. The only job of bridges within that island is to make that 
happen....to accept traffic anywhere,
and let it leave anywhere. Just as if the link were a token ring, or
token bus. The magic inside the link is irrelevant
to anything working on top of the link. Just so long as the link creates 
a fully connected, broadcast domain.

So the bridged island can be thought of, to RBridges, as a single 
physical link.

Now try to imagine RBridges in a world without bridges, since the 
bridges are inside the links,
and successfully doing their job of creating a fully connected broadcast 
domain within the
bridged island. As long as BPDUs are blocked, and the island really is 
isolated from the rest
of the world except for devices that act as stations on that island 
(like RBridges or routers or endnodes),
any of the following are equivalent models of the link: a single wire, a 
bridged Ethernet, a token ring,
a bridged token ring, a token bus, ....

If there's a problem with providing service on top of a link which is a 
fully
connected broadcast domain, then IP routers have the same problem.

Radia

Peter Ashwood-Smith wrote:

>
>
>  Hopefully some of this or the previous explanation is enough to 
>convince folks that BLOCK does indeed work. .. if not ... well I'm 
>out of ideas too.
>
>  Peter
>
>
>
>  
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 18 Oct 2005 11:29:07 -0700
From: "Ghanwani, Anoop" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 534

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Tuesday, October 18, 2005 11:17 AM
> Subject: Re: [rbridge] Time to summarize "forward or block" 
> BPDU thread
> 

[..]

> But per-ingress trees is pretty close to optimal anyway. It will be a 
> tree of shortest paths from the sender to each receiver.

This is exactly what IEEE 802.1 is trying to do with the project
on Shortest Path Bridging.

Anoop

Date: Tue, 18 Oct 2005 11:17:01 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 922

Right. I wasn't saying something other than that.
What I'm saying is that if there's just a single shared tree, and 
multiple transmitters,
then it's not clear what the optimal tree would be...probably one would 
have to know the
volume of traffic between each pair of speakers.

So at any rate, I don't think we should be trying for "optimal", even if 
we knew what we were
optimizing, since it would be really expensive to try to get the extra 
tiny bit of possible
performance by going from simple, easy, and pretty good, to optimal.

But per-ingress trees is pretty close to optimal anyway. It will be a 
tree of shortest paths from
the sender to each receiver.

Radia

Ghanwani, Anoop wrote:

>This is not necessarily true.  Depending on which ports
>block, traffic sourced from some nodes will have to 
>travel more hops to get to all of the links.  The tree 
>is optimal only for the root node.
>
>Anoop
>
>  
>

Content-class: urn:content-classes:message
Date: Tue, 18 Oct 2005 10:47:11 -0700
From: "Ghanwani, Anoop" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 610

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Tuesday, October 18, 2005 9:46 AM
> To: [email-masked]; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Time to summarize "forward or block" 
> BPDU thread
>
> If a broadcast goes to all links, then one spanning tree is 
> as good as another.

This is not necessarily true.  Depending on which ports
block, traffic sourced from some nodes will have to 
travel more hops to get to all of the links.  The tree 
is optimal only for the root node.

Anoop

From: "Saikat Ray" <[email-masked]>
To: "'Radia Perlman'" <[email-masked]>, "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 18 Oct 2005 13:38:30 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 463

But what is optimized by STP (and Dijkstra) is the cost from each node 
to the Root.
If the Root were the only sender (which of course it isn't), then one 
could consider the spanning tree "optimal"
in distribution time (though not in total cost of delivery, which would 
require a minimum
weight spanning tree).

[Saikat] So you are considering additive per-link static (i.e. independent
of the load on the link) cost, right? That is what I wanted to confirm.

Content-class: urn:content-classes:message
Date: Tue, 18 Oct 2005 13:14:11 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1454

> One nit, on terminology...
> 
> Just making sure that someone who has recently studied 
> "minimum spanning 
> trees"
> doesn't get confused by your explanation, Peter.
> You're not wrong, but the terminology "minimum spanning tree" usually 
> refers to something different
> than what you're talking about...
> something where the total cost of all the links in the tree 
> is minimum.

  Yes, sorry, you are too kind, its technically wrong without
a macro substitution of the term "minimum spanning tree". That's 
what I get for trying to think past midnight ;)

  What I was trying to explain to Joe was that if he simply adopted
the DR mechanism from Rbridge in bridges and did away with BPDUS then
no form of optimization of the tree is possible since knowledge about
what goes on further away is lost. In particular you could not produce
a shortest path first tree to a preferred root.

  This I believe is what he was alluding too in his example. In
particular
he was asserting that if the DR mechanism can work without looking
at BPDUS then why can't it work in a regular bridge without BPDUS. The
answer I believe to that question is that it could but you would lose
the 
ability to compute a shortest path first tree to a preferred root. You'd
just converge on some tree.

  Hopefully some of this or the previous explanation is enough to 
convince folks that BLOCK does indeed work. .. if not ... well I'm 
out of ideas too.

  Peter

Date: Tue, 18 Oct 2005 09:45:51 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2107

I don't think we should strive for "optimal", but rather "simple, 
robust, and pretty good".

But what is optimized by STP (and Dijkstra) is the cost from each node 
to the Root.
If the Root were the only sender (which of course it isn't), then one 
could consider the spanning tree "optimal"
in distribution time (though not in total cost of delivery, which would 
require a minimum
weight spanning tree).

With link state routing, we can get optimal pt-to-pt paths. It's only 
for multicast that which spanning
tree is chosen may matter.

If a broadcast goes to all links, then one spanning tree is as good as 
another.

In an earlier email I mentioned several reasons why per-ingress trees 
are worth the effort:

Imagine the actual topology being a big circle, 20 hops around. If it 
were a single spanning tree,
one of the links in the circle would be broken. If a packet originates 
from the left side of the
break, it has to go completely around the circle to get to someone on 
the right side of the break,
even though in the physical topology it's only a single hop.

So, for instance, if those two links were the only VLAN A links, then 
the broadcast domain of VLAN A
requires 20 hops to deliver each packet, rather than a single hop, if it 
were a per-ingress RBridge tree.

Basically, with a per-ingress tree, then each packet gets delivered to 
each link optimally.

In the case of VLAN broadcast domains (e.g., for ARPs within VLAN A), 
and for IP multicast (assuming
RBridges snoop on IGMP so they know which subset of links have 
receivers), per-ingress trees can
wind up much less expensive to deliver traffic.

Radia

Saikat Ray wrote:

>[Saikat] I think it is a good opportunity to clarify one thing since the
>concept of optimality rose. What cost-function are you considering
>optimizing? If you use additive per-link static cost, then for the broadcast
>case, under the assumption of symmetrical link costs, any given minimum
>weight spanning tree is optimum regardless of the source of the packet. Then
>why should there be multiple (per ingress) trees for broadcast?
>
>
>
>  
>

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 18 Oct 2005 12:06:34 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5283

And now for more explanation...there's really nothing optimal about the tree
computed by STP. Any single shared tree will be good for some S-D pairs,
and bad for others.

[Saikat] I think it is a good opportunity to clarify one thing since the
concept of optimality rose. What cost-function are you considering
optimizing? If you use additive per-link static cost, then for the broadcast
case, under the assumption of symmetrical link costs, any given minimum
weight spanning tree is optimum regardless of the source of the packet. Then
why should there be multiple (per ingress) trees for broadcast?

The tree created by hopping across bridged islands won't be any more or less
optimal than if there were a giant spanning tree across the entire campus,
where we went to some effort to ensure the combination of RBridges and
bridges computed the same tree as they would have if everyone were bridges.

Plus...RBridges aren't computing a single tree anyway...they are computing
per-ingress-RBridge trees.

As I've said before, we really want to terminate the bridged islands, and
then have RBridges just see each bridged island as a single link.

Radia

Peter Ashwood-Smith wrote:

>>Here's the counterexample:
>>
>>Have existing bridges BLOCK.
>>    
>>
>
>  Thats not really a counter example but let me try to explain 
>where you are getting confused below. 
> 
>  
>
>>Assume each bridge computes its own spanning tree internally 
>>(i.e., between its own ports on its own device), and sends 
>>coded 'hellos' that it it recognizes if they loop, i.e., all 
>>the thinks a campus would do.
>>    
>>
>
>  Because it would not be a MINIMUM spanning tree. However, yes, if you
>repeatedly connect a set of node disjoint trees together with a single 
>link, reducing the number of trees by one each time, the result is a 
>tree. This I think is what you are suggesting and yes, I believe 
>an algorithm like this does actually make a tree. The catch is that it
>is NOT a minimum spanning tree and you cannot easily select a root.
>STP produces a minimum spanning tree rooted where you want it so
>you get much more with the STP protocol than just the hello/detect/block
>idea. STP requires its BPDUs to flood through the network to elect
>the root and compute paths to it and rbridge requires link state to
>flood link information so it can compute the minium spanning tree.
>Both protocols need to know about ALL the possible paths in their 
>domains to minimize the resulting tree.
>The DR mechanism is only used to prevent a loop between these two
>domains but it does not by itself guarantee that the combination of
>the two trees is still minimum. Therefore, the DR mechanism if applied 
>by itself as you suggest does produce a tree but it is not minimum and
>you
>have no control over the root that is selected.
>
>  Rbridge of course only uses this DR mechanism at the interface between
>itself and some other domain (STP or manually configured), and so 
>you end up with a minimum spanning tree in STP and a minimum spanning
>tree in the rbridge
>domain but the combination of the two is not necessarily the best
>possible
>since neither minimization was done over the complete set of links/nodes
>available. This makes sense because if you take two minimum solutions 
>over disjoint sets you cannot simply add them together to produce a 
>global minimum solution. For example, I cannot take a shortest path from
>some node S to an intermediate E and a shortest path from E to D, add
>them together and
>get the shortest path from S to D because there may be a much better E!
> 
>  
>
>>Now if that works, let's do it for bridges and then we 
>>wouldn't have a spanning tree convergence problem at all, right?
>>    
>>
>
>  It produces a tree but not a minimum spanning tree with no control
>over
>the root. So its not quite the 'work' you had in mind and this in a nut
>shell is I believe your mistake.
> 
>  
>
>>If that does NOT work, then why does it work for rbridge 
>>campuses and not bridges?
>>    
>>
>
>  It does work its just that we want minimum spanning trees and
>to do that we need information about all the nodes we can reach.
>STP gets this by flooding BPDUSs and Rbridges by link state updates. 
>Take away the BPUDS and you can't get minimum. Rbridges can take
>the BPDU away [BLOCk] because it does its own minimum and combines the
>results with DR to produce a possibly non global minimum solution but
>that is the price you pay for neither side seeing all the data.
>
>  
>
>>My general test is "an rbridge campus needs to look like a 
>>bridge" or "look like a link". If it does, then I know I 
>>understand it. When it doesn't, it would be useful to 
>>understand whether this is really a 'new  animal' and exactly 
>>why it's newness is unique to rbridges (i.e., why it can't be 
>>applied as well to bridges).
>>    
>>
>
>  I think you need to think of this as a new animal as Radia suggested.
>
>  Hope this helps.
>
>  Peter
>
>
>
>  
>
>>Joe
>>
>>    
>>
>[email-masked]

[email-masked]

From: "Saikat Ray" <[email-masked]>
To: "'Joe Touch'" <[email-masked]>, "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 18 Oct 2005 11:57:34 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2567

Saikat Ray wrote:
> Now you can have an rbridge and an sbridge in the same L2 (how do you
> know you don't?). They form an undetectable, uncorrectable loop.
> 
> 
> [Saikat] I do not see how this happens. First I am assuming that if
> "sbridges" are connected by physical links, then they know how to avoid
> packet loops by some mechanism they choose to implement. Now, as far as
> "sbridges" are concerned, the network consisting of RBridges, STP-running
> bridges, physical links etc., is simply a "link". In other words, the
entire
> network (consisting of RBridges, STP-running bridges, physical links etc.)
> could be replaced by a physical link. Thus even in this case, there would
be
> no packet loop in the steady state.
> 
> Another way of looking at this argument is the following. Suppose you
remove
> all the RBridges from the network. sBridges and legacy bridges are left,
and
> the assumption is that in that case, at least, a loop-free network
results.
> Then when you add RBridges (in their original position), the rest of the
> network is simply one or more "link"s, and RBridges would ensure that
there
> would be no loops.

Except that the rbridges add a 'link' between themselves - that's the
extra 'link' that can cause the loop.

Joe

[Saikat] We discussed this possibility before (Radia and I exchanged a
couple of emails). When RBbridges add a "link" between themselves (actually
you need to consider only the scenario when "designated" RBridges add a
"link" between themselves), there will be a temporary loop. Then the
designated RBridges will start seeing each others' hello messages, and they
will know that there is a loop. In that case, all but one designated
RBridges (who are connected to themselves by a single "link") will
"de-designate" themselves. Thus in the steady state there would be no loop.

Thinking more about the problem of "Lateral compatibility"---i.e. when there
is a third protocol (the one your imaginary "sBridge" implements) that do
not know about RBridges and vice versa---I am quite convinced that *if* all
the protocols jointly converge to a steady state, there will be no loop in
the system. This basically follows from the fact that in the steady state,
each given protocol can view the rest of the network as one or more "links".
However, in the presence of 3 or more protocols, it is not clear to me
whether joint convergence to a steady state is guaranteed in all cases (I
posted a message regarding this before). I tend to believe that in
"ordinary" cases it should, but there may exist special cases...

Date: Tue, 18 Oct 2005 08:08:46 -0400
From: Stephen Suryaputra <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2638

Joe,

To me, Rbridge is changing the assumption that there is no router in
the L2 network. It fits well with the way L2 network view of routers,
they are nodes. From a directly connected L2 network, the Rbridge is
sourcing/sinking packets, and blocking (but accepting) broadcast. But
instead of terminating them (like nodes), Rbridge is tunneling them.

Another point why I think they are nodes, tunneling (i.e. the shim) is
using the unicast address of the ingress and egress Rbridges in the L2
header (no?).

Since the goal is to reduce the size of spanning tree protocol
network, the Rbridge chose not to tunnel BPDU. Tunneling is an option,
but that will make a cloud of Rbridges to be a virtual single bridge,
which IMHO can create more complex control for Rbridges. Tunnelling
BPDU however makes Rbridges look link links, very clean
architecturally.

So, now there are 4 devices in the L2 network: nodes, links, bridges
and Rbridges.

Cheers,

Stephen.

On 10/17/05, Joe Touch <[email-masked]> wrote:
>
>
> [email-masked] wrote:
> > It works perfectly well if RBridges block. It isolates the bridge islands.
> >
> > Routers also block bridge spanning tree, and to exactly the same
> > effect as if RBridges block BPDUs.
>
> This isn't the same at all; I keep hearing the analogy, but it fails
> under all tests:
>
>         first, there are NO routers on an L2 net
>
>         all sources/sinks are the same (called nodes AFAICT)
>         and hosts and routers are just nodes,
>         identical as far as L2 is concerned
>
>         nodes block all BPDUs (we agree), but
>         nodes also block broadcast (rbridges don't)
>
> Near as I can tell, L2 has exactly three devices currently:
>
>         nodes
>
>         links
>
>         bridges (participate in SPT, interpret BPDUs)
>
> Bridges don't 'block' BPDUs, but they don't forward them to all ports
> either.
>
> Now, an rbridge can be "like" a node, a link, or a bridge and still play
> in the existing L2 specs. If it isn't 'like' any of those, then we're
> changing the definition of 802, and I didn't think that was the goal here.
>
> rbridges - at least to nodes on the L2 - are NOT 'like' hosts, since
> they don't source or sink L2 traffic to existing nodes
>
> rbridges could be 'like' links if they are TRANSPARENT
>
> rbridges could be 'like' bridges if the PARTICIPATE
>
> What exactly are rbridges 'like' if they BLOCK?
>
> They can't be 'like' routers - there are no routers in L2.
>
> ??
>
> Joe
>
>
> [email-masked]

Content-class: urn:content-classes:message
Date: Tue, 18 Oct 2005 12:35:29 +0200
From: "Sofia, Rute" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] MAN scale and future uses of Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1370

Guillermo,

> 
> -Regarding scalability problem of high number of flat MAC 
> addresses in 
> the MAN,
>    There is no such problem,  provided each campus network 
> uses routers 
> to participate in the MAN. In this case the only MAC addresses to be 
> handled by the
> Rbridges are the MACs of the routers used to accesss the 
> MAN.(See Link 
> State Over MAC, Garc?a and Duato 2003   proposal for such an example)
> - Another aspect to analyze consider in the MAN environment is the 
> interoperability with provider bridges (.1ad .1ah) and their 
> encapsulations.
> Guillermo

There is no such problem, if you consider that the operators will configure things properly. In other words, if the proper traffic-engineering solutions apply.

In any case. We are not here (I believe) discussing such operator issues...the fact is that if Rbridges are to be applied within a campus then the simplest (but non-optimal) solution applies. However, if this is to be scaled to the MAN (and here I am considering the aggregation area) then there are other implications that must be considered from the mechanism perspective.

In other words, the flooding provided by IS-IS is a great idea and gives plenty of flexibility to develop new, better than ST ideas. If this is to be extended, my 2cents on this is that the issues mentioned before are worth checking.

Regards,
Rute

Date: Mon, 17 Oct 2005 23:18:48 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5861

One nit, on terminology...

Just making sure that someone who has recently studied "minimum spanning 
trees"
doesn't get confused by your explanation, Peter.
You're not wrong, but the terminology "minimum spanning tree" usually 
refers to something different
than what you're talking about...
something where the total cost of all the links in the tree is minimum.

STP (and Dijkstra) do not compute minimum spanning trees. For instance, 
if you
had a Root R, with 3 links coming off it, attached to R1, R2, and R3, 
respectively,
with the cost of all those links being 10, and a link between R1 and R2 
of cost 1,
then STP and Disjkstra would compute the tree consisting of R and its 
attached
links.

That tree would have a total weight (add the link costs) of 30.

The minimum spanning tree would instead connect R2 to R1, so the total
weight would be 21.

STP (and Disjkstra) instead compute a tree of shortest paths from the 
root. They wouldn't
attach R2 to R1 because then the path from root to R2 would be 11 rather 
than 10
if R2 was attached to the Root.

Anyway...just for future reference on the term "minimum spanning tree"...

******
And now for more explanation...there's really nothing optimal about the tree
computed by STP. Any single shared tree will be good for some S-D pairs,
and bad for others.

The tree created by hopping across bridged islands won't be any more or less
optimal than if there were a giant spanning tree across the entire campus,
where we went to some effort to ensure the combination of RBridges and
bridges computed the same tree as they would have if everyone were bridges.

Plus...RBridges aren't computing a single tree anyway...they are computing
per-ingress-RBridge trees.

As I've said before, we really want to terminate the bridged islands, and
then have RBridges just see each bridged island as a single link.

Radia

Peter Ashwood-Smith wrote:

>>Here's the counterexample:
>>
>>Have existing bridges BLOCK.
>>    
>>
>
>  Thats not really a counter example but let me try to explain 
>where you are getting confused below. 
> 
>  
>
>>Assume each bridge computes its own spanning tree internally 
>>(i.e., between its own ports on its own device), and sends 
>>coded 'hellos' that it it recognizes if they loop, i.e., all 
>>the thinks a campus would do.
>>    
>>
>
>  Because it would not be a MINIMUM spanning tree. However, yes, if you
>repeatedly connect a set of node disjoint trees together with a single 
>link, reducing the number of trees by one each time, the result is a 
>tree. This I think is what you are suggesting and yes, I believe 
>an algorithm like this does actually make a tree. The catch is that it
>is NOT a minimum spanning tree and you cannot easily select a root.
>STP produces a minimum spanning tree rooted where you want it so
>you get much more with the STP protocol than just the hello/detect/block
>idea. STP requires its BPDUs to flood through the network to elect
>the root and compute paths to it and rbridge requires link state to
>flood link information so it can compute the minium spanning tree.
>Both protocols need to know about ALL the possible paths in their 
>domains to minimize the resulting tree.
>The DR mechanism is only used to prevent a loop between these two
>domains but it does not by itself guarantee that the combination of
>the two trees is still minimum. Therefore, the DR mechanism if applied 
>by itself as you suggest does produce a tree but it is not minimum and
>you
>have no control over the root that is selected.
>
>  Rbridge of course only uses this DR mechanism at the interface between
>itself and some other domain (STP or manually configured), and so 
>you end up with a minimum spanning tree in STP and a minimum spanning
>tree in the rbridge
>domain but the combination of the two is not necessarily the best
>possible
>since neither minimization was done over the complete set of links/nodes
>available. This makes sense because if you take two minimum solutions 
>over disjoint sets you cannot simply add them together to produce a 
>global minimum solution. For example, I cannot take a shortest path from
>some node S to an intermediate E and a shortest path from E to D, add
>them together and
>get the shortest path from S to D because there may be a much better E!
> 
>  
>
>>Now if that works, let's do it for bridges and then we 
>>wouldn't have a spanning tree convergence problem at all, right?
>>    
>>
>
>  It produces a tree but not a minimum spanning tree with no control
>over
>the root. So its not quite the 'work' you had in mind and this in a nut
>shell is I believe your mistake.
> 
>  
>
>>If that does NOT work, then why does it work for rbridge 
>>campuses and not bridges?
>>    
>>
>
>  It does work its just that we want minimum spanning trees and
>to do that we need information about all the nodes we can reach.
>STP gets this by flooding BPDUSs and Rbridges by link state updates. 
>Take away the BPUDS and you can't get minimum. Rbridges can take
>the BPDU away [BLOCk] because it does its own minimum and combines the
>results with DR to produce a possibly non global minimum solution but
>that is the price you pay for neither side seeing all the data.
>
>  
>
>>My general test is "an rbridge campus needs to look like a 
>>bridge" or "look like a link". If it does, then I know I 
>>understand it. When it doesn't, it would be useful to 
>>understand whether this is really a 'new  animal' and exactly 
>>why it's newness is unique to rbridges (i.e., why it can't be 
>>applied as well to bridges).
>>    
>>
>
>  I think you need to think of this as a new animal as Radia suggested.
>
>  Hope this helps.
>
>  Peter
>
>
>
>  
>
>>Joe
>>
>>    
>>
>[email-masked]

Date: Tue, 18 Oct 2005 08:08:09 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] MAN scale and future uses of Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3315

-Regarding scalability problem of high number of flat MAC addresses in 
the MAN,
   There is no such problem,  provided each campus network uses routers 
to participate in the MAN. In this case the only MAC addresses to be 
handled by the
Rbridges are the MACs of the routers used to accesss the MAN.(See Link 
State Over MAC, Garc?a and Duato 2003   proposal for such an example)
- Another aspect to analyze consider in the MAN environment is the 
interoperability with provider bridges (.1ad .1ah) and their 
encapsulations.
Guillermo

Sofia, Rute wrote:

>>  This is one reason for the dominance of OSPF over RIP at L3. 
>>
>>  Shortest paths are of course of interest in the MAN but 
>>other reasons
>>why Rbridge is attractive in the MAN consist of future uses 
>>of its link
>>state topology. In particular as Alia pointed out, RAPID 
>>style rerouting
>>(loop free alternates) is possible. Also the link state topology is
>>useful for constraint based routing. So let's not rule out 
>>larger scale
>>in the future, especially since this is where Rbridge will 
>>really shine.
>>
>>    
>>
>Besides the fact that having "all" the topology at hand provides greater
>flexibility to decide on how to forward information, scalability issues
>concerning Rbridges imply more than just the forwarding algorithm of
>choice. 
>
> Considering Rbridges application from a MAN scope, other scalability
>issues relate to:
>-  storage cost (the price of flat addressing and of having every
>Rbridge learning both requested and unrequested MAC destination
>addresses) may be decreased, but is something that has not be considered
>up until now, given that the scope is limited to a campus...
>
>- backward compatibility issues currently being discussed (i.e., whether
>to have Rbridges as termination of STs). If the use of Rbridges within
>the MAN is not to be disregarded, then there is a cost related to having
>Rbridges interworking with legacy bridges. By not allowing Rbridges to
>intervene in the ST (using BLOCK) then the Rbridge placement must be
>carefully chosen, or performance will degrade. 
>
>- scalability due to broadcasts. As Saikat stated, there are better
>approaches to treat broadcasts and not really requiring much more
>computational power (given that all the information is local)
>
>- scalability related to the IS-IS tuning. On this point, (I am not
>completely sure about the price but...), there is a price to pay to tune
>IS-IS in order to achieve convergence in the order of hundreds of
>seconds. This is another issue to be checked.
>
>Summing up, these are issues to be considered *if* Rbridges is to be
>extended to something larger than a campus. But going back to the
>participate vs. non-participate in the ST issue, then the scope is
>something that may help in deciding this issue. As I said, I do not see
>that Rbridges need to intervene *if* the scope is limited to a campus.
>Why? Because as stated in Radia's paper, Rbridges can simply terminate
>STs, which makes all the sense given that a Rbridge is a hybrid router.
>But this scenario does not seem to make the same sense, if a MAN scope
>is considered...
>
>
>
>
>Regards,
>Rute
>[email-masked]

Date: Mon, 17 Oct 2005 22:58:59 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2149

I'm sorry, but I don't understand your example  (in a different
email), and don't understand why you think
isolating bridges into islands that create the illusion, to RBridges, of 
a single link can be a problem.
And I don't see why having RBridges as a layer above the bridges isn't 
the same as routers
being a layer above bridges.
And I can't think of a way of explaining it any differently. Perhaps 
somoene else can try,
or perhaps I can talk to you by phone sometime. But I'm travelling again.

Radia

Joe Touch wrote:

>[email-masked] wrote:
>  
>
>>It works perfectly well if RBridges block. It isolates the bridge islands.
>>
>>Routers also block bridge spanning tree, and to exactly the same
>>effect as if RBridges block BPDUs.
>>    
>>
>
>This isn't the same at all; I keep hearing the analogy, but it fails
>under all tests:
>
>	first, there are NO routers on an L2 net
>
>	all sources/sinks are the same (called nodes AFAICT)
>	and hosts and routers are just nodes,
>	identical as far as L2 is concerned
>
>	nodes block all BPDUs (we agree), but
>	nodes also block broadcast (rbridges don't)
>
>Near as I can tell, L2 has exactly three devices currently:
>
>	nodes
>
>	links
>
>	bridges (participate in SPT, interpret BPDUs)
>
>Bridges don't 'block' BPDUs, but they don't forward them to all ports
>either.
>
>Now, an rbridge can be "like" a node, a link, or a bridge and still play
>in the existing L2 specs. If it isn't 'like' any of those, then we're
>changing the definition of 802, and I didn't think that was the goal here.
>
>rbridges - at least to nodes on the L2 - are NOT 'like' hosts, since
>they don't source or sink L2 traffic to existing nodes
>
>rbridges could be 'like' links if they are TRANSPARENT
>
>rbridges could be 'like' bridges if the PARTICIPATE
>
>What exactly are rbridges 'like' if they BLOCK?
>
>They can't be 'like' routers - there are no routers in L2.
>
>??
>
>Joe
>  
>
>------------------------------------------------------------------------
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 18 Oct 2005 01:40:17 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3664

> Here's the counterexample:
> 
> Have existing bridges BLOCK.

  Thats not really a counter example but let me try to explain 
where you are getting confused below. 
 
> Assume each bridge computes its own spanning tree internally 
> (i.e., between its own ports on its own device), and sends 
> coded 'hellos' that it it recognizes if they loop, i.e., all 
> the thinks a campus would do.

  Because it would not be a MINIMUM spanning tree. However, yes, if you
repeatedly connect a set of node disjoint trees together with a single 
link, reducing the number of trees by one each time, the result is a 
tree. This I think is what you are suggesting and yes, I believe 
an algorithm like this does actually make a tree. The catch is that it
is NOT a minimum spanning tree and you cannot easily select a root.
STP produces a minimum spanning tree rooted where you want it so
you get much more with the STP protocol than just the hello/detect/block
idea. STP requires its BPDUs to flood through the network to elect
the root and compute paths to it and rbridge requires link state to
flood link information so it can compute the minium spanning tree.
Both protocols need to know about ALL the possible paths in their 
domains to minimize the resulting tree.
The DR mechanism is only used to prevent a loop between these two
domains but it does not by itself guarantee that the combination of
the two trees is still minimum. Therefore, the DR mechanism if applied 
by itself as you suggest does produce a tree but it is not minimum and
you
have no control over the root that is selected.

  Rbridge of course only uses this DR mechanism at the interface between
itself and some other domain (STP or manually configured), and so 
you end up with a minimum spanning tree in STP and a minimum spanning
tree in the rbridge
domain but the combination of the two is not necessarily the best
possible
since neither minimization was done over the complete set of links/nodes
available. This makes sense because if you take two minimum solutions 
over disjoint sets you cannot simply add them together to produce a 
global minimum solution. For example, I cannot take a shortest path from
some node S to an intermediate E and a shortest path from E to D, add
them together and
get the shortest path from S to D because there may be a much better E!
 
> Now if that works, let's do it for bridges and then we 
> wouldn't have a spanning tree convergence problem at all, right?

  It produces a tree but not a minimum spanning tree with no control
over
the root. So its not quite the 'work' you had in mind and this in a nut
shell is I believe your mistake.
 
> If that does NOT work, then why does it work for rbridge 
> campuses and not bridges?

  It does work its just that we want minimum spanning trees and
to do that we need information about all the nodes we can reach.
STP gets this by flooding BPDUSs and Rbridges by link state updates. 
Take away the BPUDS and you can't get minimum. Rbridges can take
the BPDU away [BLOCk] because it does its own minimum and combines the
results with DR to produce a possibly non global minimum solution but
that is the price you pay for neither side seeing all the data.

> My general test is "an rbridge campus needs to look like a 
> bridge" or "look like a link". If it does, then I know I 
> understand it. When it doesn't, it would be useful to 
> understand whether this is really a 'new  animal' and exactly 
> why it's newness is unique to rbridges (i.e., why it can't be 
> applied as well to bridges).

  I think you need to think of this as a new animal as Radia suggested.

  Hope this helps.

  Peter

> Joe

Date: Mon, 17 Oct 2005 20:20:39 -0700
From: Joe Touch <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1951

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2BCAA69D061094D597EE81B5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Saikat Ray wrote:
> Now you can have an rbridge and an sbridge in the same L2 (how do you
> know you don't?). They form an undetectable, uncorrectable loop.
> 
> 
> [Saikat] I do not see how this happens. First I am assuming that if
> "sbridges" are connected by physical links, then they know how to avoid
> packet loops by some mechanism they choose to implement. Now, as far as
> "sbridges" are concerned, the network consisting of RBridges, STP-running
> bridges, physical links etc., is simply a "link". In other words, the entire
> network (consisting of RBridges, STP-running bridges, physical links etc.)
> could be replaced by a physical link. Thus even in this case, there would be
> no packet loop in the steady state.
> 
> Another way of looking at this argument is the following. Suppose you remove
> all the RBridges from the network. sBridges and legacy bridges are left, and
> the assumption is that in that case, at least, a loop-free network results.
> Then when you add RBridges (in their original position), the rest of the
> network is simply one or more "link"s, and RBridges would ensure that there
> would be no loops.

Except that the rbridges add a 'link' between themselves - that's the
extra 'link' that can cause the loop.

Joe

--------------enig2BCAA69D061094D597EE81B5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig2BCAA69D061094D597EE81B5--

Date: Mon, 17 Oct 2005 20:18:35 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2913

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig72C05E9D880157C133FFA156
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Ashwood-Smith wrote:
>>>  Also, the 'problems' that people are attributing to 
>>
>>blocking and not 
>>
>>>processing BPDUs [BLOCK] are also 'problems' when no STP is running.
>>
>>'problems'? (why the quotes?)
> 
> 
>   Because I don't see them and did not want people to think I did.
>  
> 
>>OK, let's just shut off spanning tree in bridges and it all 
>>works just fine now?
>>
>>Now I'm *really* confused.
> 
> 
>   Sorry, my explaination was not very clear. I was simply pointing out
> that
> the Rbridge DR mechanism avoids loops independently of the STP protocol.
> Therefore, if there are no loops PRIOR to the introduction of the
> rbridges
> and their interconnections, but there is a loop AFTER their introduction
> the
> rbridges will detect and prevent it. In otherwords they detect and
> prevent
> loops for which they are responsible.
> 
> 
>>If we want to say "BLOCK *MAY* work, but *MAY* silently 
>>fail", and "PARTICIPATE and TRANSPARENT will always work with 
>>current standards", that's fine (and, AFAICT, true), but I 
>>also don't see how we pick BLOCK as a default in that case.
> 
> 
>   I'd like to see the example of BLOCK failing and by failing I
> mean a permanent loop uncorrected by either STP or Rbridge. Personally
> I don't think this exists because the simple 'proof' of interconnecting
> two
> trees with a single link still being a tree seems pretty air tight to
> me!

Here's the counterexample:

Have existing bridges BLOCK.

Assume each bridge computes its own spanning tree internally (i.e.,
between its own ports on its own device), and sends coded 'hellos' that
it it recognizes if they loop, i.e., all the thinks a campus would do.

Now if that works, let's do it for bridges and then we wouldn't have a
spanning tree convergence problem at all, right?

If that does NOT work, then why does it work for rbridge campuses and
not bridges?

My general test is "an rbridge campus needs to look like a bridge" or
"look like a link". If it does, then I know I understand it. When it
doesn't, it would be useful to understand whether this is really a 'new
 animal' and exactly why it's newness is unique to rbridges (i.e., why
it can't be applied as well to bridges).

Joe

--------------enig72C05E9D880157C133FFA156
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig72C05E9D880157C133FFA156--

Date: Mon, 17 Oct 2005 20:12:51 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2028

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig127E5339470D5D364382FE92
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

[email-masked] wrote:
> It works perfectly well if RBridges block. It isolates the bridge islands.
> 
> Routers also block bridge spanning tree, and to exactly the same
> effect as if RBridges block BPDUs.

This isn't the same at all; I keep hearing the analogy, but it fails
under all tests:

	first, there are NO routers on an L2 net

	all sources/sinks are the same (called nodes AFAICT)
	and hosts and routers are just nodes,
	identical as far as L2 is concerned

	nodes block all BPDUs (we agree), but
	nodes also block broadcast (rbridges don't)

Near as I can tell, L2 has exactly three devices currently:

	nodes

	links

	bridges (participate in SPT, interpret BPDUs)

Bridges don't 'block' BPDUs, but they don't forward them to all ports
either.

Now, an rbridge can be "like" a node, a link, or a bridge and still play
in the existing L2 specs. If it isn't 'like' any of those, then we're
changing the definition of 802, and I didn't think that was the goal here.

rbridges - at least to nodes on the L2 - are NOT 'like' hosts, since
they don't source or sink L2 traffic to existing nodes

rbridges could be 'like' links if they are TRANSPARENT

rbridges could be 'like' bridges if the PARTICIPATE

What exactly are rbridges 'like' if they BLOCK?

They can't be 'like' routers - there are no routers in L2.

??

Joe

--------------enig127E5339470D5D364382FE92
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig127E5339470D5D364382FE92--

Date: Mon, 17 Oct 2005 13:59:45 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3528

And actually, people seemed to want to compute a per-ingress RBridge 
spanning tree.
The ingress RBridge will be in the shim header. So there is no problem 
with the root
of the tree changing, since they are not calculating a single tree.

The reasons for computing different trees (using the link state 
database) for each ingress RBridge are,
if I recall:

a) more optimized VLAN broadcast domain (if only a few links are in VLAN 
A, might as well
have shortest paths between those links, rather than a single spanning 
tree, which might cause a very
long path between two VLAN A links
b) more optimized IP multicast paths, when there are not receivers on 
many links (if there are
receivers on most of the links, having a per-ingress tree isn't that useful)
c) avoiding getting packets out of order when S starts talking to D, and 
ingress RBridge R1 does
not yet know the location of D. Using a per-ingress RBridge tree, the 
packets will take
the same path whether R1 knows where D is or not.

Radia

Saikat Ray wrote:

>You do not even need a ?root? really! Each RBridge has the *global*
>topology. They can simply each run Kruskal's algorithm and compute the (nee
>*a*) minimum weight spanning tree (which is probably the right thing to do
>anyway for broadcast purposes).
>
>________________________________________
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Vishwas Manral
>Sent: Monday, October 17, 2005 7:27 AM
>Subject: Re: [rbridge] Treating broadcast addresses
>
>Hi Rute,
>
>Would this also mean Root-Election? What about convergence of this tree?
>
>Thanks,
>Vishwas
>________________________________________
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Sofia, Rute
>Sent: Monday, October 17, 2005 4:36 PM
>Subject: Re: [rbridge] Treating broadcast addresses
>
>Vishwas,
> 
>based on the information exchanged by LSPs you can simply compute the ST
>locally. The key here is the choice of the root. This can also be passed
>along by IS-IS...
> 
>Regards,
>Rute
> 
>Hi,
>
>My question is more like, how would we build a spanning tree for broadcast
>using IS-IS? 
>
>We need a globally coordinated tree like STP and not like the way IS-IS
>computes it. Would we require, changes to the spanning tree computation
>itself?
>
>Thanks,
>Vishwas
>________________________________________
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Vishwas Manral
>Sent: Monday, October 17, 2005 11:41 AM
>Subject: [rbridge] Treating broadcast addresses
>
>Hi,
>
>I had a doubt about treatment of broadcast addresses.
>
>Currently using STP we have one tree and ports are blocked/ forwarding, so
>packets cannot loop irrespective of destination addresses. In IS-IS
>protocol, we use ports based on destination address and no ports are blocked
>or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could
>end in a forwarding loop. How would we get over it?
>
>Would we still allow broadcast destination address packets to be forwarded?
>It is like preventing flooding loops in a case where we have a global
>broadcast IP address, which is forwarded to all attached routers. Am I
>missing the point all together?
>
>Thanks,
>Vishwas
>
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 15:50:17 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] MAN scale and future uses of Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 14653

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5D353.FFE37CC6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

There is perhaps hope for higher rates of change and/or large scale for
flat addresses spaces. The query routing stuff (P2P networking) in
particular looks promising. Who knows perhaps it can be applied at L2 in
the future.
=20
What is 'large enough'? Well increased scale is not necessarily to be
used for larger deployments. An increase in scalability has other more
important (IMHO) benefits. In particular if something can scale well
beyond the deployment scenarios it will be much more stable at the sizes
more commonly deployed. In other words you are not at the edge of your
operating envelope .. you are safely somewhere in the middle with lots
of head room. You can safely change/grow and shrink without worrying
about stability (and can survive spikes such as earthquakes, hurricanes
and ice storms). Anyway, once you increase the possible scale, the next
question of how many routers v.s rbridges is more one of functionality.
The rbridge won't be able to move further out until it has enough
features to take a bite out of its attached routers .. hopefully it can
do that while staying cheaper but at the moment its going to run out of
features before it runs out of scaling oompf. Anyway that's a long
winded way of saying ... beats me ;)
=20
=20
Peter

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alia Atlas
	Sent: Monday, October 17, 2005 3:02 PM
	To: Developing a hybrid router/bridge.
	Subject: Re: [rbridge] MAN scale and future uses of Rbridge
=09
=09
	On 10/17/05, Peter Ashwood-Smith <[email-masked]> wrote:=20
=09

		I think the main impediment to very large scale is the
large flat address space and its rate of change. Not the number or
Rbridge nodes and networks/links. While use of IS-IS or OSPF areas can
help when addressing is hierarchical, they are not going to help much
when you cannot aggregate the addresses into specific areas.

	There are environments where the rate of change could be
reasonably bounded, so that brings it back to the flat address space...
=09

		Then again I don't think that Rbridge needs to scale
that large to be enormously useful. If it pushes the attainable size out
a bit, gives better routes, is more stable and allows future innovations
based on the topology it is going to be very useful. After that .. well
its routers all the way down ;)

	What do you think is large enough?  (I remember the discussion
earlier, but not specific numbers.)
=09
	Alia=20
=09

	=09
		Peter=20
	=09

			-----Original Message-----
			From: [email-masked] [mailto:
[email-masked] <mailto:[email-masked]> ] On
Behalf Of Alia Atlas
			Sent: Monday, October 17, 2005 2:37 PM
			To: Developing a hybrid router/bridge.
			Subject: Re: [rbridge] MAN scale and future uses
of Rbridge
		=09
		=09

			On 10/17/05, Sofia, Rute
<[email-masked]> wrote:=20

				Considering Rbridges application from a
MAN scope, other scalability
				issues relate to:
				-  storage cost (the price of flat
addressing and of having every
				Rbridge learning both requested and
unrequested MAC destination=20
				addresses) may be decreased, but is
something that has not be considered
				up until now, given that the scope is
limited to a campus...

			 What number of MAC addresses is the target for
the rbridge campus?   Do you
			think the constraints are on the memory or on
the notifications required due to changes?=20
		=09
		=09

				- scalability related to the IS-IS
tuning. On this point, (I am not
				completely sure about the price but...),
there is a price to pay to tune=20
				IS-IS in order to achieve convergence in
the order of hundreds of
				seconds. This is another issue to be
checked.

			Is there a reason that different areas couldn't
be used in the IS-IS instance for rbridges?
			Do you think this would be adequate?  Are the
topological restrictions (i.e. hub and spoke)
			acceptable?  Could we work around that?
		=09

				Summing up, these are issues to be
considered *if* Rbridges is to be
				extended to something larger than a
campus. But going back to the=20
				participate vs. non-participate in the
ST issue, then the scope is
				something that may help in deciding this
issue. As I said, I do not see
				that Rbridges need to intervene *if* the
scope is limited to a campus.
				Why? Because as stated in Radia's paper,
Rbridges can simply terminate
				STs, which makes all the sense given
that a Rbridge is a hybrid router.
				But this scenario does not seem to make
the same sense, if a MAN scope
				is considered...
			=09

			While improving the scalability may not be
immediately in scope, I think it is
			worthwhile to consider where the restrictions
are coming from.
		=09
			Alia
		=09

		[email-masked]
	=09
	=09
	=09
	=09

------_=_NextPart_001_01C5D353.FFE37CC6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN><SPAN class=3D058141619-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>There is perhaps hope for higher rates of =
change and/or=20
large scale for flat addresses spaces. The query routing stuff (P2P =
networking)=20
in particular looks promising. Who knows perhaps it can be applied at L2 =
in the=20
future.</FONT></SPAN></DIV>
<DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff =
size=3D2>What=20
is 'large enough'? Well increased scale is not necessarily to be used =
for larger=20
deployments. An increase in scalability has other more important (IMHO)=20
benefits. In particular if something can scale well beyond the =
deployment=20
scenarios it will be much more stable at the sizes more commonly =
deployed. In=20
other words you are not at the&nbsp;edge of your operating =
envelope&nbsp;.. you=20
are safely somewhere in the middle with lots of head room. You can =
safely=20
change/grow and shrink without worrying about stability (and can survive =
spikes=20
such as earthquakes, hurricanes and ice storms). Anyway, once you =
increase the=20
possible scale, the next question of how many routers v.s rbridges is =
more one=20
of functionality. The rbridge won't be able to move further out until it =
has=20
enough features to take a bite out of its attached routers .. hopefully =
it can=20
do that while staying cheaper but at the moment its going to run out of =
features=20
before it runs out of scaling oompf. Anyway that's a long winded way of =
saying=20
... beats me ;)</FONT></SPAN></DIV>
<DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D058141619-17102005><FONT face=3DArial color=3D#0000ff =

size=3D2>Peter</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>Alia Atlas<BR><B>Sent:</B> Monday, October 17, 2005 3:02 =
PM<BR><B>To:</B>=20
  Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] =
MAN scale=20
  and future uses of Rbridge<BR><BR></FONT></DIV>On 10/17/05, <B=20
  class=3Dgmail_sendername>Peter Ashwood-Smith</B> &lt;<A=20
  href=3D"mailto:[email-masked]">[email-masked]</A>&gt; wrote:
  <DIV><SPAN class=3Dgmail_quote></SPAN>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV><SPAN><FONT face=3DArial color=3D#0000ff size=3D2>I think the =
main impediment=20
    to very large scale is the large flat address space and its rate of =
change.=20
    Not the number or Rbridge nodes and networks/links.&nbsp;While use =
of IS-IS=20
    or OSPF areas can help when addressing is hierarchical, they are not =
going=20
    to help much when you cannot aggregate the addresses into specific=20
    areas.</FONT></SPAN></DIV></BLOCKQUOTE>
  <DIV><BR>There are environments where the rate of change could be =
reasonably=20
  bounded, so that brings it back to the flat address =
space...<BR></DIV><BR>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV><SPAN><FONT face=3DArial color=3D#0000ff size=3D2>Then again I =
don't think=20
    that Rbridge needs to scale that large to be enormously useful. If =
it pushes=20
    the attainable size out a bit, gives better routes, is more =
stable&nbsp;and=20
    allows future innovations based on the topology it is going to be =
very=20
    useful. After that .. well its routers all the way down=20
    ;)</FONT></SPAN></DIV></BLOCKQUOTE>
  <DIV><BR>What do you think is large enough?&nbsp; (I remember the =
discussion=20
  earlier, but not specific numbers.)<BR><BR>Alia <BR></DIV><BR>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid"><SPAN=20
    class=3Dsg>
    <DIV><SPAN><FONT face=3DArial color=3D#0000ff size=3D2>Peter</FONT>=20
    </SPAN></DIV></SPAN>
    <DIV><SPAN class=3De id=3Dq_106ffefd56937552_2>
    <BLOCKQUOTE=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: =
rgb(0,0,255) 2px solid; MARGIN-RIGHT: 0px">
      <DIV></DIV>
      <DIV lang=3Den-us dir=3Dltr align=3Dleft><FONT face=3DTahoma =
size=3D2>-----Original=20
      Message-----<BR><B>From:</B> <A=20
      onclick=3D"return top.js.OpenExtLink(window,event,this)"=20
      href=3D"mailto:[email-masked]"=20
      target=3D_blank>[email-masked]</A> [mailto:<A=20
      onclick=3D"return top.js.OpenExtLink(window,event,this)"=20
      href=3D"mailto:[email-masked]" target=3D_blank>=20
      [email-masked]</A>] <B>On Behalf Of </B>Alia=20
      Atlas<BR><B>Sent:</B> Monday, October 17, 2005 2:37 =
PM<BR><B>To:</B>=20
      Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: =
[rbridge] MAN=20
      scale and future uses of Rbridge<BR><BR></FONT></DIV><BR><BR>
      <DIV><SPAN class=3Dgmail_quote>On 10/17/05, <B =
class=3Dgmail_sendername>Sofia,=20
      Rute</B> &lt;<A onclick=3D"return =
top.js.OpenExtLink(window,event,this)"=20
      href=3D"mailto:[email-masked]"=20
      target=3D_blank>[email-masked]</A>&gt; wrote:</SPAN>=20
      <BLOCKQUOTE class=3Dgmail_quote=20
      style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; =
BORDER-LEFT: rgb(204,204,204) 1px solid">Considering=20
        Rbridges application from a MAN scope, other =
scalability<BR>issues=20
        relate to:<BR>-&nbsp;&nbsp;storage cost (the price of flat =
addressing=20
        and of having every<BR>Rbridge learning both requested and =
unrequested=20
        MAC destination <BR>addresses) may be decreased, but is =
something that=20
        has not be considered<BR>up until now, given that the scope is =
limited=20
        to a campus...</BLOCKQUOTE>
      <DIV><BR>&nbsp;What number of MAC addresses is the target for the =
rbridge=20
      campus?&nbsp;&nbsp; Do you<BR>think the constraints are on the =
memory or=20
      on the notifications required due to changes? <BR><BR></DIV>
      <BLOCKQUOTE class=3Dgmail_quote=20
      style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; =
BORDER-LEFT: rgb(204,204,204) 1px solid">-=20
        scalability related to the IS-IS tuning. On this point, (I am=20
        not<BR>completely sure about the price but...), there is a price =
to pay=20
        to tune <BR>IS-IS in order to achieve convergence in the order =
of=20
        hundreds of<BR>seconds. This is another issue to be =
checked.</BLOCKQUOTE>
      <DIV><BR>Is there a reason that different areas couldn't be used =
in the=20
      IS-IS instance for rbridges?<BR>Do you think this would be =
adequate?&nbsp;=20
      Are the topological restrictions (i.e. hub and =
spoke)<BR>acceptable?&nbsp;=20
      Could we work around that?<BR></DIV><BR>
      <BLOCKQUOTE class=3Dgmail_quote=20
      style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; =
BORDER-LEFT: rgb(204,204,204) 1px solid">Summing=20
        up, these are issues to be considered *if* Rbridges is to =
be<BR>extended=20
        to something larger than a campus. But going back to the =
<BR>participate=20
        vs. non-participate in the ST issue, then the scope =
is<BR>something that=20
        may help in deciding this issue. As I said, I do not see<BR>that =

        Rbridges need to intervene *if* the scope is limited to a=20
        campus.<BR>Why? Because as stated in Radia's paper, Rbridges can =
simply=20
        terminate<BR>STs, which makes all the sense given that a Rbridge =
is a=20
        hybrid router.<BR>But this scenario does not seem to make the =
same=20
        sense, if a MAN scope<BR>is =
considered...<BR></BLOCKQUOTE></DIV><BR>While=20
      improving the scalability may not be immediately in scope, I think =
it=20
      is<BR>worthwhile to consider where the restrictions are coming=20
      =
from.<BR><BR>Alia<BR></BLOCKQUOTE></SPAN></DIV><BR>______________________=
_________________________<BR>rbridge=20
    mailing list<BR><A onclick=3D"return =
top.js.OpenExtLink(window,event,this)"=20
    href=3D"mailto:[email-masked]">[email-masked]</A><BR><A=20
    onclick=3D"return top.js.OpenExtLink(window,event,this)"=20
    href=3D"http://www.postel.org/mailman/listinfo/rbridge"=20
    =
target=3D_blank>http://www.postel.org/mailman/listinfo/rbridge</A><BR><BR=
><BR><BR=20
    clear=3Dall></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>
=00
------_=_NextPart_001_01C5D353.FFE37CC6--

Date: Mon, 17 Oct 2005 12:01:49 -0700
From: Alia Atlas <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] MAN scale and future uses of Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9728

------=_Part_20407_136698.1129575709588
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/17/05, Peter Ashwood-Smith <[email-masked]> wrote:
>
> I think the main impediment to very large scale is the large flat address
> space and its rate of change. Not the number or Rbridge nodes and
> networks/links. While use of IS-IS or OSPF areas can help when addressing=
 is
> hierarchical, they are not going to help much when you cannot aggregate t=
he
> addresses into specific areas.
>

There are environments where the rate of change could be reasonably bounded=
,
so that brings it back to the flat address space...

Then again I don't think that Rbridge needs to scale that large to be
> enormously useful. If it pushes the attainable size out a bit, gives bett=
er
> routes, is more stable and allows future innovations based on the topolog=
y
> it is going to be very useful. After that .. well its routers all the way
> down ;)
>

What do you think is large enough? (I remember the discussion earlier, but
not specific numbers.)

Alia

Peter
> *From:* [email-masked] [mailto:[email-masked]] *O=
n
> Behalf Of *Alia Atlas
> *Sent:* Monday, October 17, 2005 2:37 PM
> *To:* Developing a hybrid router/bridge.
> *Subject:* Re: [rbridge] MAN scale and future uses of Rbridge
>
>
>
> On 10/17/05, Sofia, Rute <[email-masked]> wrote:
> >
> > Considering Rbridges application from a MAN scope, other scalability
> > issues relate to:
> > - storage cost (the price of flat addressing and of having every
> > Rbridge learning both requested and unrequested MAC destination
> > addresses) may be decreased, but is something that has not be considere=
d
> > up until now, given that the scope is limited to a campus...
>
>
> What number of MAC addresses is the target for the rbridge campus? Do you
> think the constraints are on the memory or on the notifications required
> due to changes?
>
> - scalability related to the IS-IS tuning. On this point, (I am not
> > completely sure about the price but...), there is a price to pay to tun=
e
> >
> > IS-IS in order to achieve convergence in the order of hundreds of
> > seconds. This is another issue to be checked.
>
>
> Is there a reason that different areas couldn't be used in the IS-IS
> instance for rbridges?
> Do you think this would be adequate? Are the topological restrictions (i.=
e.
> hub and spoke)
> acceptable? Could we work around that?
>
> Summing up, these are issues to be considered *if* Rbridges is to be
> > extended to something larger than a campus. But going back to the
> > participate vs. non-participate in the ST issue, then the scope is
> > something that may help in deciding this issue. As I said, I do not see
> > that Rbridges need to intervene *if* the scope is limited to a campus.
> > Why? Because as stated in Radia's paper, Rbridges can simply terminate
> > STs, which makes all the sense given that a Rbridge is a hybrid router.
> > But this scenario does not seem to make the same sense, if a MAN scope
> > is considered...
> >
>
> While improving the scalability may not be immediately in scope, I think
> it is
> worthwhile to consider where the restrictions are coming from.
>
> Alia
>
>
> [email-masked]

------=_Part_20407_136698.1129575709588
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/17/05, <b class=3D"gmail_sendername">Peter Ashwood-Smith</b> &lt;<a h=
ref=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<div><span=
 class=3D"gmail_quote"></span><blockquote class=3D"gmail_quote" style=3D"bo=
rder-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding=
-left: 1ex;">

<div><span><font color=3D"#0000ff" face=3D"Arial" size=3D"2">I=20
think the main impediment to very large scale is the large flat address spa=
ce=20
and its rate of change. Not the number or Rbridge nodes and=20
networks/links.&nbsp;While use of IS-IS or OSPF areas can help when address=
ing=20
is hierarchical, they are not going to help much when you cannot aggregate =
the=20
addresses into specific areas.</font></span></div></blockquote><div><br>
There are environments where the rate of change could be reasonably bounded=
, so that brings it back to the flat address space...<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><s=
pan><font color=3D"#0000ff" face=3D"Arial" size=3D"2">Then=20
again I don't think that Rbridge needs to scale that large to be enormously=
=20
useful. If it pushes the attainable size out a bit, gives better routes, is=
 more=20
stable&nbsp;and allows future innovations based on the topology it is going=
 to=20
be very useful. After that .. well its routers all the way down=20
;)</font></span></div></blockquote><div><br>
What do you think is large enough?&nbsp; (I remember the discussion earlier=
, but not specific numbers.)<br>
<br>
Alia <br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span c=
lass=3D"sg"><div><span><font color=3D"#0000ff" face=3D"Arial" size=3D"2">Pe=
ter</font>
</span></div></span><div><span class=3D"e" id=3D"q_106ffefd56937552_2">
<blockquote style=3D"border-left: 2px solid rgb(0, 0, 255); padding-left: 5=
px; margin-left: 5px; margin-right: 0px;">
  <div></div>
  <div align=3D"left" dir=3D"ltr" lang=3D"en-us"><font face=3D"Tahoma" size=
=3D"2">-----Original Message-----<br><b>From:</b>=20
  <a href=3D"mailto:[email-masked]" target=3D"_blank" onclick=
=3D"return top.js.OpenExtLink(window,event,this)">[email-masked]=
g</a> [mailto:<a href=3D"mailto:[email-masked]" target=3D"_blan=
k" onclick=3D"return top.js.OpenExtLink(window,event,this)">
[email-masked]</a>] <b>On Behalf Of=20
  </b>Alia Atlas<br><b>Sent:</b> Monday, October 17, 2005 2:37 PM<br><b>To:=
</b>=20
  Developing a hybrid router/bridge.<br><b>Subject:</b> Re: [rbridge] MAN s=
cale=20
  and future uses of Rbridge<br><br></font></div><br><br>
  <div><span class=3D"gmail_quote">On 10/17/05, <b class=3D"gmail_sendernam=
e">Sofia,=20
  Rute</b> &lt;<a href=3D"mailto:[email-masked]" target=3D"_blank" =
onclick=3D"return top.js.OpenExtLink(window,event,this)">rute.sofia@siemens=
.com</a>&gt;=20
  wrote:</span>
  <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204=
, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Considering=20
    Rbridges application from a MAN scope, other scalability<br>issues rela=
te=20
    to:<br>-&nbsp;&nbsp;storage cost (the price of flat addressing and of h=
aving=20
    every<br>Rbridge learning both requested and unrequested MAC destinatio=
n=20
    <br>addresses) may be decreased, but is something that has not be=20
    considered<br>up until now, given that the scope is limited to a=20
  campus...</blockquote>
  <div><br>&nbsp;What number of MAC addresses is the target for the rbridge=
=20
  campus?&nbsp;&nbsp; Do you<br>think the constraints are on the memory or =
on=20
  the notifications required due to changes? <br><br></div>
  <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204=
, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-=20
    scalability related to the IS-IS tuning. On this point, (I am=20
    not<br>completely sure about the price but...), there is a price to pay=
 to=20
    tune <br>IS-IS in order to achieve convergence in the order of hundreds=
=20
    of<br>seconds. This is another issue to be checked.</blockquote>
  <div><br>Is there a reason that different areas couldn't be used in the I=
S-IS=20
  instance for rbridges?<br>Do you think this would be adequate?&nbsp; Are =
the=20
  topological restrictions (i.e. hub and spoke)<br>acceptable?&nbsp; Could =
we=20
  work around that?<br></div><br>
  <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204=
, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Summing=20
    up, these are issues to be considered *if* Rbridges is to be<br>extende=
d to=20
    something larger than a campus. But going back to the <br>participate v=
s.=20
    non-participate in the ST issue, then the scope is<br>something that ma=
y=20
    help in deciding this issue. As I said, I do not see<br>that Rbridges n=
eed=20
    to intervene *if* the scope is limited to a campus.<br>Why? Because as=
=20
    stated in Radia's paper, Rbridges can simply terminate<br>STs, which ma=
kes=20
    all the sense given that a Rbridge is a hybrid router.<br>But this scen=
ario=20
    does not seem to make the same sense, if a MAN scope<br>is=20
  considered...<br></blockquote></div><br>While improving the scalability m=
ay=20
  not be immediately in scope, I think it is<br>worthwhile to consider wher=
e the=20
  restrictions are coming from.<br><br>Alia<br></blockquote>
</span></div><br>_______________________________________________<br>rbridge=
 mailing list<br><a onclick=3D"return top.js.OpenExtLink(window,event,this)=
" href=3D"mailto:[email-masked]">[email-masked]</a><br><a onclick=
=3D"return top.js.OpenExtLink(window,event,this)" href=3D"http://www.postel=
.org/mailman/listinfo/rbridge" target=3D"_blank">
http://www.postel.org/mailman/listinfo/rbridge</a><br><br><br><br clear=3D"=
all"></blockquote></div><br>

------=_Part_20407_136698.1129575709588--

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 14:48:48 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] MAN scale and future uses of Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7976

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5D34B.68C2DCA6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think the main impediment to very large scale is the large flat
address space and its rate of change. Not the number or Rbridge nodes
and networks/links. While use of IS-IS or OSPF areas can help when
addressing is hierarchical, they are not going to help much when you
cannot aggregate the addresses into specific areas.
=20
Then again I don't think that Rbridge needs to scale that large to be
enormously useful. If it pushes the attainable size out a bit, gives
better routes, is more stable and allows future innovations based on the
topology it is going to be very useful. After that .. well its routers
all the way down ;)
=20
Peter

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alia Atlas
	Sent: Monday, October 17, 2005 2:37 PM
	To: Developing a hybrid router/bridge.
	Subject: Re: [rbridge] MAN scale and future uses of Rbridge
=09
=09

	On 10/17/05, Sofia, Rute <[email-masked]> wrote:=20

		Considering Rbridges application from a MAN scope, other
scalability
		issues relate to:
		-  storage cost (the price of flat addressing and of
having every
		Rbridge learning both requested and unrequested MAC
destination=20
		addresses) may be decreased, but is something that has
not be considered
		up until now, given that the scope is limited to a
campus...

	 What number of MAC addresses is the target for the rbridge
campus?   Do you
	think the constraints are on the memory or on the notifications
required due to changes?=20
=09
=09

		- scalability related to the IS-IS tuning. On this
point, (I am not
		completely sure about the price but...), there is a
price to pay to tune=20
		IS-IS in order to achieve convergence in the order of
hundreds of
		seconds. This is another issue to be checked.

	Is there a reason that different areas couldn't be used in the
IS-IS instance for rbridges?
	Do you think this would be adequate?  Are the topological
restrictions (i.e. hub and spoke)
	acceptable?  Could we work around that?
=09

		Summing up, these are issues to be considered *if*
Rbridges is to be
		extended to something larger than a campus. But going
back to the=20
		participate vs. non-participate in the ST issue, then
the scope is
		something that may help in deciding this issue. As I
said, I do not see
		that Rbridges need to intervene *if* the scope is
limited to a campus.
		Why? Because as stated in Radia's paper, Rbridges can
simply terminate
		STs, which makes all the sense given that a Rbridge is a
hybrid router.
		But this scenario does not seem to make the same sense,
if a MAN scope
		is considered...
	=09

	While improving the scalability may not be immediately in scope,
I think it is
	worthwhile to consider where the restrictions are coming from.
=09
	Alia
=09

------_=_NextPart_001_01C5D34B.68C2DCA6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D161384118-17102005><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
think the main impediment to very large scale is the large flat address =
space=20
and its rate of change. Not the number or Rbridge nodes and=20
networks/links.&nbsp;While use of IS-IS or OSPF areas can help when =
addressing=20
is hierarchical, they are not going to help much when you cannot =
aggregate the=20
addresses into specific areas.</FONT></SPAN></DIV>
<DIV><SPAN class=3D161384118-17102005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D161384118-17102005><FONT face=3DArial color=3D#0000ff =
size=3D2>Then=20
again I don't think that Rbridge needs to scale that large to be =
enormously=20
useful. If it pushes the attainable size out a bit, gives better routes, =
is more=20
stable&nbsp;and allows future innovations based on the topology it is =
going to=20
be very useful. After that .. well its routers all the way down=20
;)</FONT></SPAN></DIV>
<DIV><SPAN class=3D161384118-17102005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D161384118-17102005><FONT face=3DArial color=3D#0000ff =

size=3D2>Peter</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>Alia Atlas<BR><B>Sent:</B> Monday, October 17, 2005 2:37 =
PM<BR><B>To:</B>=20
  Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] =
MAN scale=20
  and future uses of Rbridge<BR><BR></FONT></DIV><BR><BR>
  <DIV><SPAN class=3Dgmail_quote>On 10/17/05, <B =
class=3Dgmail_sendername>Sofia,=20
  Rute</B> &lt;<A=20
  href=3D"mailto:[email-masked]">[email-masked]</A>&gt;=20
  wrote:</SPAN>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">Considering=20
    Rbridges application from a MAN scope, other scalability<BR>issues =
relate=20
    to:<BR>-&nbsp;&nbsp;storage cost (the price of flat addressing and =
of having=20
    every<BR>Rbridge learning both requested and unrequested MAC =
destination=20
    <BR>addresses) may be decreased, but is something that has not be=20
    considered<BR>up until now, given that the scope is limited to a=20
  campus...</BLOCKQUOTE>
  <DIV><BR>&nbsp;What number of MAC addresses is the target for the =
rbridge=20
  campus?&nbsp;&nbsp; Do you<BR>think the constraints are on the memory =
or on=20
  the notifications required due to changes? <BR><BR></DIV>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">-=20
    scalability related to the IS-IS tuning. On this point, (I am=20
    not<BR>completely sure about the price but...), there is a price to =
pay to=20
    tune <BR>IS-IS in order to achieve convergence in the order of =
hundreds=20
    of<BR>seconds. This is another issue to be checked.</BLOCKQUOTE>
  <DIV><BR>Is there a reason that different areas couldn't be used in =
the IS-IS=20
  instance for rbridges?<BR>Do you think this would be adequate?&nbsp; =
Are the=20
  topological restrictions (i.e. hub and spoke)<BR>acceptable?&nbsp; =
Could we=20
  work around that?<BR></DIV><BR>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">Summing=20
    up, these are issues to be considered *if* Rbridges is to =
be<BR>extended to=20
    something larger than a campus. But going back to the =
<BR>participate vs.=20
    non-participate in the ST issue, then the scope is<BR>something that =
may=20
    help in deciding this issue. As I said, I do not see<BR>that =
Rbridges need=20
    to intervene *if* the scope is limited to a campus.<BR>Why? Because =
as=20
    stated in Radia's paper, Rbridges can simply terminate<BR>STs, which =
makes=20
    all the sense given that a Rbridge is a hybrid router.<BR>But this =
scenario=20
    does not seem to make the same sense, if a MAN scope<BR>is=20
  considered...<BR></BLOCKQUOTE></DIV><BR>While improving the =
scalability may=20
  not be immediately in scope, I think it is<BR>worthwhile to consider =
where the=20
  restrictions are coming =
from.<BR><BR>Alia<BR></BLOCKQUOTE></BODY></HTML>
=00
------_=_NextPart_001_01C5D34B.68C2DCA6--

Date: Mon, 17 Oct 2005 11:37:03 -0700
From: Alia Atlas <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] MAN scale and future uses of Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4757

------=_Part_20127_24578989.1129574223832
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/17/05, Sofia, Rute <[email-masked]> wrote:
>
> Considering Rbridges application from a MAN scope, other scalability
> issues relate to:
> - storage cost (the price of flat addressing and of having every
> Rbridge learning both requested and unrequested MAC destination
> addresses) may be decreased, but is something that has not be considered
> up until now, given that the scope is limited to a campus...

What number of MAC addresses is the target for the rbridge campus? Do you
think the constraints are on the memory or on the notifications required du=
e
to changes?

- scalability related to the IS-IS tuning. On this point, (I am not
> completely sure about the price but...), there is a price to pay to tune
> IS-IS in order to achieve convergence in the order of hundreds of
> seconds. This is another issue to be checked.

Is there a reason that different areas couldn't be used in the IS-IS
instance for rbridges?
Do you think this would be adequate? Are the topological restrictions (i.e.
hub and spoke)
acceptable? Could we work around that?

Summing up, these are issues to be considered *if* Rbridges is to be
> extended to something larger than a campus. But going back to the
> participate vs. non-participate in the ST issue, then the scope is
> something that may help in deciding this issue. As I said, I do not see
> that Rbridges need to intervene *if* the scope is limited to a campus.
> Why? Because as stated in Radia's paper, Rbridges can simply terminate
> STs, which makes all the sense given that a Rbridge is a hybrid router.
> But this scenario does not seem to make the same sense, if a MAN scope
> is considered...
>

While improving the scalability may not be immediately in scope, I think it
is
worthwhile to consider where the restrictions are coming from.

Alia

------=_Part_20127_24578989.1129574223832
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div><span class=3D"gmail_quote">On 10/17/05, <b class=3D"gmail_sen=
dername">Sofia, Rute</b> &lt;<a href=3D"mailto:[email-masked]">rute=
[email-masked]</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" s=
tyle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8e=
x; padding-left: 1ex;">
Considering Rbridges application from a MAN scope, other scalability<br>iss=
ues relate to:<br>-&nbsp;&nbsp;storage cost (the price of flat addressing a=
nd of having every<br>Rbridge learning both requested and unrequested MAC d=
estination
<br>addresses) may be decreased, but is something that has not be considere=
d<br>up until now, given that the scope is limited to a campus...</blockquo=
te><div><br>
&nbsp;What number of MAC addresses is the target for the rbridge campus?&nb=
sp;&nbsp; Do you<br>
think the constraints are on the memory or on the notifications required du=
e to changes? <br>
<br>
</div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb=
(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- scalabili=
ty related to the IS-IS tuning. On this point, (I am not<br>completely sure=
 about the price but...), there is a price to pay to tune
<br>IS-IS in order to achieve convergence in the order of hundreds of<br>se=
conds. This is another issue to be checked.</blockquote><div><br>
Is there a reason that different areas couldn't be used in the IS-IS instan=
ce for rbridges?<br>
Do you think this would be adequate?&nbsp; Are the topological restrictions=
 (i.e. hub and spoke)<br>
acceptable?&nbsp; Could we work around that?<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Summing=
 up, these are issues to be considered *if* Rbridges is to be<br>extended t=
o something larger than a campus. But going back to the
<br>participate vs. non-participate in the ST issue, then the scope is<br>s=
omething that may help in deciding this issue. As I said, I do not see<br>t=
hat Rbridges need to intervene *if* the scope is limited to a campus.<br>
Why? Because as stated in Radia's paper, Rbridges can simply terminate<br>S=
Ts, which makes all the sense given that a Rbridge is a hybrid router.<br>B=
ut this scenario does not seem to make the same sense, if a MAN scope<br>
is considered...<br>
</blockquote></div><br>
While improving the scalability may not be immediately in scope, I think it=
 is<br>
worthwhile to consider where the restrictions are coming from.<br>
<br>
Alia<br>

------=_Part_20127_24578989.1129574223832--

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 11:24:32 -0700
From: "Michael Smith \(michsmit\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1969

> From: [email-masked] 
> Subject: Re: [rbridge] Time to summarize "forward or block" 
> BPDU thread
> 
> > > b) there are scary dependencies between bridge spanning tree and 
> > > RBridges algorithms
> > 
> >   Yeah no kidding. 
> > 
> > > c) no advantage as far as I can see. I don't know why we are 
> > > discussing this.
> > 
> >   Well there are still a few folks on this list that are 
> not convinced 
> > of a) or b). There are probably 100 more on the list that are just 
> > quietly listening that also don't understand.
> > We are very likely to encounter these opinions over and 
> over again and 
> > the best approach is to discuss and counter them and capture it for 
> > future reference. Otherwise we are going to see these same 
> arguments 
> > over and over again and used as 'reasons' why Rbridge is 
> 'not as good 
> > as X or Y'.
> > 
> 
> My 2cents: if Rbridges scope is indeed a campus, then Radia's 
> claims hold...there is no advantage in having Rbridges 
> meddling with legacy stuff.

While rbridges may not have to "meddle with legacy stuff", at a minimum,
we should list the all of the 802.1 and 802.3 protocols and indicate the
applicable action(s).  (Similar to that done for the UNI in the Metro
Ethernet Forum (MEF) and ITU 8011 series specifications.)  For example,
blocking BPDUs is valid but simply blocking GVRP will cause connectivity
issues.

Michael

> Now, if Rbridges is intended to 
> be applied to other fields, e.g., MAN scope, then yes, legacy 
> is an issue.
> 
> I do not see the second case happening particularly because 
> there are other issues (besides the legacy interworking) that 
> would require additional work in Rbridges. So I quite frankly 
> do not see the point in prolonging this discussion either. 
> 
> So,
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 19:17:55 +0200
From: "Sofia, Rute" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] MAN scale and future uses of Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2560

> 
>   This is one reason for the dominance of OSPF over RIP at L3. 
> 
>   Shortest paths are of course of interest in the MAN but 
> other reasons
> why Rbridge is attractive in the MAN consist of future uses 
> of its link
> state topology. In particular as Alia pointed out, RAPID 
> style rerouting
> (loop free alternates) is possible. Also the link state topology is
> useful for constraint based routing. So let's not rule out 
> larger scale
> in the future, especially since this is where Rbridge will 
> really shine.
> 
Besides the fact that having "all" the topology at hand provides greater
flexibility to decide on how to forward information, scalability issues
concerning Rbridges imply more than just the forwarding algorithm of
choice. 

 Considering Rbridges application from a MAN scope, other scalability
issues relate to:
-  storage cost (the price of flat addressing and of having every
Rbridge learning both requested and unrequested MAC destination
addresses) may be decreased, but is something that has not be considered
up until now, given that the scope is limited to a campus...

- backward compatibility issues currently being discussed (i.e., whether
to have Rbridges as termination of STs). If the use of Rbridges within
the MAN is not to be disregarded, then there is a cost related to having
Rbridges interworking with legacy bridges. By not allowing Rbridges to
intervene in the ST (using BLOCK) then the Rbridge placement must be
carefully chosen, or performance will degrade. 

- scalability due to broadcasts. As Saikat stated, there are better
approaches to treat broadcasts and not really requiring much more
computational power (given that all the information is local)

- scalability related to the IS-IS tuning. On this point, (I am not
completely sure about the price but...), there is a price to pay to tune
IS-IS in order to achieve convergence in the order of hundreds of
seconds. This is another issue to be checked.

Summing up, these are issues to be considered *if* Rbridges is to be
extended to something larger than a campus. But going back to the
participate vs. non-participate in the ST issue, then the scope is
something that may help in deciding this issue. As I said, I do not see
that Rbridges need to intervene *if* the scope is limited to a campus.
Why? Because as stated in Radia's paper, Rbridges can simply terminate
STs, which makes all the sense given that a Rbridge is a hybrid router.
But this scenario does not seem to make the same sense, if a MAN scope
is considered...

Regards,
Rute

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 12:33:18 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] MAN scale and future uses of Rbridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 913

> >   The protocols do not know how they are being applied. They
> > are either
> > mathematically correct or not so I assume you are either 
> talking about
> > scale or migration? 
> 
> About scalability, yes.
> 
> Regards,
> Rute

  In general link state type procotols of which IS-IS and therefore
Rbridge is an example scale better than distance vector style protocols,
of which  STP is a varient. 

  This is one reason for the dominance of OSPF over RIP at L3. 

  Shortest paths are of course of interest in the MAN but other reasons
why Rbridge is attractive in the MAN consist of future uses of its link
state topology. In particular as Alia pointed out, RAPID style rerouting
(loop free alternates) is possible. Also the link state topology is
useful for constraint based routing. So let's not rule out larger scale
in the future, especially since this is where Rbridge will really shine.

  Peter

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 18:09:57 +0200
From: "Sofia, Rute" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 492

> 
> > My 2cents: if Rbridges scope is indeed a campus, then Radia's claims
> > hold...there is no advantage in having Rbridges meddling with legacy
> > stuff. Now, if Rbridges is intended to be applied to other 
> > fields, e.g.,
> > MAN scope, then yes, legacy is an issue.
> 
>   The protocols do not know how they are being applied. They 
> are either
> mathematically correct or not so I assume you are either talking about
> scale or migration? 

About scalability, yes.

Regards,
Rute

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 17 Oct 2005 11:36:23 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2519

There is a *theoretical* possibility of oscillatory behavior if an unknown
third protocol is present in the network (the one that our imaginary
"sbridges" implement). Basically suppose that the protocol sBridges
implement interacts with the STP. Then the following sequence of events may
occur (under the assumption that sBridge control messages look like data
packets to RBridges). First the sBridges and the legacy bridges together
converge to some topology, most likely a disjoint one. During this time,
RBridges are invisible; in particular, sBridges do not see them. Then the
RBridge topology converges. However, now potentially the connectivity that
sBridges see has changed (due to packet forwarding by RBridges). Thus,
sBridges try to recomputed their states, which in turn trigger an STP
recomputation (because we are assuming that sBridge protocol and STP
interacts), and we are back to square one (i.e. an oscillation starts)! I
cannot off the top of my head think of a dumb enough sBridge protocol that
would result into this scenario, but one cannot rule out the possibility!

-----Original Message-----
From: Saikat Ray [mailto:[email-masked]] 
Sent: Monday, October 17, 2005 11:22 AM
To: 'Developing a hybrid router/bridge.'
Subject: FW: [rbridge] Time to summarize "forward or block" BPDU thread

Now you can have an rbridge and an sbridge in the same L2 (how do you
know you don't?). They form an undetectable, uncorrectable loop.

[Saikat] I do not see how this happens. First I am assuming that if
"sbridges" are connected by physical links, then they know how to avoid
packet loops by some mechanism they choose to implement. Now, as far as
"sbridges" are concerned, the network consisting of RBridges, STP-running
bridges, physical links etc., is simply a "link". In other words, the entire
network (consisting of RBridges, STP-running bridges, physical links etc.)
could be replaced by a physical link. Thus even in this case, there would be
no packet loop in the steady state.

Another way of looking at this argument is the following. Suppose you remove
all the RBridges from the network. sBridges and legacy bridges are left, and
the assumption is that in that case, at least, a loop-free network results.
Then when you add RBridges (in their original position), the rest of the
network is simply one or more "link"s, and RBridges would ensure that there
would be no loops.

Do you have an example in mind where the previous scenario
(sbridges+rBridges) may end up in creating a loop?

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 11:34:28 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 974

> My 2cents: if Rbridges scope is indeed a campus, then Radia's claims
> hold...there is no advantage in having Rbridges meddling with legacy
> stuff. Now, if Rbridges is intended to be applied to other 
> fields, e.g.,
> MAN scope, then yes, legacy is an issue.

  The protocols do not know how they are being applied. They are either
mathematically correct or not so I assume you are either talking about
scale or migration? 
 
> I do not see the second case happening particularly because there are
> other issues (besides the legacy interworking) that would require
> additional work in Rbridges. So I quite frankly do not see 
> the point in
> prolonging this discussion either. 

  The point in discussing these issues is to find answers to them in
this
forum before the same issues make their way into a much larger audience.
It is very hard to stop negative opinions or incorrect ones concerning 
technology once they reach a larger less informed audience.

  Peter

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 17 Oct 2005 11:21:51 -0400
Organization: University of Pennsylvania
Subject: [rbridge] FW:  Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1199

Now you can have an rbridge and an sbridge in the same L2 (how do you
know you don't?). They form an undetectable, uncorrectable loop.

[Saikat] I do not see how this happens. First I am assuming that if
"sbridges" are connected by physical links, then they know how to avoid
packet loops by some mechanism they choose to implement. Now, as far as
"sbridges" are concerned, the network consisting of RBridges, STP-running
bridges, physical links etc., is simply a "link". In other words, the entire
network (consisting of RBridges, STP-running bridges, physical links etc.)
could be replaced by a physical link. Thus even in this case, there would be
no packet loop in the steady state.

Another way of looking at this argument is the following. Suppose you remove
all the RBridges from the network. sBridges and legacy bridges are left, and
the assumption is that in that case, at least, a loop-free network results.
Then when you add RBridges (in their original position), the rest of the
network is simply one or more "link"s, and RBridges would ensure that there
would be no loops.

Do you have an example in mind where the previous scenario
(sbridges+rBridges) may end up in creating a loop?

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 11:12:29 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1338

> >   Also, the 'problems' that people are attributing to 
> blocking and not 
> > processing BPDUs [BLOCK] are also 'problems' when no STP is running.
> 
> 'problems'? (why the quotes?)

  Because I don't see them and did not want people to think I did.
 
> OK, let's just shut off spanning tree in bridges and it all 
> works just fine now?
> 
> Now I'm *really* confused.

  Sorry, my explaination was not very clear. I was simply pointing out
that
the Rbridge DR mechanism avoids loops independently of the STP protocol.
Therefore, if there are no loops PRIOR to the introduction of the
rbridges
and their interconnections, but there is a loop AFTER their introduction
the
rbridges will detect and prevent it. In otherwords they detect and
prevent
loops for which they are responsible.

> If we want to say "BLOCK *MAY* work, but *MAY* silently 
> fail", and "PARTICIPATE and TRANSPARENT will always work with 
> current standards", that's fine (and, AFAICT, true), but I 
> also don't see how we pick BLOCK as a default in that case.

  I'd like to see the example of BLOCK failing and by failing I
mean a permanent loop uncorrected by either STP or Rbridge. Personally
I don't think this exists because the simple 'proof' of interconnecting
two
trees with a single link still being a tree seems pretty air tight to
me!

  Peter

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 17:09:14 +0200
From: "Sofia, Rute" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1213

> > b) there are scary dependencies between bridge spanning tree 
> > and RBridges algorithms
> 
>   Yeah no kidding. 
> 
> > c) no advantage as far as I can see. I don't know why we are 
> > discussing this.
> 
>   Well there are still a few folks on this list that are not 
> convinced of a) or b). There are probably 100 more on the list
> that are just quietly listening that also don't understand.
> We are very likely to encounter these opinions over and over 
> again and the best approach is to discuss and counter them 
> and capture it for future reference. Otherwise we are going 
> to see these same arguments over and over again and used as
> 'reasons' why Rbridge is 'not as good as X or Y'.
> 

My 2cents: if Rbridges scope is indeed a campus, then Radia's claims
hold...there is no advantage in having Rbridges meddling with legacy
stuff. Now, if Rbridges is intended to be applied to other fields, e.g.,
MAN scope, then yes, legacy is an issue.

I do not see the second case happening particularly because there are
other issues (besides the legacy interworking) that would require
additional work in Rbridges. So I quite frankly do not see the point in
prolonging this discussion either. 

So, 

Date: Mon, 17 Oct 2005 20:30:01 +0530
From: Ganesh CS <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5733

Hi Radia,

[email-masked] wrote:

>Yes, the intention is to do optimized distribution of IP-based multicast
>by using
>a) per-ingress Rbridge tree, and
>  
>
Do you mean (ingress Rbridge, group) instead of (source, group) ?

>b) filtering of that tree based on snooping on IGMP
>  
>
IGMP snooping is not applicable for IP subnet based broadcasts. 
Alternately will be based on host information ?

-Ganesh

>Radia
>
>----- Original Message -----
>From: Ganesh CS <[email-masked]>
>Date: Monday, October 17, 2005 6:14 am
>Subject: Re: [rbridge] Treating broadcast addresses
>
>  
>
>>What about IP subnet based broadcasts, how will they be supported 
>>by 
>>rbridges ?
>>Will it be more on lines of subnet based multicast instead of 
>>broadcast 
>>in rbridge network ?
>>
>>-Ganesh
>>
>>Vishwas Manral wrote:
>>
>>    
>>
>>>Hi Rute,
>>>
>>> 
>>>
>>>Thanks for the reply. I am clearer now.
>>>
>>> 
>>>
>>>If the root election is done at run time (like DR election in IS-
>>>      
>>>
>>IS), 
>>    
>>
>>>it could mean that the Root could change often. If we had a 
>>>      
>>>
>>sticky 
>>    
>>
>>>Root election (like a DR election in OSPF) it could mean that the 
>>>      
>>>
>>root 
>>    
>>
>>>selection would take time to converge.
>>>
>>> 
>>>
>>>Thanks again,
>>>
>>>Vishwas
>>>
>>>------------------------------------------------------------------
>>>      
>>>
>>------
>>    
>>
>>>*From:* [email-masked] [[email-masked]] 
>>>*On Behalf Of *Sofia, Rute
>>>*Sent:* Monday, October 17, 2005 5:23 PM
>>>*To:* Developing a hybrid router/bridge.
>>>*Subject:* Re: [rbridge] Treating broadcast addresses
>>>
>>> 
>>>
>>>Vishwas,
>>>
>>> 
>>>
>>>Suppose you are speaking about the ST that Rbridges use to 
>>>      
>>>
>>perform 
>>    
>>
>>>broadcast. You don't need root election: the info provided by 
>>>      
>>>
>>LSPs is 
>>    
>>
>>>enough to build the ST.
>>>
>>> 
>>>
>>>Regards,
>>>
>>>Rute
>>>
>>> 
>>>
>>>     
>>>
>>>    --------------------------------------------------------------
>>>      
>>>
>>----------
>>    
>>
>>>    *From:* [email-masked]
>>>    [[email-masked]] *On Behalf Of *Vishwas Manral
>>>    *Sent:* Monday, October 17, 2005 1:27 PM
>>>    *To:* Developing a hybrid router/bridge.
>>>    *Subject:* Re: [rbridge] Treating broadcast addresses
>>>
>>>    Hi Rute,
>>>
>>>     
>>>
>>>    Would this also mean Root-Election? What about convergence of 
>>>      
>>>
>>this>     tree?
>>    
>>
>>>     
>>>
>>>    Thanks,
>>>
>>>    Vishwas
>>>
>>>    --------------------------------------------------------------
>>>      
>>>
>>----------
>>    
>>
>>>    *From:* [email-masked]
>>>    [[email-masked]] *On Behalf Of *Sofia, Rute
>>>    *Sent:* Monday, October 17, 2005 4:36 PM
>>>    *To:* Developing a hybrid router/bridge.
>>>    *Subject:* Re: [rbridge] Treating broadcast addresses
>>>
>>>     
>>>
>>>    Vishwas,
>>>
>>>     
>>>
>>>    based on the information exchanged by LSPs you can simply 
>>>      
>>>
>>compute>     the ST locally. The key here is the choice of the 
>>root. This can
>>    
>>
>>>    also be passed along by IS-IS...
>>>
>>>     
>>>
>>>    Regards,
>>>
>>>    Rute
>>>
>>>     
>>>
>>>        Hi,
>>>
>>>         
>>>
>>>        My question is more like, how would we build a spanning tree
>>>        for broadcast using IS-IS?
>>>
>>>         
>>>
>>>        We need a globally coordinated tree like STP and not like 
>>>      
>>>
>>the>         way IS-IS computes it. Would we require, changes to the
>>    
>>
>>>        spanning tree computation itself?
>>>
>>>         
>>>
>>>        Thanks,
>>>
>>>        Vishwas
>>>
>>>        ----------------------------------------------------------
>>>      
>>>
>>--------------
>>    
>>
>>>        *From:* [email-masked]
>>>        [[email-masked]] *On Behalf Of *Vishwas Manral
>>>        *Sent:* Monday, October 17, 2005 11:41 AM
>>>        *To:* Developing a hybrid router/bridge.
>>>        *Subject:* [rbridge] Treating broadcast addresses
>>>
>>>         
>>>
>>>        Hi,
>>>
>>>         
>>>
>>>        I had a doubt about treatment of broadcast addresses.
>>>
>>>         
>>>
>>>        Currently using STP we have one tree and ports are blocked/
>>>        forwarding, so packets cannot loop irrespective of 
>>>      
>>>
>>destination>         addresses. In IS-IS protocol, we use ports 
>>based on
>>    
>>
>>>        destination address and no ports are blocked or 
>>>      
>>>
>>unblocked. But
>>    
>>
>>>        if the destination address is FF-FF-FF-FF-FF-FF we could end
>>>        in a forwarding loop. How would we get over it?
>>>
>>>         
>>>
>>>        Would we still allow broadcast destination address 
>>>      
>>>
>>packets to
>>    
>>
>>>        be forwarded? It is like preventing flooding loops in a case
>>>        where we have a global broadcast IP address, which is
>>>        forwarded to all attached routers. Am I missing the point 
>>>      
>>>
>>all>         together?
>>    
>>
>>>         
>>>
>>>        Thanks,
>>>
>>>        Vishwas
>>>
>>>         
>>>
>>>-------------------------------------------------------------------
>>>      
>>>
>>-----
>>    
>>
>>>[email-masked]
>>[email-masked]
>[email-masked]

Date: Mon, 17 Oct 2005 07:51:01 -0700
From: [email-masked]
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Priority: normal
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 6490

The simplest thing would just be to have RBridges send hellos fairly often all the time.
It would be a parameter, so people could set it.

One could use hints like topology change flags, but I'm not sure how helpful that
would be. It wouldn't hurt, but I don't think there would be that much overhead to
having hellos every, say, second.

Radia

----- Original Message -----
From: Saikat Ray <[email-masked]>
Date: Monday, October 17, 2005 6:46 am
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread

> First of all, I totally agree with you that there should be 
> multiple small
> spanning trees glued by RBridge networks instead of a global huge 
> spanningtree. My point was slightly different, though. In the 
> mechanism you pointed
> out (hearing hallos from other RBridges), the amount of time a 
> temporaryloop persists would depend on the time interval between 
> hallo messages sent
> by RBridges (what is the default value?). If two RBridges are 
> connected by a
> physical link, then this is probably the only way the RBridges can 
> detectthe loop. However, if the underlying "link" is actually a 
> bridged network
> (spanning tree), then the RBridges would have more information. For 
> example,when RBridges see topology change BPDU's (or something 
> similar), then they
> may deduct the possibility of a loop formation and they may 
> increase the
> sending rate of hallo messages. In short, the RBridges are 
> privileged to be
> in a position to make additional observations (BPDUs) and, in my 
> humbleopinion, they ought to use it.
> 
> From: Radia Perlman [[email-masked]] 
> Sent: Sunday, October 16, 2005 8:46 PM
> To: [email-masked]; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Time to summarize "forward or block" BPDU 
> thread
> The scenario you mention is where there is temporarily two 
> Designated 
> RBridges (DRs), because
> two links were merged.
> 
> The DRs will notice this when they start seeing each other's IS-IS 
> Hello 
> messages, and that
> will break the loop.
> 
> I don't think this case is that much of a problem, and certainly 
> would 
> not be helped by trying to run a big
> global spanning tree. The big global spanning tree would converge 
> much 
> slower than the RBridge
> DR election protocol would. So attempting to avoid a temporary loop 
> when 
> two bridged domains
> are merged, by running a big global instance
> of the spanning tree algorithm, will not solve the problem, and 
> will 
> actually
> make things worse.
> 
> Radia
> 
> 
> 
> 
> Saikat Ray wrote:
> 
> >It is probably a standard scenario in IS-IS protocol (and 
> consequently a
> >standard solution is known), but I was thinking that if the RBridges
> >disregards BPDUs entirely, then in some situations loops may form 
> for some
> >period. For example, suppose $T_1$ and $T_2$ are disjoint trees 
> formed>entirely by legacy elements. $R_1$ and $R_2$ are the 
> designated RBridges
> for
> >the "links" $T_1$ and $T_2$, respectively. At this point, there is 
> no loop
> >in the system. Now suppose that a physical link (or a legacy 
> bridge) is
> >added that connects a legacy bridge of $T_1$ to a legacy bridge of 
> $T_2$.>This addition will trigger a new Spanning tree computation, 
> which will
> >result into a single spanning tree that spans the nodes of $T_1$ 
> and $T_2$.
> >At this point, effectively the RBridges $R_1$ and $R_2$ are 
> connected by a
> >single "link" and until one of the RBridge gets "de-designated", 
> therewould
> >exist a loop. Two questions arise in my mind: (i) how fast would that
> >"de-designation" process be? And (ii) would it be useful (i.e. 
> would it
> >accelerate the convergence) if RBridges "listen" to the BPDUs?
> >
> >From: [email-masked] [[email-masked]] On
> >Behalf Of Radia Perlman
> >Sent: Sunday, October 16, 2005 7:12 PM
> >Subject: [rbridge] Time to summarize "forward or block" BPDU thread
> >
> >It looks like this thread was discussed with two different subject 
> >lines, and it's also
> >gone on long enough it's time for someone to summarize it.
> >
> >I strongly believe that things will be more stable if RBridges do 
> NOT 
> >forward BPDUs...that
> >we decouple the protocols.
> >
> >That TRILL is kind of like a layer between bridging and routing.
> >
> >If RBridges do not forward BPDUs, then whether or not the TRILL 
> link 
> >state protocol is
> >converged, it won't affect the little spanning tree inside a 
> particular 
> >bridged segment.
> >
> >That way, the little spanning trees will converge as quickly as 
> possible 
> >(because it's small),
> >and cannot possibly be disrupted by RBridges wormholing BPDUs.
> >
> >I do not understand the reasons why people want to forward BPDUs. 
> I 
> >think the arguments (which
> >I may not be presenting fairly because I don't understand them) are:
> >a) you'll get a more optimal combined spanning tree on which 
> >unknown/broadcast frames will
> >be sent if it is one global spanning tree, rather than little 
> >independent spanning trees hooked together
> >by the independently computed spanning tree calculated by IS-IS.
> >b) forwarding BPDUs, and having a global spanning tree, will 
> prevent loops.
> >
> >I strongly disagree with both those arguments. For a) What do 
> people 
> >think is more optimal about a tree
> >computed that way vs having independent trees inside each bridged 
> >island? And besides, there isn't
> >a single spanning tree...it's a spanning tree per ingress RBridge.
> >For b) no...I believe that having both the RBridge algorithm and 
> the 
> >bridge algorithm feeding into
> >each other will create much slower convergence.
> >
> >If I haven't summarized correctly, then someone else can try to 
> capture 
> >the arguments, but I do
> >think we should merge discussion under one subject line, and 
> restart 
> >with a summary.
> >
> >Radia
> >
> >[email-masked]
> >[email-masked]
> [email-masked]

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 10:50:11 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 870

> With forwarding, or sometimes forwarding based on 
> configuration (I'm not sure what people are
> proposing:
> 
> a) things will converge much more slowly
  
  Agreed. 
> 
> b) there are scary dependencies between bridge spanning tree 
> and RBridges algorithms

  Yeah no kidding. 

> c) no advantage as far as I can see. I don't know why we are 
> discussing this.

  Well there are still a few folks on this list that are not 
convinced of a) or b). There are probably 100 more on the list
that are just quietly listening that also don't understand.
We are very likely to encounter these opinions over and over 
again and the best approach is to discuss and counter them 
and capture it for future reference. Otherwise we are going 
to see these same arguments over and over again and used as
'reasons' why Rbridge is 'not as good as X or Y'.

  Peter

> Radia

Date: Mon, 17 Oct 2005 07:46:31 -0700
From: [email-masked]
To: "Developing a hybrid router/bridge." <[email-masked]>
Priority: normal
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2365

This is a multi-part message in MIME format.

--Boundary_(ID_qwWvcjcclrlXyJhYW77pvw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

Actually, the explanation of how RBridges would work on a technical level was
in the original draft. I thought it was just being broken into "architecture"
and "technical", which would mean things wouldn't change.

RBridges detect each other the same way routers detect each other. Through
Hello messages, which get sent on a "link", which can be formed
by whatever technology. One possible technology is bridged Ethernet.

RBridges assume that the underlying link works the way it always did...to create
a cloud on which any other RBridges connected to the cloud are fully connected.

RBridges do not require changes on the underlying link.

If people would think of it as a layer above, just like routers are, perhaps it would be less confusing.

And RBridges also form a layer BELOW routers, so they are transparent to routers, and make
no demands on IP nodes to change the way they work.

Radia

--Boundary_(ID_qwWvcjcclrlXyJhYW77pvw)
Content-type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="==========AD867A26ABED09D99B9B=========="

--==========AD867A26ABED09D99B9B==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 17. oktober 2005 05:17 -0700 Joe Touch <[email-masked]> wrote:

> WHEN (note the use of 'when', not 'if', since there's *nothing* that can
> be done to enforce this) this isn't the case, the following problems
> arise:
>
> 	a) there is no way to detect the error
>
> 	b) loops *will* occur

You know, I really can't tell whether this is true or not without looking=20
at the protocol specification that says how the RBridges detect each other.

Should this discussion wait for the drafts to come out?

                 Harald

--==========AD867A26ABED09D99B9B==========--

--Boundary_(ID_qwWvcjcclrlXyJhYW77pvw)
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

[email-masked]

--Boundary_(ID_qwWvcjcclrlXyJhYW77pvw)--

Date: Mon, 17 Oct 2005 07:42:45 -0700
From: [email-masked]
To: "Developing a hybrid router/bridge." <[email-masked]>
Priority: normal
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2106

This is a multi-part message in MIME format.

--Boundary_(ID_9J1K6qLHycqPNEQ0IJSIng)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

It works perfectly well if RBridges block. It isolates the bridge islands.

Routers also block bridge spanning tree, and to exactly the same
effect as if RBridges block BPDUs.

There is no interdependency if they block.

THere IS interdependency if RBridges forward BPDUs.

Radia

--Boundary_(ID_9J1K6qLHycqPNEQ0IJSIng)
Content-type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary=------------enig81AB87D6717B80F53ED954EF

--------------enig81AB87D6717B80F53ED954EF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Saikat Ray wrote:
> AFAICT, this all works when there is at most one rbridge campus in an L2.
> 
> [Saikat] I think that the assumption (definition) is that if two RBridges
> are connected directly (i.e. no IP router in between), then they are parts
> of a single campus, thus must talk to each other. If that is true, then how
> would you have more than one campuses that are not separated by an IP
> router?

You won't - the rbridge campuses will merge.

But we're the IETF, and we're making 'rbridges', which will BLOCK.

Let's say the IEEE decides to allow another group to make 'sbridges',
which also decide to BLOCK.

Now you can have an rbridge and an sbridge in the same L2 (how do you
know you don't?). They form an undetectable, uncorrectable loop.

--

I.e. - this all works only if everyone plays by OUR rules. Since we're
NOT the IEEE, how is it that we can decide to create a protocol that
relies on us being the ONLY exception?

Joe

--------------enig81AB87D6717B80F53ED954EF--

--Boundary_(ID_9J1K6qLHycqPNEQ0IJSIng)
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

[email-masked]

--Boundary_(ID_9J1K6qLHycqPNEQ0IJSIng)--

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 10:42:30 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 632

> As someone trying to write the drafts, I'm trying to 
> understand the terminology that will determine this.
> 
> I have a MUCH better idea of how to explain things now - 
> whether I agree with them at all levels or not, so this 
> discussion IS helping, FWIW.

  It is worthwhile to include alternatives you don't agree with in
the very early drafts. Give them a paragraph, describe them briefly etc.
This forces either solutions, demonstrations of incorrectness, 
demonstrations of correctness etc. all of which can also be incorporated
to avoid repeatedly revisiting those things that either work or don't 
work. 

  Peter

Date: Mon, 17 Oct 2005 16:39:28 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3090

Joe Touch wrote:

>Guillermo Ib??ez wrote:
>  
>
>>I agree completely with Radia and I would add three more arguments in 
>>favour of Rbridge protocol separation from spanning tree protocols:
>>- If Rbridges are succesful, the bridges spanning trees will be legacy 
>>in the long term, or will tend to be excluded from the core of the 
>>campus network due to its much lower performance in terms of congestion, 
>>path length and  infrastructure usage.
>>    
>>
>
>rbridges still rely on spanning trees at the edge; otherwise, we're
>limited to 'make sure you don't wire things in a ring' like we are with
>hubs.
>
>further, rbridges still rely on bridges as transits in the core.
>
>  
>
Sorry, I agree on both sentences, but I do not understand the argument.

>>- Coordination of the Rbridges protocol is not with one ST protocol but 
>>with TWO spanning tree protocols: STP (legacy, and slow) and RSTP 
>>(standard, faster). They have different mechanisms for convergence: wait 
>>a timer long enough to converge and  "wavefront" enabling of ports 
>>downstream from the root bridge  respectively. There is also a limit on 
>>the maximum diameter of spanning trees (related with the timer use) that 
>>should be taken into account by those in favour of big size spanning trees.
>>    
>>
>
>  
>
>>-Rbridges will be standardized by IETF, RSTP is under IEEE control. The 
>>risk of separate evolution exists. Although coordination IEEE-IETF 
>>works, it is better not to create  interdependencies if they can be avoided.
>>Guillermo
>>    
>>
>
>That's a good reason NOT to assume the IETF can force only one system on
>an L2 to be privileged and be allowed to BLOCK.
>  
>
(I copy here my previous message on the PARTICIPATE ROLE)

Sorry, I did not follow the whole discussion on the BLOCK / TRANSPARENT / PARTICIPATE. My understanding 
 is that rbridges can participate in the spanning tree they are attached to but 
do not forward BPDUs. Each port emits BPDUs based solely on its port 
information, opposite to the standard  stp operation ,  where the bridge 
builds the BPDUs to be transmitted  based on information collected from 
all bridge ports and selecting the best BPDU, thus containing the distance 
to root bridge. I would call this mode PARTICIPATE PER PORT.
Rbridge ports should announce themselves as designated ports of  Rbridge 
(IS-IS Designated Bridge acting as STP root bridge). The Rbridge ports will be in role Designated if they win the 
competition for the link or in Back-Up or Alternate role (that means 
blocked) if they lost the competition of best BPDU heard in the local 
link.  They would never be in  Root port role.
Regarding BLOCK, it seems to be a decision of the network administrator, like when deciding not to enable spanning tree protocol ( I did not follow the discussion, may be I miss the point).
Guillermo

>Joe
>
>  
>
>------------------------------------------------------------------------
>
>[email-masked]

Date: Mon, 17 Oct 2005 07:32:04 -0700
From: [email-masked]
To: "Developing a hybrid router/bridge." <[email-masked]>
Priority: normal
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2588

This is a multi-part message in MIME format.

--Boundary_(ID_GwG7c5uDJmaiCG66SFNhTA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

We pick block because things will converge much more quickly.

With blocking:

The spanning tree domains are smaller, and therefore will converge more quickly.

There is no feedback between the RBridge algorithm wormholing BPDUs into random places
within a spanning tree, confusing the spanning tree convergence.

*******
With forwarding, or sometimes forwarding based on configuration (I'm not sure what people are
proposing:

a) things will converge much more slowly

b) there are scary dependencies between bridge spanning tree and RBridges algorithms

c) no advantage as far as I can see. I don't know why we are discussing this.

Radia

--Boundary_(ID_GwG7c5uDJmaiCG66SFNhTA)
Content-type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary=------------enig6DDB1E9D7A4186DB999B949C

--------------enig6DDB1E9D7A4186DB999B949C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Ashwood-Smith wrote:
>   This lack of understanding of the DRs seems to be the cause of a lot
> of this debate. 

IMO, it's the belief that there will only ever be one DR or DR-like
(BLOCKing) device. I agree that this all works when it works.

>   Also, the 'problems' that people are attributing to blocking and not
> processing BPDUs [BLOCK] are also 'problems' when no STP is running.

'problems'? (why the quotes?)

OK, let's just shut off spanning tree in bridges and it all works just
fine now?

Now I'm *really* confused.

AFAICT, this all works when there is at most one rbridge campus in an L2.

WHEN (note the use of 'when', not 'if', since there's *nothing* that can
be done to enforce this) this isn't the case, the following problems arise:

	a) there is no way to detect the error

	b) loops *will* occur

If we want to say "BLOCK *MAY* work, but *MAY* silently fail", and
"PARTICIPATE and TRANSPARENT will always work with current standards",
that's fine (and, AFAICT, true), but I also don't see how we pick BLOCK
as a default in that case.

Joe

--------------enig6DDB1E9D7A4186DB999B949C--

--Boundary_(ID_GwG7c5uDJmaiCG66SFNhTA)
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

[email-masked]

--Boundary_(ID_GwG7c5uDJmaiCG66SFNhTA)--

Date: Mon, 17 Oct 2005 07:27:09 -0700
From: [email-masked]
To: "Developing a hybrid router/bridge." <[email-masked]>
Priority: normal
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5003

Yes, the intention is to do optimized distribution of IP-based multicast
by using
a) per-ingress Rbridge tree, and
b) filtering of that tree based on snooping on IGMP

Radia

----- Original Message -----
From: Ganesh CS <[email-masked]>
Date: Monday, October 17, 2005 6:14 am
Subject: Re: [rbridge] Treating broadcast addresses

> What about IP subnet based broadcasts, how will they be supported 
> by 
> rbridges ?
> Will it be more on lines of subnet based multicast instead of 
> broadcast 
> in rbridge network ?
> 
> -Ganesh
> 
> Vishwas Manral wrote:
> 
> > Hi Rute,
> >
> >  
> >
> > Thanks for the reply. I am clearer now.
> >
> >  
> >
> > If the root election is done at run time (like DR election in IS-
> IS), 
> > it could mean that the Root could change often. If we had a 
> sticky 
> > Root election (like a DR election in OSPF) it could mean that the 
> root 
> > selection would take time to converge.
> >
> >  
> >
> > Thanks again,
> >
> > Vishwas
> >
> > ------------------------------------------------------------------
> ------
> >
> > *From:* [email-masked] [[email-masked]] 
> > *On Behalf Of *Sofia, Rute
> > *Sent:* Monday, October 17, 2005 5:23 PM
> > *To:* Developing a hybrid router/bridge.
> > *Subject:* Re: [rbridge] Treating broadcast addresses
> >
> >  
> >
> > Vishwas,
> >
> >  
> >
> > Suppose you are speaking about the ST that Rbridges use to 
> perform 
> > broadcast. You don't need root election: the info provided by 
> LSPs is 
> > enough to build the ST.
> >
> >  
> >
> > Regards,
> >
> > Rute
> >
> >  
> >
> >      
> >
> >     --------------------------------------------------------------
> ----------
> >
> >     *From:* [email-masked]
> >     [[email-masked]] *On Behalf Of *Vishwas Manral
> >     *Sent:* Monday, October 17, 2005 1:27 PM
> >     *To:* Developing a hybrid router/bridge.
> >     *Subject:* Re: [rbridge] Treating broadcast addresses
> >
> >     Hi Rute,
> >
> >      
> >
> >     Would this also mean Root-Election? What about convergence of 
> this>     tree?
> >
> >      
> >
> >     Thanks,
> >
> >     Vishwas
> >
> >     --------------------------------------------------------------
> ----------
> >
> >     *From:* [email-masked]
> >     [[email-masked]] *On Behalf Of *Sofia, Rute
> >     *Sent:* Monday, October 17, 2005 4:36 PM
> >     *To:* Developing a hybrid router/bridge.
> >     *Subject:* Re: [rbridge] Treating broadcast addresses
> >
> >      
> >
> >     Vishwas,
> >
> >      
> >
> >     based on the information exchanged by LSPs you can simply 
> compute>     the ST locally. The key here is the choice of the 
> root. This can
> >     also be passed along by IS-IS...
> >
> >      
> >
> >     Regards,
> >
> >     Rute
> >
> >      
> >
> >         Hi,
> >
> >          
> >
> >         My question is more like, how would we build a spanning tree
> >         for broadcast using IS-IS?
> >
> >          
> >
> >         We need a globally coordinated tree like STP and not like 
> the>         way IS-IS computes it. Would we require, changes to the
> >         spanning tree computation itself?
> >
> >          
> >
> >         Thanks,
> >
> >         Vishwas
> >
> >         ----------------------------------------------------------
> --------------
> >
> >         *From:* [email-masked]
> >         [[email-masked]] *On Behalf Of *Vishwas Manral
> >         *Sent:* Monday, October 17, 2005 11:41 AM
> >         *To:* Developing a hybrid router/bridge.
> >         *Subject:* [rbridge] Treating broadcast addresses
> >
> >          
> >
> >         Hi,
> >
> >          
> >
> >         I had a doubt about treatment of broadcast addresses.
> >
> >          
> >
> >         Currently using STP we have one tree and ports are blocked/
> >         forwarding, so packets cannot loop irrespective of 
> destination>         addresses. In IS-IS protocol, we use ports 
> based on
> >         destination address and no ports are blocked or 
> unblocked. But
> >         if the destination address is FF-FF-FF-FF-FF-FF we could end
> >         in a forwarding loop. How would we get over it?
> >
> >          
> >
> >         Would we still allow broadcast destination address 
> packets to
> >         be forwarded? It is like preventing flooding loops in a case
> >         where we have a global broadcast IP address, which is
> >         forwarded to all attached routers. Am I missing the point 
> all>         together?
> >
> >          
> >
> >         Thanks,
> >
> >         Vishwas
> >
> >          
> >
> >-------------------------------------------------------------------
> -----
> >
> >[email-masked]
> [email-masked]

Date: Mon, 17 Oct 2005 07:26:40 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1520

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig65AC83E92982DC8888EE3ACC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Harald Tveit Alvestrand wrote:
> 
> 
> --On 17. oktober 2005 05:17 -0700 Joe Touch <[email-masked]> wrote:
> 
>> WHEN (note the use of 'when', not 'if', since there's *nothing* that can
>> be done to enforce this) this isn't the case, the following problems
>> arise:
>>
>>     a) there is no way to detect the error
>>
>>     b) loops *will* occur
> 
> 
> You know, I really can't tell whether this is true or not without
> looking at the protocol specification that says how the RBridges detect
> each other.
> 
> Should this discussion wait for the drafts to come out?

As someone trying to write the drafts, I'm trying to understand the
terminology that will determine this.

I have a MUCH better idea of how to explain things now - whether I agree
with them at all levels or not, so this discussion IS helping, FWIW.

Joe

--------------enig65AC83E92982DC8888EE3ACC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig65AC83E92982DC8888EE3ACC--

Date: Mon, 17 Oct 2005 07:22:17 -0700
From: Joe Touch <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1642

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig81AB87D6717B80F53ED954EF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Saikat Ray wrote:
> AFAICT, this all works when there is at most one rbridge campus in an L2.
> 
> [Saikat] I think that the assumption (definition) is that if two RBridges
> are connected directly (i.e. no IP router in between), then they are parts
> of a single campus, thus must talk to each other. If that is true, then how
> would you have more than one campuses that are not separated by an IP
> router?

You won't - the rbridge campuses will merge.

But we're the IETF, and we're making 'rbridges', which will BLOCK.

Let's say the IEEE decides to allow another group to make 'sbridges',
which also decide to BLOCK.

Now you can have an rbridge and an sbridge in the same L2 (how do you
know you don't?). They form an undetectable, uncorrectable loop.

--

I.e. - this all works only if everyone plays by OUR rules. Since we're
NOT the IEEE, how is it that we can decide to create a protocol that
relies on us being the ONLY exception?

Joe

--------------enig81AB87D6717B80F53ED954EF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig81AB87D6717B80F53ED954EF--

Date: Mon, 17 Oct 2005 16:05:08 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1060

--==========AD867A26ABED09D99B9B==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 17. oktober 2005 05:17 -0700 Joe Touch <[email-masked]> wrote:

> WHEN (note the use of 'when', not 'if', since there's *nothing* that can
> be done to enforce this) this isn't the case, the following problems
> arise:
>
> 	a) there is no way to detect the error
>
> 	b) loops *will* occur

You know, I really can't tell whether this is true or not without looking=20
at the protocol specification that says how the RBridges detect each other.

Should this discussion wait for the drafts to come out?

                 Harald

--==========AD867A26ABED09D99B9B==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========AD867A26ABED09D99B9B==========--

Date: Mon, 17 Oct 2005 07:18:42 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2276

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4F276645051F73836010D8E8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Guillermo Ib=E1=F1ez wrote:
> I agree completely with Radia and I would add three more arguments in=20
> favour of Rbridge protocol separation from spanning tree protocols:
> - If Rbridges are succesful, the bridges spanning trees will be legacy =

> in the long term, or will tend to be excluded from the core of the=20
> campus network due to its much lower performance in terms of congestion=
,=20
> path length and  infrastructure usage.

rbridges still rely on spanning trees at the edge; otherwise, we're
limited to 'make sure you don't wire things in a ring' like we are with
hubs.

further, rbridges still rely on bridges as transits in the core.

> - Coordination of the Rbridges protocol is not with one ST protocol but=
=20
> with TWO spanning tree protocols: STP (legacy, and slow) and RSTP=20
> (standard, faster). They have different mechanisms for convergence: wai=
t=20
> a timer long enough to converge and  "wavefront" enabling of ports=20
> downstream from the root bridge  respectively. There is also a limit on=
=20
> the maximum diameter of spanning trees (related with the timer use) tha=
t=20
> should be taken into account by those in favour of big size spanning tr=
ees.

> -Rbridges will be standardized by IETF, RSTP is under IEEE control. The=
=20
> risk of separate evolution exists. Although coordination IEEE-IETF=20
> works, it is better not to create  interdependencies if they can be avo=
ided.
> Guillermo

That's a good reason NOT to assume the IETF can force only one system on
an L2 to be privileged and be allowed to BLOCK.

Joe

--------------enig4F276645051F73836010D8E8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig4F276645051F73836010D8E8--

From: "Saikat Ray" <[email-masked]>
To: "'Radia Perlman'" <[email-masked]>, "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 17 Oct 2005 09:46:09 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5471

First of all, I totally agree with you that there should be multiple small
spanning trees glued by RBridge networks instead of a global huge spanning
tree. My point was slightly different, though. In the mechanism you pointed
out (hearing hallos from other RBridges), the amount of time a temporary
loop persists would depend on the time interval between hallo messages sent
by RBridges (what is the default value?). If two RBridges are connected by a
physical link, then this is probably the only way the RBridges can detect
the loop. However, if the underlying "link" is actually a bridged network
(spanning tree), then the RBridges would have more information. For example,
when RBridges see topology change BPDU's (or something similar), then they
may deduct the possibility of a loop formation and they may increase the
sending rate of hallo messages. In short, the RBridges are privileged to be
in a position to make additional observations (BPDUs) and, in my humble
opinion, they ought to use it.

-----Original Message-----
From: Radia Perlman [mailto:[email-masked]] 
Sent: Sunday, October 16, 2005 8:46 PM
To: [email-masked]; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread

The scenario you mention is where there is temporarily two Designated 
RBridges (DRs), because
two links were merged.

The DRs will notice this when they start seeing each other's IS-IS Hello 
messages, and that
will break the loop.

I don't think this case is that much of a problem, and certainly would 
not be helped by trying to run a big
global spanning tree. The big global spanning tree would converge much 
slower than the RBridge
DR election protocol would. So attempting to avoid a temporary loop when 
two bridged domains
are merged, by running a big global instance
of the spanning tree algorithm, will not solve the problem, and will 
actually
make things worse.

Radia

Saikat Ray wrote:

>It is probably a standard scenario in IS-IS protocol (and consequently a
>standard solution is known), but I was thinking that if the RBridges
>disregards BPDUs entirely, then in some situations loops may form for some
>period. For example, suppose $T_1$ and $T_2$ are disjoint trees formed
>entirely by legacy elements. $R_1$ and $R_2$ are the designated RBridges
for
>the "links" $T_1$ and $T_2$, respectively. At this point, there is no loop
>in the system. Now suppose that a physical link (or a legacy bridge) is
>added that connects a legacy bridge of $T_1$ to a legacy bridge of $T_2$.
>This addition will trigger a new Spanning tree computation, which will
>result into a single spanning tree that spans the nodes of $T_1$ and $T_2$.
>At this point, effectively the RBridges $R_1$ and $R_2$ are connected by a
>single "link" and until one of the RBridge gets "de-designated", there
would
>exist a loop. Two questions arise in my mind: (i) how fast would that
>"de-designation" process be? And (ii) would it be useful (i.e. would it
>accelerate the convergence) if RBridges "listen" to the BPDUs?
>
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Radia Perlman
>Sent: Sunday, October 16, 2005 7:12 PM
>Subject: [rbridge] Time to summarize "forward or block" BPDU thread
>
>It looks like this thread was discussed with two different subject 
>lines, and it's also
>gone on long enough it's time for someone to summarize it.
>
>I strongly believe that things will be more stable if RBridges do NOT 
>forward BPDUs...that
>we decouple the protocols.
>
>That TRILL is kind of like a layer between bridging and routing.
>
>If RBridges do not forward BPDUs, then whether or not the TRILL link 
>state protocol is
>converged, it won't affect the little spanning tree inside a particular 
>bridged segment.
>
>That way, the little spanning trees will converge as quickly as possible 
>(because it's small),
>and cannot possibly be disrupted by RBridges wormholing BPDUs.
>
>I do not understand the reasons why people want to forward BPDUs. I 
>think the arguments (which
>I may not be presenting fairly because I don't understand them) are:
>a) you'll get a more optimal combined spanning tree on which 
>unknown/broadcast frames will
>be sent if it is one global spanning tree, rather than little 
>independent spanning trees hooked together
>by the independently computed spanning tree calculated by IS-IS.
>b) forwarding BPDUs, and having a global spanning tree, will prevent loops.
>
>I strongly disagree with both those arguments. For a) What do people 
>think is more optimal about a tree
>computed that way vs having independent trees inside each bridged 
>island? And besides, there isn't
>a single spanning tree...it's a spanning tree per ingress RBridge.
>For b) no...I believe that having both the RBridge algorithm and the 
>bridge algorithm feeding into
>each other will create much slower convergence.
>
>If I haven't summarized correctly, then someone else can try to capture 
>the arguments, but I do
>think we should merge discussion under one subject line, and restart 
>with a summary.
>
>Radia
>
>[email-masked]
>[email-masked]

Date: Mon, 17 Oct 2005 18:44:48 +0530
From: Ganesh CS <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4161

What about IP subnet based broadcasts, how will they be supported by 
rbridges ?
Will it be more on lines of subnet based multicast instead of broadcast 
in rbridge network ?

-Ganesh

Vishwas Manral wrote:

> Hi Rute,
>
>  
>
> Thanks for the reply. I am clearer now.
>
>  
>
> If the root election is done at run time (like DR election in IS-IS), 
> it could mean that the Root could change often. If we had a sticky 
> Root election (like a DR election in OSPF) it could mean that the root 
> selection would take time to converge.
>
>  
>
> Thanks again,
>
> Vishwas
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] 
> *On Behalf Of *Sofia, Rute
> *Sent:* Monday, October 17, 2005 5:23 PM
> *To:* Developing a hybrid router/bridge.
> *Subject:* Re: [rbridge] Treating broadcast addresses
>
>  
>
> Vishwas,
>
>  
>
> Suppose you are speaking about the ST that Rbridges use to perform 
> broadcast. You don't need root election: the info provided by LSPs is 
> enough to build the ST.
>
>  
>
> Regards,
>
> Rute
>
>  
>
>      
>
>     ------------------------------------------------------------------------
>
>     *From:* [email-masked]
>     [mailto:[email-masked]] *On Behalf Of *Vishwas Manral
>     *Sent:* Monday, October 17, 2005 1:27 PM
>     *To:* Developing a hybrid router/bridge.
>     *Subject:* Re: [rbridge] Treating broadcast addresses
>
>     Hi Rute,
>
>      
>
>     Would this also mean Root-Election? What about convergence of this
>     tree?
>
>      
>
>     Thanks,
>
>     Vishwas
>
>     ------------------------------------------------------------------------
>
>     *From:* [email-masked]
>     [mailto:[email-masked]] *On Behalf Of *Sofia, Rute
>     *Sent:* Monday, October 17, 2005 4:36 PM
>     *To:* Developing a hybrid router/bridge.
>     *Subject:* Re: [rbridge] Treating broadcast addresses
>
>      
>
>     Vishwas,
>
>      
>
>     based on the information exchanged by LSPs you can simply compute
>     the ST locally. The key here is the choice of the root. This can
>     also be passed along by IS-IS...
>
>      
>
>     Regards,
>
>     Rute
>
>      
>
>         Hi,
>
>          
>
>         My question is more like, how would we build a spanning tree
>         for broadcast using IS-IS?
>
>          
>
>         We need a globally coordinated tree like STP and not like the
>         way IS-IS computes it. Would we require, changes to the
>         spanning tree computation itself?
>
>          
>
>         Thanks,
>
>         Vishwas
>
>         ------------------------------------------------------------------------
>
>         *From:* [email-masked]
>         [mailto:[email-masked]] *On Behalf Of *Vishwas Manral
>         *Sent:* Monday, October 17, 2005 11:41 AM
>         *To:* Developing a hybrid router/bridge.
>         *Subject:* [rbridge] Treating broadcast addresses
>
>          
>
>         Hi,
>
>          
>
>         I had a doubt about treatment of broadcast addresses.
>
>          
>
>         Currently using STP we have one tree and ports are blocked/
>         forwarding, so packets cannot loop irrespective of destination
>         addresses. In IS-IS protocol, we use ports based on
>         destination address and no ports are blocked or unblocked. But
>         if the destination address is FF-FF-FF-FF-FF-FF we could end
>         in a forwarding loop. How would we get over it?
>
>          
>
>         Would we still allow broadcast destination address packets to
>         be forwarded? It is like preventing flooding loops in a case
>         where we have a global broadcast IP address, which is
>         forwarded to all attached routers. Am I missing the point all
>         together?
>
>          
>
>         Thanks,
>
>         Vishwas
>
>          
>
>------------------------------------------------------------------------
>
>[email-masked]

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 17 Oct 2005 08:31:24 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 380

AFAICT, this all works when there is at most one rbridge campus in an L2.

[Saikat] I think that the assumption (definition) is that if two RBridges
are connected directly (i.e. no IP router in between), then they are parts
of a single campus, thus must talk to each other. If that is true, then how
would you have more than one campuses that are not separated by an IP
router?

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Mon, 17 Oct 2005 08:27:46 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2286

You do not even need a ?root? really! Each RBridge has the *global*
topology. They can simply each run Kruskal's algorithm and compute the (nee
*a*) minimum weight spanning tree (which is probably the right thing to do
anyway for broadcast purposes).

________________________________________
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vishwas Manral
Sent: Monday, October 17, 2005 7:27 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Treating broadcast addresses

Hi Rute,

Would this also mean Root-Election? What about convergence of this tree?

Thanks,
Vishwas
________________________________________
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sofia, Rute
Sent: Monday, October 17, 2005 4:36 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Treating broadcast addresses

Vishwas,
?
based on the information exchanged by LSPs you can simply compute the ST
locally. The key here is the choice of the root. This can also be passed
along by IS-IS...
?
Regards,
Rute
?
Hi,

My question is more like, how would we build a spanning tree for broadcast
using IS-IS? 

We need a globally coordinated tree like STP and not like the way IS-IS
computes it. Would we require, changes to the spanning tree computation
itself?

Thanks,
Vishwas
________________________________________
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vishwas Manral
Sent: Monday, October 17, 2005 11:41 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Treating broadcast addresses

Hi,

I had a doubt about treatment of broadcast addresses.

Currently using STP we have one tree and ports are blocked/ forwarding, so
packets cannot loop irrespective of destination addresses. In IS-IS
protocol, we use ports based on destination address and no ports are blocked
or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could
end in a forwarding loop. How would we get over it?

Would we still allow broadcast destination address packets to be forwarded?
It is like preventing flooding loops in a case where we have a global
broadcast IP address, which is forwarded to all attached routers. Am I
missing the point all together?

Thanks,
Vishwas

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 05:27:30 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 19063

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5D315.AF253BD8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Rute,

=20

Thanks for the reply. I am clearer now.

=20

If the root election is done at run time (like DR election in IS-IS), it
could mean that the Root could change often. If we had a sticky Root
election (like a DR election in OSPF) it could mean that the root
selection would take time to converge.

=20

Thanks again,

Vishwas

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sofia, Rute
Sent: Monday, October 17, 2005 5:23 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Treating broadcast addresses

=20

Vishwas,

=20

Suppose you are speaking about the ST that Rbridges use to perform
broadcast. You don't need root election: the info provided by LSPs is
enough to build the ST.

=20

Regards,

Rute

=20

	=20

=09
________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Vishwas Manral
	Sent: Monday, October 17, 2005 1:27 PM
	To: Developing a hybrid router/bridge.
	Subject: Re: [rbridge] Treating broadcast addresses

	Hi Rute,

	=20

	Would this also mean Root-Election? What about convergence of
this tree?

	=20

	Thanks,

	Vishwas

=09
________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sofia, Rute
	Sent: Monday, October 17, 2005 4:36 PM
	To: Developing a hybrid router/bridge.
	Subject: Re: [rbridge] Treating broadcast addresses

	=20

	Vishwas,

	=20

	based on the information exchanged by LSPs you can simply
compute the ST locally. The key here is the choice of the root. This can
also be passed along by IS-IS...

	=20

	Regards,

	Rute

	=20

		Hi,

		=20

		My question is more like, how would we build a spanning
tree for broadcast using IS-IS?=20

		=20

		We need a globally coordinated tree like STP and not
like the way IS-IS computes it. Would we require, changes to the
spanning tree computation itself?

		=20

		Thanks,

		Vishwas

	=09
________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Vishwas Manral
		Sent: Monday, October 17, 2005 11:41 AM
		To: Developing a hybrid router/bridge.
		Subject: [rbridge] Treating broadcast addresses

		=20

		Hi,

		=20

		I had a doubt about treatment of broadcast addresses.

		=20

		Currently using STP we have one tree and ports are
blocked/ forwarding, so packets cannot loop irrespective of destination
addresses. In IS-IS protocol, we use ports based on destination address
and no ports are blocked or unblocked. But if the destination address is
FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get
over it?

		=20

		Would we still allow broadcast destination address
packets to be forwarded? It is like preventing flooding loops in a case
where we have a global broadcast IP address, which is forwarded to all
attached routers. Am I missing the point all together?

		=20

		Thanks,

		Vishwas

		=20

------_=_NextPart_001_01C5D315.AF253BD8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi =
Rute,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for the reply. I am clearer =
now.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>If the root election is done at run =
time (like
DR election in IS-IS), it could mean that the Root could change often. =
If we
had a sticky Root election (like a DR election in OSPF) it could mean =
that the root
selection would take time to converge.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks =
again,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>=

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Sofia, Rute<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, =
2005 5:23
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Developing
 a hybrid router/bridge.</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] =
Treating
broadcast addresses</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Vishwas,</span></font><o:p></o:p></p=

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Suppose you are speaking about the =
ST that
Rbridges use to perform broadcast. You don't need root election: the =
info
provided by LSPs is enough to build the ST.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Regards,</span></font><o:p></o:p></p=

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Rute</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Vishwas Manral<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, =
2005
1:27 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Developing
 a hybrid router/bridge.</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] =
Treating
broadcast addresses</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi =
Rute,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Would this also mean Root-Election? =
What
about convergence of this tree?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>=

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Sofia, Rute<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, =
2005
4:36 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
tabIndex=3D"0"
style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"
w:st=3D"on">Developing a hybrid router/bridge.</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] =
Treating
broadcast addresses</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Vishwas,</span></font><o:p></o:p></p=

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>based on the information exchanged =
by LSPs
you can simply compute the ST locally. The key here is the choice of the =
root.
This can also be passed along by IS-IS...</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Regards,</span></font><o:p></o:p></p=

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Rute</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>My question is more like, how would =
we
build a spanning tree for broadcast using IS-IS? =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>We need a globally coordinated tree =
like
STP and not like the way IS-IS computes it. Would we require, changes to =
the
spanning tree computation itself?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>=

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
[email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On Behalf
Of </span></b>Vishwas Manral<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, =
2005
11:41 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
tabIndex=3D"0"
style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"
w:st=3D"on">Developing a hybrid router/bridge.</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [rbridge] =
Treating
broadcast addresses</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I had a doubt about treatment of broadcast =
addresses.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Currently using STP we have one tree and ports are =
blocked/
forwarding, so packets cannot loop irrespective of destination =
addresses. In
IS-IS protocol, we use ports based on destination address and no ports =
are
blocked or unblocked. But if the destination address is =
FF-FF-FF-FF-FF-FF we
could end in a forwarding loop. How would we get over =
it?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Would we still allow broadcast destination address =
packets
to be forwarded? It is like preventing flooding loops in a case where we =
have a
global broadcast IP address, which is forwarded to all attached routers. =
Am I
missing the point all together?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Vishwas<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</blockquote>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C5D315.AF253BD8--

Date: Mon, 17 Oct 2005 05:17:48 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1763

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6DDB1E9D7A4186DB999B949C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Ashwood-Smith wrote:
>   This lack of understanding of the DRs seems to be the cause of a lot
> of this debate. 

IMO, it's the belief that there will only ever be one DR or DR-like
(BLOCKing) device. I agree that this all works when it works.

>   Also, the 'problems' that people are attributing to blocking and not
> processing BPDUs [BLOCK] are also 'problems' when no STP is running.

'problems'? (why the quotes?)

OK, let's just shut off spanning tree in bridges and it all works just
fine now?

Now I'm *really* confused.

AFAICT, this all works when there is at most one rbridge campus in an L2.

WHEN (note the use of 'when', not 'if', since there's *nothing* that can
be done to enforce this) this isn't the case, the following problems arise:

	a) there is no way to detect the error

	b) loops *will* occur

If we want to say "BLOCK *MAY* work, but *MAY* silently fail", and
"PARTICIPATE and TRANSPARENT will always work with current standards",
that's fine (and, AFAICT, true), but I also don't see how we pick BLOCK
as a default in that case.

Joe

--------------enig6DDB1E9D7A4186DB999B949C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig6DDB1E9D7A4186DB999B949C--

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 13:52:48 +0200
From: "Sofia, Rute" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 15429

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5D311.4B954E04
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Vishwas,
=20
Suppose you are speaking about the ST that Rbridges use to perform
broadcast. You don't need root election: the info provided by LSPs is
enough to build the ST.
=20
Regards,
Rute
=20

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Vishwas Manral
	Sent: Monday, October 17, 2005 1:27 PM
	To: Developing a hybrid router/bridge.
	Subject: Re: [rbridge] Treating broadcast addresses
=09
=09

	Hi Rute,

	=20

	Would this also mean Root-Election? What about convergence of
this tree?

	=20

	Thanks,

	Vishwas

=09
________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sofia, Rute
	Sent: Monday, October 17, 2005 4:36 PM
	To: Developing a hybrid router/bridge.
	Subject: Re: [rbridge] Treating broadcast addresses

	=20

	Vishwas,

	=20

	based on the information exchanged by LSPs you can simply
compute the ST locally. The key here is the choice of the root. This can
also be passed along by IS-IS...

	=20

	Regards,

	Rute

	=20

		Hi,

		=20

		My question is more like, how would we build a spanning
tree for broadcast using IS-IS?=20

		=20

		We need a globally coordinated tree like STP and not
like the way IS-IS computes it. Would we require, changes to the
spanning tree computation itself?

		=20

		Thanks,

		Vishwas

	=09
________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Vishwas Manral
		Sent: Monday, October 17, 2005 11:41 AM
		To: Developing a hybrid router/bridge.
		Subject: [rbridge] Treating broadcast addresses

		=20

		Hi,

		=20

		I had a doubt about treatment of broadcast addresses.

		=20

		Currently using STP we have one tree and ports are
blocked/ forwarding, so packets cannot loop irrespective of destination
addresses. In IS-IS protocol, we use ports based on destination address
and no ports are blocked or unblocked. But if the destination address is
FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get
over it?

		=20

		Would we still allow broadcast destination address
packets to be forwarded? It is like preventing flooding loops in a case
where we have a global broadcast IP address, which is forwarded to all
attached routers. Am I missing the point all together?

		=20

		Thanks,

		Vishwas

		=20

------_=_NextPart_001_01C5D311.4B954E04
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR><!--[if !mso]>
<STYLE>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</STYLE>
<![endif]--><o:SmartTagType name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>
st1\:*{behavior:url(#default#ieooui) }
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D257455111-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Vishwas,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D257455111-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D257455111-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Suppose you are speaking about the ST that =
Rbridges use to=20
perform broadcast. You don't need root election: the info provided by =
LSPs is=20
enough to build the ST.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D257455111-17102005></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D257455111-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D257455111-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Rute</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Vishwas=20
  Manral<BR><B>Sent:</B> Monday, October 17, 2005 1:27 PM<BR><B>To:</B>=20
  Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] =
Treating=20
  broadcast addresses<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
  Rute,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Would this =
also mean=20
  Root-Election? What about convergence of this=20
  tree?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Vishwas<o:p></o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  [email-masked] [mailto:[email-masked]] =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Sofia, =
Rute<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, October 17, 2005 =
4:36=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
<st1:PersonName=20
  style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
  tabIndex=3D0 w:st=3D"on">Developing a hybrid=20
  router/bridge.</st1:PersonName><BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [rbridge] Treating =
broadcast=20
  addresses</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Vishwas,</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">based on =
the=20
  information exchanged by LSPs you can simply compute the ST locally. =
The key=20
  here is the choice of the root. This can also be passed along by=20
  IS-IS...</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Regards,</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Rute</SPAN></FONT><o:p></o:p></P>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: =
medium none">
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Hi,<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">My =
question is more=20
    like, how would we build a spanning tree for broadcast using IS-IS?=20
    <o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">We need a =
globally=20
    coordinated tree like STP and not like the way IS-IS computes it. =
Would we=20
    require, changes to the spanning tree computation=20
    itself?<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Vishwas<o:p></o:p></SPAN></FONT></P>
    <DIV>
    <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
    <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
    </SPAN></FONT></DIV>
    <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
    style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
    face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
    [email-masked] [mailto:[email-masked]] =
<B><SPAN=20
    style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Vishwas =
Manral<BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, October 17, =
2005 11:41=20
    AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
<st1:PersonName=20
    style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
    tabIndex=3D0 w:st=3D"on">Developing a hybrid=20
    router/bridge.</st1:PersonName><BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> [rbridge] Treating =
broadcast=20
    addresses</SPAN></FONT><o:p></o:p></P></DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Hi,<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I had a doubt about =
treatment of=20
    broadcast addresses.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently using STP we =
have one=20
    tree and ports are blocked/ forwarding, so packets cannot loop =
irrespective=20
    of destination addresses. In IS-IS protocol, we use ports based on=20
    destination address and no ports are blocked or unblocked. But if =
the=20
    destination address is FF-FF-FF-FF-FF-FF we could end in a =
forwarding loop.=20
    How would we get over it?<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Would we still allow =
broadcast=20
    destination address packets to be forwarded? It is like preventing =
flooding=20
    loops in a case where we have a global broadcast IP address, which =
is=20
    forwarded to all attached routers. Am I missing the point all=20
    together?<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Vishwas<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P></BLOCKQUOTE></DIV></BLOCKQUOTE=
></BODY></HTML>

------_=_NextPart_001_01C5D311.4B954E04--

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 04:27:28 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 12456

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5D30D.4C5C9A1A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Rute,

=20

Would this also mean Root-Election? What about convergence of this tree?

=20

Thanks,

Vishwas

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sofia, Rute
Sent: Monday, October 17, 2005 4:36 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Treating broadcast addresses

=20

Vishwas,

=20

based on the information exchanged by LSPs you can simply compute the ST
locally. The key here is the choice of the root. This can also be passed
along by IS-IS...

=20

Regards,

Rute

=20

	Hi,

	=20

	My question is more like, how would we build a spanning tree for
broadcast using IS-IS?=20

	=20

	We need a globally coordinated tree like STP and not like the
way IS-IS computes it. Would we require, changes to the spanning tree
computation itself?

	=20

	Thanks,

	Vishwas

=09
________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Vishwas Manral
	Sent: Monday, October 17, 2005 11:41 AM
	To: Developing a hybrid router/bridge.
	Subject: [rbridge] Treating broadcast addresses

	=20

	Hi,

	=20

	I had a doubt about treatment of broadcast addresses.

	=20

	Currently using STP we have one tree and ports are blocked/
forwarding, so packets cannot loop irrespective of destination
addresses. In IS-IS protocol, we use ports based on destination address
and no ports are blocked or unblocked. But if the destination address is
FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get
over it?

	=20

	Would we still allow broadcast destination address packets to be
forwarded? It is like preventing flooding loops in a case where we have
a global broadcast IP address, which is forwarded to all attached
routers. Am I missing the point all together?

	=20

	Thanks,

	Vishwas

	=20

------_=_NextPart_001_01C5D30D.4C5C9A1A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi =
Rute,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Would this also mean Root-Election? =
What
about convergence of this tree?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>=

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Sofia, Rute<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, =
2005 4:36
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Developing
 a hybrid router/bridge.</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [rbridge] =
Treating
broadcast addresses</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Vishwas,</span></font><o:p></o:p></p=

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>based on the information exchanged =
by LSPs
you can simply compute the ST locally. The key here is the choice of the =
root.
This can also be passed along by IS-IS...</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Regards,</span></font><o:p></o:p></p=

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Rute</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>My question is more like, how would =
we
build a spanning tree for broadcast using IS-IS? =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>We need a globally coordinated tree =
like
STP and not like the way IS-IS computes it. Would we require, changes to =
the
spanning tree computation itself?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>=

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
[email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On Behalf
Of </span></b>Vishwas Manral<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, =
2005
11:41 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
tabIndex=3D"0"
style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"
w:st=3D"on">Developing a hybrid router/bridge.</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [rbridge] =
Treating
broadcast addresses</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I had a doubt about treatment of broadcast =
addresses.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Currently using STP we have one tree and ports are =
blocked/
forwarding, so packets cannot loop irrespective of destination =
addresses. In
IS-IS protocol, we use ports based on destination address and no ports =
are
blocked or unblocked. But if the destination address is =
FF-FF-FF-FF-FF-FF we
could end in a forwarding loop. How would we get over =
it?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Would we still allow broadcast destination address =
packets
to be forwarded? It is like preventing flooding loops in a case where we =
have a
global broadcast IP address, which is forwarded to all attached routers. =
Am I
missing the point all together?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Vishwas<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C5D30D.4C5C9A1A--

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 13:06:09 +0200
From: "Sofia, Rute" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9943

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5D30A.C742E1AC
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Vishwas,
=20
based on the information exchanged by LSPs you can simply compute the ST
locally. The key here is the choice of the root. This can also be passed
along by IS-IS...
=20
Regards,
Rute

=20

	Hi,

	=20

	My question is more like, how would we build a spanning tree for
broadcast using IS-IS?=20

	=20

	We need a globally coordinated tree like STP and not like the
way IS-IS computes it. Would we require, changes to the spanning tree
computation itself?

	=20

	Thanks,

	Vishwas

=09
________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Vishwas Manral
	Sent: Monday, October 17, 2005 11:41 AM
	To: Developing a hybrid router/bridge.
	Subject: [rbridge] Treating broadcast addresses

	=20

	Hi,

	=20

	I had a doubt about treatment of broadcast addresses.

	=20

	Currently using STP we have one tree and ports are blocked/
forwarding, so packets cannot loop irrespective of destination
addresses. In IS-IS protocol, we use ports based on destination address
and no ports are blocked or unblocked. But if the destination address is
FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get
over it?

	=20

	Would we still allow broadcast destination address packets to be
forwarded? It is like preventing flooding loops in a case where we have
a global broadcast IP address, which is forwarded to all attached
routers. Am I missing the point all together?

	=20

	Thanks,

	Vishwas

	=20

------_=_NextPart_001_01C5D30A.C742E1AC
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR><!--[if !mso]>
<STYLE>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</STYLE>
<![endif]--><o:SmartTagType name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>
st1\:*{behavior:url(#default#ieooui) }
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Vishwas,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>based on the information exchanged by LSPs you =
can simply=20
compute the ST locally. The key here is the choice of the root. This can =
also be=20
passed along by IS-IS...</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Regards,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D968480411-17102005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Rute</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Hi,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">My question =
is more=20
  like, how would we build a spanning tree for broadcast using IS-IS?=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">We need a =
globally=20
  coordinated tree like STP and not like the way IS-IS computes it. =
Would we=20
  require, changes to the spanning tree computation=20
  itself?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Vishwas<o:p></o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  [email-masked] [mailto:[email-masked]] =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Vishwas =
Manral<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, October 17, 2005 =
11:41=20
  AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
<st1:PersonName=20
  style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
  tabIndex=3D0 w:st=3D"on">Developing a hybrid=20
  router/bridge.</st1:PersonName><BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> [rbridge] Treating =
broadcast=20
  addresses</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Hi,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I had a doubt about =
treatment of=20
  broadcast addresses.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Currently using STP we =
have one=20
  tree and ports are blocked/ forwarding, so packets cannot loop =
irrespective of=20
  destination addresses. In IS-IS protocol, we use ports based on =
destination=20
  address and no ports are blocked or unblocked. But if the destination =
address=20
  is FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we =
get over=20
  it?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Would we still allow =
broadcast=20
  destination address packets to be forwarded? It is like preventing =
flooding=20
  loops in a case where we have a global broadcast IP address, which is=20
  forwarded to all attached routers. Am I missing the point all=20
  together?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Vishwas<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTM=
L>

------_=_NextPart_001_01C5D30A.C742E1AC--

Content-class: urn:content-classes:message
Date: Mon, 17 Oct 2005 03:49:36 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8031

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5D308.017E57CB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

My question is more like, how would we build a spanning tree for
broadcast using IS-IS?=20

=20

We need a globally coordinated tree like STP and not like the way IS-IS
computes it. Would we require, changes to the spanning tree computation
itself?

=20

Thanks,

Vishwas

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vishwas Manral
Sent: Monday, October 17, 2005 11:41 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Treating broadcast addresses

=20

Hi,

=20

I had a doubt about treatment of broadcast addresses.

=20

Currently using STP we have one tree and ports are blocked/ forwarding,
so packets cannot loop irrespective of destination addresses. In IS-IS
protocol, we use ports based on destination address and no ports are
blocked or unblocked. But if the destination address is
FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get
over it?

=20

Would we still allow broadcast destination address packets to be
forwarded? It is like preventing flooding loops in a case where we have
a global broadcast IP address, which is forwarded to all attached
routers. Am I missing the point all together?

=20

Thanks,

Vishwas

=20

------_=_NextPart_001_01C5D308.017E57CB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>My question is more like, how would =
we build
a spanning tree for broadcast using IS-IS? <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>We need a globally coordinated tree =
like
STP and not like the way IS-IS computes it. Would we require, changes to =
the
spanning tree computation itself?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Vishwas<o:p></o:p></span></font></p>=

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Vishwas Manral<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 17, =
2005
11:41 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Developing
 a hybrid router/bridge.</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [rbridge] =
Treating
broadcast addresses</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I had a doubt about treatment of broadcast =
addresses.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Currently using STP we have one tree and ports are =
blocked/
forwarding, so packets cannot loop irrespective of destination =
addresses. In IS-IS
protocol, we use ports based on destination address and no ports are =
blocked or
unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could =
end in
a forwarding loop. How would we get over =
it?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Would we still allow broadcast destination address =
packets
to be forwarded? It is like preventing flooding loops in a case where we =
have a
global broadcast IP address, which is forwarded to all attached routers. =
Am I
missing the point all together?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Vishwas<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C5D308.017E57CB--

Date: Mon, 17 Oct 2005 06:42:42 -0400 (EDT)
From: Saikat Ray <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 759

> Currently using STP we have one tree and ports are blocked/ forwarding,
> so packets cannot loop irrespective of destination addresses. In IS-IS
> protocol, we use ports based on destination address and no ports are
> blocked or unblocked. But if the destination address is
> FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get
> over it?

Broadcast packets are sent over a spanning tree (not computed by the STP)
that spans the RBridges.

>
>
>
> Would we still allow broadcast destination address packets to be
> forwarded? It is like preventing flooding loops in a case where we have
> a global broadcast IP address, which is forwarded to all attached
> routers. Am I missing the point all together?
>
>
>
> Thanks,
>
> Vishwas
>
>
>
>

Date: Mon, 17 Oct 2005 12:26:42 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3132

I agree completely with Radia and I would add three more arguments in 
favour of Rbridge protocol separation from spanning tree protocols:
- If Rbridges are succesful, the bridges spanning trees will be legacy 
in the long term, or will tend to be excluded from the core of the 
campus network due to its much lower performance in terms of congestion, 
path length and  infrastructure usage.
- Coordination of the Rbridges protocol is not with one ST protocol but 
with TWO spanning tree protocols: STP (legacy, and slow) and RSTP 
(standard, faster). They have different mechanisms for convergence: wait 
a timer long enough to converge and  "wavefront" enabling of ports 
downstream from the root bridge  respectively. There is also a limit on 
the maximum diameter of spanning trees (related with the timer use) that 
should be taken into account by those in favour of big size spanning trees.
-Rbridges will be standardized by IETF, RSTP is under IEEE control. The 
risk of separate evolution exists. Although coordination IEEE-IETF 
works, it is better not to create  interdependencies if they can be avoided.
Guillermo

Radia Perlman wrote:

>It looks like this thread was discussed with two different subject 
>lines, and it's also
>gone on long enough it's time for someone to summarize it.
>
>I strongly believe that things will be more stable if RBridges do NOT 
>forward BPDUs...that
>we decouple the protocols.
>
>That TRILL is kind of like a layer between bridging and routing.
>
>If RBridges do not forward BPDUs, then whether or not the TRILL link 
>state protocol is
>converged, it won't affect the little spanning tree inside a particular 
>bridged segment.
>
>That way, the little spanning trees will converge as quickly as possible 
>(because it's small),
>and cannot possibly be disrupted by RBridges wormholing BPDUs.
>
>I do not understand the reasons why people want to forward BPDUs. I 
>think the arguments (which
>I may not be presenting fairly because I don't understand them) are:
>a) you'll get a more optimal combined spanning tree on which 
>unknown/broadcast frames will
>be sent if it is one global spanning tree, rather than little 
>independent spanning trees hooked together
>by the independently computed spanning tree calculated by IS-IS.
>b) forwarding BPDUs, and having a global spanning tree, will prevent loops.
>
>I strongly disagree with both those arguments. For a) What do people 
>think is more optimal about a tree
>computed that way vs having independent trees inside each bridged 
>island? And besides, there isn't
>a single spanning tree...it's a spanning tree per ingress RBridge.
>For b) no...I believe that having both the RBridge algorithm and the 
>bridge algorithm feeding into
>each other will create much slower convergence.
>
>If I haven't summarized correctly, then someone else can try to capture 
>the arguments, but I do
>think we should merge discussion under one subject line, and restart 
>with a summary.
>
>Radia
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Sun, 16 Oct 2005 23:11:28 -0700
From: "Vishwas Manral" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Treating broadcast addresses
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4189

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5D2E1.272B876B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

I had a doubt about treatment of broadcast addresses.

=20

Currently using STP we have one tree and ports are blocked/ forwarding,
so packets cannot loop irrespective of destination addresses. In IS-IS
protocol, we use ports based on destination address and no ports are
blocked or unblocked. But if the destination address is
FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get
over it?

=20

Would we still allow broadcast destination address packets to be
forwarded? It is like preventing flooding loops in a case where we have
a global broadcast IP address, which is forwarded to all attached
routers. Am I missing the point all together?

=20

Thanks,

Vishwas

=20

------_=_NextPart_001_01C5D2E1.272B876B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I had a doubt about treatment of broadcast =
addresses.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Currently using STP we have one tree and ports are =
blocked/
forwarding, so packets cannot loop irrespective of destination =
addresses. In
IS-IS protocol, we use ports based on destination address and no ports =
are
blocked or unblocked. But if the destination address is =
FF-FF-FF-FF-FF-FF we
could end in a forwarding loop. How would we get over =
it?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Would we still allow broadcast destination address =
packets
to be forwarded? It is like preventing flooding loops in a case where we =
have a
global broadcast IP address, which is forwarded to all attached routers. =
Am I
missing the point all together?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Vishwas<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C5D2E1.272B876B--

Content-class: urn:content-classes:message
Date: Sun, 16 Oct 2005 21:10:16 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5651

  This lack of understanding of the DRs seems to be the cause of a lot
of this debate. 

  Also, the 'problems' that people are attributing to blocking and not
processing BPDUs [BLOCK] are also 'problems' when no STP is running.
In the case where two broadcast domains are rbridged together in such a
way
as to create a loop, the DR mechanism will detect and prevent it, so it
works
even when BPDUs are not present. 

  So far the only reason I can think of to allow BPDUs to passively pass
is for migration purposes. To keep the tree from changing 'just yet' but
it certainly won't speed anything up, fix anything or do more to prevent
loops than blocking will.

  Peter Ashwood-Smith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Sunday, October 16, 2005 8:46 PM
> To: [email-masked]; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Time to summarize "forward or block" 
> BPDU thread
> 
> 
> The scenario you mention is where there is temporarily two Designated 
> RBridges (DRs), because
> two links were merged.
> 
> The DRs will notice this when they start seeing each other's 
> IS-IS Hello 
> messages, and that
> will break the loop.
> 
> I don't think this case is that much of a problem, and 
> certainly would 
> not be helped by trying to run a big
> global spanning tree. The big global spanning tree would 
> converge much 
> slower than the RBridge
> DR election protocol would. So attempting to avoid a 
> temporary loop when 
> two bridged domains
> are merged, by running a big global instance
> of the spanning tree algorithm, will not solve the problem, and will 
> actually
> make things worse.
> 
> Radia
> 
> 
> 
> 
> Saikat Ray wrote:
> 
> >It is probably a standard scenario in IS-IS protocol (and 
> consequently 
> >a standard solution is known), but I was thinking that if 
> the RBridges 
> >disregards BPDUs entirely, then in some situations loops may 
> form for 
> >some period. For example, suppose $T_1$ and $T_2$ are disjoint trees 
> >formed entirely by legacy elements. $R_1$ and $R_2$ are the 
> designated 
> >RBridges for the "links" $T_1$ and $T_2$, respectively. At 
> this point, 
> >there is no loop in the system. Now suppose that a physical 
> link (or a 
> >legacy bridge) is added that connects a legacy bridge of $T_1$ to a 
> >legacy bridge of $T_2$. This addition will trigger a new 
> Spanning tree 
> >computation, which will result into a single spanning tree 
> that spans 
> >the nodes of $T_1$ and $T_2$. At this point, effectively the 
> RBridges 
> >$R_1$ and $R_2$ are connected by a single "link" and until 
> one of the 
> >RBridge gets "de-designated", there would exist a loop. Two 
> questions 
> >arise in my mind: (i) how fast would that "de-designation" 
> process be? 
> >And (ii) would it be useful (i.e. would it accelerate the 
> convergence) 
> >if RBridges "listen" to the BPDUs?
> >
> >From: [email-masked] 
> [mailto:[email-masked]] On 
> >Behalf Of Radia Perlman
> >Sent: Sunday, October 16, 2005 7:12 PM
> >Subject: [rbridge] Time to summarize "forward or block" BPDU thread
> >
> >It looks like this thread was discussed with two different subject
> >lines, and it's also
> >gone on long enough it's time for someone to summarize it.
> >
> >I strongly believe that things will be more stable if RBridges do NOT
> >forward BPDUs...that
> >we decouple the protocols.
> >
> >That TRILL is kind of like a layer between bridging and routing.
> >
> >If RBridges do not forward BPDUs, then whether or not the TRILL link
> >state protocol is
> >converged, it won't affect the little spanning tree inside a 
> particular 
> >bridged segment.
> >
> >That way, the little spanning trees will converge as quickly as 
> >possible
> >(because it's small),
> >and cannot possibly be disrupted by RBridges wormholing BPDUs.
> >
> >I do not understand the reasons why people want to forward BPDUs. I
> >think the arguments (which
> >I may not be presenting fairly because I don't understand them) are:
> >a) you'll get a more optimal combined spanning tree on which 
> >unknown/broadcast frames will
> >be sent if it is one global spanning tree, rather than little 
> >independent spanning trees hooked together
> >by the independently computed spanning tree calculated by IS-IS.
> >b) forwarding BPDUs, and having a global spanning tree, will 
> prevent loops.
> >
> >I strongly disagree with both those arguments. For a) What do people
> >think is more optimal about a tree
> >computed that way vs having independent trees inside each bridged 
> >island? And besides, there isn't
> >a single spanning tree...it's a spanning tree per ingress RBridge.
> >For b) no...I believe that having both the RBridge algorithm and the 
> >bridge algorithm feeding into
> >each other will create much slower convergence.
> >
> >If I haven't summarized correctly, then someone else can try 
> to capture
> >the arguments, but I do
> >think we should merge discussion under one subject line, and restart 
> >with a summary.
> >
> >Radia
> >
> >[email-masked] http://www.postel.org/mailman/listinfo/rbridge
> >
> >[email-masked] http://www.postel.org/mailman/listinfo/rbridge
> >  
> >
> 
> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
> 
> 

Date: Sun, 16 Oct 2005 17:45:47 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4213

The scenario you mention is where there is temporarily two Designated 
RBridges (DRs), because
two links were merged.

The DRs will notice this when they start seeing each other's IS-IS Hello 
messages, and that
will break the loop.

I don't think this case is that much of a problem, and certainly would 
not be helped by trying to run a big
global spanning tree. The big global spanning tree would converge much 
slower than the RBridge
DR election protocol would. So attempting to avoid a temporary loop when 
two bridged domains
are merged, by running a big global instance
of the spanning tree algorithm, will not solve the problem, and will 
actually
make things worse.

Radia

Saikat Ray wrote:

>It is probably a standard scenario in IS-IS protocol (and consequently a
>standard solution is known), but I was thinking that if the RBridges
>disregards BPDUs entirely, then in some situations loops may form for some
>period. For example, suppose $T_1$ and $T_2$ are disjoint trees formed
>entirely by legacy elements. $R_1$ and $R_2$ are the designated RBridges for
>the "links" $T_1$ and $T_2$, respectively. At this point, there is no loop
>in the system. Now suppose that a physical link (or a legacy bridge) is
>added that connects a legacy bridge of $T_1$ to a legacy bridge of $T_2$.
>This addition will trigger a new Spanning tree computation, which will
>result into a single spanning tree that spans the nodes of $T_1$ and $T_2$.
>At this point, effectively the RBridges $R_1$ and $R_2$ are connected by a
>single "link" and until one of the RBridge gets "de-designated", there would
>exist a loop. Two questions arise in my mind: (i) how fast would that
>"de-designation" process be? And (ii) would it be useful (i.e. would it
>accelerate the convergence) if RBridges "listen" to the BPDUs?
>
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Radia Perlman
>Sent: Sunday, October 16, 2005 7:12 PM
>Subject: [rbridge] Time to summarize "forward or block" BPDU thread
>
>It looks like this thread was discussed with two different subject 
>lines, and it's also
>gone on long enough it's time for someone to summarize it.
>
>I strongly believe that things will be more stable if RBridges do NOT 
>forward BPDUs...that
>we decouple the protocols.
>
>That TRILL is kind of like a layer between bridging and routing.
>
>If RBridges do not forward BPDUs, then whether or not the TRILL link 
>state protocol is
>converged, it won't affect the little spanning tree inside a particular 
>bridged segment.
>
>That way, the little spanning trees will converge as quickly as possible 
>(because it's small),
>and cannot possibly be disrupted by RBridges wormholing BPDUs.
>
>I do not understand the reasons why people want to forward BPDUs. I 
>think the arguments (which
>I may not be presenting fairly because I don't understand them) are:
>a) you'll get a more optimal combined spanning tree on which 
>unknown/broadcast frames will
>be sent if it is one global spanning tree, rather than little 
>independent spanning trees hooked together
>by the independently computed spanning tree calculated by IS-IS.
>b) forwarding BPDUs, and having a global spanning tree, will prevent loops.
>
>I strongly disagree with both those arguments. For a) What do people 
>think is more optimal about a tree
>computed that way vs having independent trees inside each bridged 
>island? And besides, there isn't
>a single spanning tree...it's a spanning tree per ingress RBridge.
>For b) no...I believe that having both the RBridge algorithm and the 
>bridge algorithm feeding into
>each other will create much slower convergence.
>
>If I haven't summarized correctly, then someone else can try to capture 
>the arguments, but I do
>think we should merge discussion under one subject line, and restart 
>with a summary.
>
>Radia
>
>[email-masked]
>[email-masked]

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Sun, 16 Oct 2005 20:09:44 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3288

It is probably a standard scenario in IS-IS protocol (and consequently a
standard solution is known), but I was thinking that if the RBridges
disregards BPDUs entirely, then in some situations loops may form for some
period. For example, suppose $T_1$ and $T_2$ are disjoint trees formed
entirely by legacy elements. $R_1$ and $R_2$ are the designated RBridges for
the "links" $T_1$ and $T_2$, respectively. At this point, there is no loop
in the system. Now suppose that a physical link (or a legacy bridge) is
added that connects a legacy bridge of $T_1$ to a legacy bridge of $T_2$.
This addition will trigger a new Spanning tree computation, which will
result into a single spanning tree that spans the nodes of $T_1$ and $T_2$.
At this point, effectively the RBridges $R_1$ and $R_2$ are connected by a
single "link" and until one of the RBridge gets "de-designated", there would
exist a loop. Two questions arise in my mind: (i) how fast would that
"de-designation" process be? And (ii) would it be useful (i.e. would it
accelerate the convergence) if RBridges "listen" to the BPDUs?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Sunday, October 16, 2005 7:12 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Time to summarize "forward or block" BPDU thread

It looks like this thread was discussed with two different subject 
lines, and it's also
gone on long enough it's time for someone to summarize it.

I strongly believe that things will be more stable if RBridges do NOT 
forward BPDUs...that
we decouple the protocols.

That TRILL is kind of like a layer between bridging and routing.

If RBridges do not forward BPDUs, then whether or not the TRILL link 
state protocol is
converged, it won't affect the little spanning tree inside a particular 
bridged segment.

That way, the little spanning trees will converge as quickly as possible 
(because it's small),
and cannot possibly be disrupted by RBridges wormholing BPDUs.

I do not understand the reasons why people want to forward BPDUs. I 
think the arguments (which
I may not be presenting fairly because I don't understand them) are:
a) you'll get a more optimal combined spanning tree on which 
unknown/broadcast frames will
be sent if it is one global spanning tree, rather than little 
independent spanning trees hooked together
by the independently computed spanning tree calculated by IS-IS.
b) forwarding BPDUs, and having a global spanning tree, will prevent loops.

I strongly disagree with both those arguments. For a) What do people 
think is more optimal about a tree
computed that way vs having independent trees inside each bridged 
island? And besides, there isn't
a single spanning tree...it's a spanning tree per ingress RBridge.
For b) no...I believe that having both the RBridge algorithm and the 
bridge algorithm feeding into
each other will create much slower convergence.

If I haven't summarized correctly, then someone else can try to capture 
the arguments, but I do
think we should merge discussion under one subject line, and restart 
with a summary.

Radia

[email-masked]

Date: Sun, 16 Oct 2005 16:11:53 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Time to summarize "forward or block" BPDU thread
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1791

It looks like this thread was discussed with two different subject 
lines, and it's also
gone on long enough it's time for someone to summarize it.

I strongly believe that things will be more stable if RBridges do NOT 
forward BPDUs...that
we decouple the protocols.

That TRILL is kind of like a layer between bridging and routing.

If RBridges do not forward BPDUs, then whether or not the TRILL link 
state protocol is
converged, it won't affect the little spanning tree inside a particular 
bridged segment.

That way, the little spanning trees will converge as quickly as possible 
(because it's small),
and cannot possibly be disrupted by RBridges wormholing BPDUs.

I do not understand the reasons why people want to forward BPDUs. I 
think the arguments (which
I may not be presenting fairly because I don't understand them) are:
a) you'll get a more optimal combined spanning tree on which 
unknown/broadcast frames will
be sent if it is one global spanning tree, rather than little 
independent spanning trees hooked together
by the independently computed spanning tree calculated by IS-IS.
b) forwarding BPDUs, and having a global spanning tree, will prevent loops.

I strongly disagree with both those arguments. For a) What do people 
think is more optimal about a tree
computed that way vs having independent trees inside each bridged 
island? And besides, there isn't
a single spanning tree...it's a spanning tree per ingress RBridge.
For b) no...I believe that having both the RBridge algorithm and the 
bridge algorithm feeding into
each other will create much slower convergence.

If I haven't summarized correctly, then someone else can try to capture 
the arguments, but I do
think we should merge discussion under one subject line, and restart 
with a summary.

Radia

Date: Sun, 16 Oct 2005 12:33:24 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1986

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig01CB02CD89AB2E1B650A8211
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Harald Tveit Alvestrand wrote:
>=20
> --On s=F8ndag, oktober 16, 2005 09:21:57 -0700 Joe Touch <[email-masked]=
>=20
> wrote:
>=20
>=20
>>>What we should be thinking of (to my mind) is "how do we discover that=

>>>we're up the creek" - for this particular disaster, sending out a
>>>broadcast packet and watching it come back should be quite sufficient
>>>for the "detect" part....
>>
>>What if you send a packet and it creates a broadcast storm? Sure, you
>>know you're up the creek, but how do you paddle back?
>=20
> if I have an one-packet answer to "how to take down a network", that=20
> network is certainly in trouble without me..... but others have certain=
ly=20
> suggested forms of probing (hello packets?) that might be more gentle.

My concern is that every reason for allowing BLOCK for rbridges is a
reason to allow them for bridges as well.

SPT is there for a reason - to avoid the possibility of loops, and thus
such one-packet problems (deliberate or otherwise). I don't understand
why that's the required default for bridges (AFACT - regardless of
vendor offerings) but can be relaxed here.

> I'd very much like to design a network that is stable in the presence o=
f a=20
> person with a laptop, an ordinary bridge port and no conscience....

Agreed.

Joe

--------------enig01CB02CD89AB2E1B650A8211
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig01CB02CD89AB2E1B650A8211--

Date: Sun, 16 Oct 2005 20:25:59 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 823

--On s?ndag, oktober 16, 2005 09:21:57 -0700 Joe Touch <[email-masked]> 
wrote:

>> What we should be thinking of (to my mind) is "how do we discover that
>> we're up the creek" - for this particular disaster, sending out a
>> broadcast packet and watching it come back should be quite sufficient
>> for the "detect" part....
>
> What if you send a packet and it creates a broadcast storm? Sure, you
> know you're up the creek, but how do you paddle back?

if I have an one-packet answer to "how to take down a network", that 
network is certainly in trouble without me..... but others have certainly 
suggested forms of probing (hello packets?) that might be more gentle.

I'd very much like to design a network that is stable in the presence of a 
person with a laptop, an ordinary bridge port and no conscience....

Content-class: urn:content-classes:message
Date: Sun, 16 Oct 2005 13:56:58 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 399

> What if you send a packet and it creates a broadcast storm? 
> Sure, you know you're up the creek, but how do you paddle back?

  If your new device (like rbridge) sends and receives hellos before it 
unblocks ports this should not happen. You really can't protect against
poor design but if each new device type follows this sort of rule
the end result should be a tree (i.e. no loops).

  Peter

Date: Sun, 16 Oct 2005 09:21:57 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1844

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7669BE26E62B80051C53E57B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Harald Tveit Alvestrand wrote:
> 
> 
> --On 15. oktober 2005 08:22 -0700 Joe Touch <[email-masked]> wrote:
> 
>> I.e., this works because all rbridges join to make a single campus.
>> If there are two or more campuses in the same L2, or if some other
>> device or pseudodevice (sbridge ;-) decides to play this game, the
>> rbridge campus can't BLOCK; it MUST be PARTICIPATE or TRANSPARENT.
>>
>> I don't believe it is therefore appropriate to BLOCK; if we break the
>> 'all bridges/hubs must play in spanning tree' rule, we can't ensure that
>> there won't be any other device that will do this too.
> 
> actually we *can't* ensure that all bridges and hubs play the spanning
> tree game no matter what we do, given that spanning tree is a
> configuration option on switches.
> 
> What we should be thinking of (to my mind) is "how do we discover that
> we're up the creek" - for this particular disaster, sending out a
> broadcast packet and watching it come back should be quite sufficient
> for the "detect" part....

What if you send a packet and it creates a broadcast storm? Sure, you
know you're up the creek, but how do you paddle back?

Joe

--------------enig7669BE26E62B80051C53E57B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7669BE26E62B80051C53E57B--

Date: Sun, 16 Oct 2005 12:15:09 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicabi lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1497

--==========88B549C0F2A39A9686C7==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 15. oktober 2005 08:22 -0700 Joe Touch <[email-masked]> wrote:

> I.e., this works because all rbridges join to make a single campus.
> If there are two or more campuses in the same L2, or if some other
> device or pseudodevice (sbridge ;-) decides to play this game, the
> rbridge campus can't BLOCK; it MUST be PARTICIPATE or TRANSPARENT.
>
> I don't believe it is therefore appropriate to BLOCK; if we break the
> 'all bridges/hubs must play in spanning tree' rule, we can't ensure that
> there won't be any other device that will do this too.

actually we *can't* ensure that all bridges and hubs play the spanning tree =

game no matter what we do, given that spanning tree is a configuration=20
option on switches.

What we should be thinking of (to my mind) is "how do we discover that=20
we're up the creek" - for this particular disaster, sending out a broadcast =

packet and watching it come back should be quite sufficient for the=20
"detect" part....

--==========88B549C0F2A39A9686C7==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========88B549C0F2A39A9686C7==========--

Content-class: urn:content-classes:message
Date: Sat, 15 Oct 2005 20:13:42 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract	for problem and	applicabi lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1285

> OK - thinking about this further, I think I get it - with a caveat.
> 
> BLOCK works fine, provided the rbridge campus is the ONLY 
> "device" in the L2 who thinks it's appropriate to BLOCK. As 
> such, it knows that it can't form a loop by tying together edge trees.
> 
> I.e., this works because all rbridges join to make a single 
> campus. If there are two or more campuses in the same L2, or 
> if some other device or pseudodevice (sbridge ;-) decides to 
> play this game, the rbridge campus can't BLOCK; it MUST be 
> PARTICIPATE or TRANSPARENT.
> 
> I don't believe it is therefore appropriate to BLOCK; if we 
> break the 'all bridges/hubs must play in spanning tree' rule, 
> we can't ensure that there won't be any other device that 
> will do this too.

  I think that if each new type of device takes care of detecting a 
condition that could loop between its own devices ( and avoiding it )
then the entire L2 network will be loop free. As you can see, the
rbridge did
not need to 'talk' to the bridges to detect that a loop
existed. It heard its own hellos and deduced that it would
form a loop if it uses both devices/ports. The same would be true of
any other hypothetical device, if it hears its own messages
on some other port it knows there is a loop. 

  Peter

Date: Sat, 15 Oct 2005 08:22:45 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract	for problem and	applicabi lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3014

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig46C5E713863C1CE211F03825
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Ashwood-Smith wrote:
>>FWIW, nobody has answered the basic question:
>>replace an rbridge in BLOCK mode with a bridge
>>run whatever rbridges run internally within the bridge
>>(i.e., emulate it)
>>would THAT device be able to replace a bridge?
>>would THAT device be able to partition the STPs of its leaves?
> 
> 
>   Let me take a crack at it. 
> 
>   If I take one big STP domain and pick some point in the middle and
> block
> the BPDUS, clearly what I get is two independent trees that won't know
> about 
> each other. Broadcast packets on one side will get to the other as if
> there
> were a host on the far side, but would potentially loop if there were
> two links
> between the trees. To fix this, somebody has to block one of the links
> in
> both directions at one end or the other, or both ends.
> 
>   Now, if we take the code on rbridge that elects a desgnated rbridge to
> 
> act as the interface between these domains, run that same
> logic on this new 'bridge'. Then yes. It could replace a bridge at this
> boundary
> since it would decide which link between the trees to use and would
> block the
> others.
> 
>   Anyway the key to eliminating this confusion is to understand that the
> designated rbridge allows only one link between the trees. This concept
> can be used to join two
> trees together regardless of how they are created and only has to be
> done by one
> side or the other, not both. You could have two statically configured
> trees with two or more links betwen them and this concept will pick one
> link to use and ignore/block the others.

OK - thinking about this further, I think I get it - with a caveat.

BLOCK works fine, provided the rbridge campus is the ONLY "device" in
the L2 who thinks it's appropriate to BLOCK. As such, it knows that it
can't form a loop by tying together edge trees.

I.e., this works because all rbridges join to make a single campus.
If there are two or more campuses in the same L2, or if some other
device or pseudodevice (sbridge ;-) decides to play this game, the
rbridge campus can't BLOCK; it MUST be PARTICIPATE or TRANSPARENT.

I don't believe it is therefore appropriate to BLOCK; if we break the
'all bridges/hubs must play in spanning tree' rule, we can't ensure that
there won't be any other device that will do this too.

Joe

--------------enig46C5E713863C1CE211F03825
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig46C5E713863C1CE211F03825--

Content-class: urn:content-classes:message
Date: Sat, 15 Oct 2005 11:11:57 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract	for problem and	applicabi lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1526

> FWIW, nobody has answered the basic question:
> replace an rbridge in BLOCK mode with a bridge
> run whatever rbridges run internally within the bridge
> (i.e., emulate it)
> would THAT device be able to replace a bridge?
> would THAT device be able to partition the STPs of its leaves?

  Let me take a crack at it. 

  If I take one big STP domain and pick some point in the middle and
block
the BPDUS, clearly what I get is two independent trees that won't know
about 
each other. Broadcast packets on one side will get to the other as if
there
were a host on the far side, but would potentially loop if there were
two links
between the trees. To fix this, somebody has to block one of the links
in
both directions at one end or the other, or both ends.

  Now, if we take the code on rbridge that elects a desgnated rbridge to

act as the interface between these domains, run that same
logic on this new 'bridge'. Then yes. It could replace a bridge at this
boundary
since it would decide which link between the trees to use and would
block the
others.

  Anyway the key to eliminating this confusion is to understand that the
designated rbridge allows only one link between the trees. This concept
can be used to join two
trees together regardless of how they are created and only has to be
done by one
side or the other, not both. You could have two statically configured
trees with two or more links betwen them and this concept will pick one
link to use and ignore/block the others.

  Peter Ashwood-Smith

Date: Fri, 14 Oct 2005 21:12:32 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract	for problem and	applicabi lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 11280

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFF8CA7BF29078962B06ABDEF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Gray, Eric wrote:
> Joe,
> 
> 	You said: The edges are individual spanning trees. The rbridge 
> 	can have more than one internal path between two edge trees, 
> 	but that's it, that's all the redundency that's provided. 
> 	Turning off ports on the outside edge of the rbridge has no 
> 	effect on the internal multipath potential.
> 
> 	And then later, you also said: Yes [STP would be disabled by 
> 	default]. And not to forward ingress frames until internal 
> 	routing (IS-IS in this case) is established. At that point, 
> 	STP should be enabled at the 'edges', STP PARTICIPATEd, and 
> 	-then- ingress enabled.
> 
> 	What's the problem?
> 
> "Internal" and "external" are not meaningful terms.  How would an
> RBridge distinguish an "internal" bridge from an "external" bridge?

Internal and external traffic is easy to distinguish (internal has the
shim header). Bridges can be either or both, of course. It doesn't
matter, though - both can set their spanning trees before the rbridge is
configured.

> You suggest that this would occur as a result of recognizing that
> another RBridge exists on the local bridged network.  That appears
> to assume that the only way to keep RBridges from being part of the
> same campus is to put a router between them.  That - in turn - has
> some interesting implications with respect to colocation of router
> and RBridge functionality.

That was Radia's assertion. I had always thought an L2 could have more
than one rbridge campus, but that would imply that there was a way to
indicate which campus an rbridge was part of (e.g., via override).

> The key reason why I don't think that the presence of other RBridge 
> on a port makes it an "internal" port is that there is a distinction
> between reaching other RBridges in certain extended topologies and
> reaching them in other densely interconnected topologies.  But that
> may simply be a terminology issue.
> 
> The same applies to "ingress" and "edge".
> 
> But there's a larger issue.  I am not at all convinced that it is
> ever necessary to differentiate the behavior of "internal" verses
> "external" interfaces.  Consequently, I think it is an unecessary
> complication, especially given that - if it is indeed based on the
> presence of another RBridge on the same link - it is something that
> can change very quickly, causing an RBridge to change operational
> modes.  There's no reason I can see for taking on the additional 
> complexity.

I agree that interfaces aren't internal or external. Let's put it this way:

	rbridges ingress/egress functionality is disabled until the
	spanning trees of other bridges is completed (it basically has
	to be; otherwise, stuff falls on the floor).

	once the other spanning trees are set, the rbridge can
	enable ingress/egress (which is when it would anyway, since
	that's the point at which traffic would flow.

> 	You also said: Rbridges have nothing to do with the convergence 
> 	of the spanning tree external to them, IMO. All they do is have 
> 	their INTERNAL routing converge faster than spanning tree would
> 	have - that's where the benefit comes from. I never thought it 
> 	had anything to do with an effect on the external trees.
> 
> 	And then later said: That's an interesting question - [a longer 
> 	initial convergence time] may be the result of having an internal 
> 	routing protocol that isn't setup ahead of time. [That is], maybe
> 	rbridges DO take longer to *initially* converge the STP of an 
> 	existing net, but react faster *afterwards* to changes.
> 
> This is only true if RBridges do not participate in STP with the
> bridges in a local bridged network. If they do participate, then
> the STP will not converge until after the RBridges have determined
> forwarding paths among themselves, which will not occur until any
> bridges between RBridges have converged on their STP.
> 
> So, the bridges between RBridges do STP.  The links between RBridges
> come up.  The RBridges "hello" each other, peer, exchange link state
> and reachability information, and then announce a topology change to
> at least all ports that they have not heard other RBridges on (though
> this is not sufficient, let's assume for simplicity that it is).  Now
> the bridges on the affected links re-start STP - only now the network
> of bridges is very much larger, because it includes at least bridges
> that hang off of the RBridge's peer's other interfaces.
> 
> How is it that this does not take longer than if the RBridges didn't
> exist?  Also, there appears to be a misconception that STP takes a
> long time in comparison with routing.  Given that STP must complete 
> before routing can begin, this is a bit of a misleading concern, at
> best.

This is a startup issue; I have already agreed that this would take
longer with rbridges in the loop, with the hope that later cahnges could
be propagated more quickly.

> Let's take a specific case: An "internal" bridge goes down, taking
> one or more links between RBridges with it.  The RBridges lose a
> forwarding path and make the corresponding LSDB updates. Further,
> let's assume that this partitions the RBridge campus temporarily.
> 
> The link is redundant, so a neighbor will announce a topology change 
> and STP will re-run to switch port forwarding states so that the 
> redundant path is now available.  
> 
> The link returns and IS-IS reconverges.  Now the RBridges might be 
> clever and recognize that the net change (no pun intended) is NIL - 
> assuming that all of this happened fast enough that the RBridges
> have not previously announced a topology change to "external" bridges.
> 
> In this case, nothing else happens.  
> 
> However, let's assume that the re-establishment of the "internal" 
> link did not happen fast enough.  In that case, the "external" 
> bridges will see two topology change notifications and STP will be 
> run each time.  If the second topology change occurs before the STP 
> completes for the first topology change, it will be as if the whole 
> system is being restarted from scratch.

I'm not sure I followed all of that, but yes, there are cases where
changes in the internal paths available to an rbridge due to
partitioning could affect edge STPs.

> 	You also said: [STP convergence is] just like adding a bridge 
> 	to an existing bridged system. The new bridge doesn't forward 
> 	frames until STP finishes, but the existing bridges can finish 
> 	just fine. The rbridge is the 'new' bridge. 
> 
> 	All the other bridges are the existing bridge system. No chicken 
> 	and egg, AFAICT; the sequence is determined by rbridge's reliance 
> 	on bridges.
> 
> I think that in this case (and maybe in others) we're not talking
> about the same kind of convergence problem. I am talking about the
> time that initial convergence takes and you're (apparently) talking 
> about the time it take to re-converge after a minor topology change.

I had been talking about both cases (at least in later emails), and
already agreed they were different.

> Also, STP convergence - as explained above - is different if a 
> bridge goes down.
> 
> I think - even so - that there's a flaw in your reasoning that is
> based on a mistaken assumption that you specifically state below.
> 
> 	Also, you said: Again, I'm back to 'what would a bridge do'. 
> 	Either this is a bridge (PARTICIPATE) or a link (e.g., hub, 
> 	which means TRANSPARENT). Those are the only two options that 
> 	have correlaries in existing L2.
> 
> That's simply not true.  Hosts exist at L2.  Routers exist at L2.
> Neither of them do either of these.

Yes. And - sorry to shout but this point apparently isn't being
appreciated - BOTH HAVE L2 SOURCE/SINK ADDRESSES.

Rbridges - at least as far as ingress/egress links are concerned - do
NOT. Their addresses are ONLY for rbridge-rbridge traffic.

So - this is equally important:

	to conventional nodes (hosts/routers are the same thing in L2)
	on the L2, the rbridge MUST act like a link/hub or switch

	to other rbridge nodes (and only to them), the ingress/egress
	look like conventional nodes (sources/sinks)

> 	Finally, you also said: [RBridges] can't make redundent paths 
> 	in the non-rbridge portion of an L2 net. They can only do so 
> 	within the rbridge.
> 
> This is a flawed assumption.
> 
> Note that even bridges can carry L2 traffic for more than one VLAN.
> It's a simple matter - if you're starting from scratch to implement
> a bridge - to allow an RBridge (for instance) to use one port in a
> local bridged network to forward frames associated with one set of
> VLANs, and another port in the same local bridged network to forward
> frames associate with another set of VLANs.

Different ports for different VLANs aren't redundent paths, unless
you're going to move frames from one VLAN to another.

> Also note that there is no possibility of looping traffic introduced
> by this behavior.
> 
> Also note that the same would obviously apply if another RBridge
> in the same RBridge campus had a port in the same local bridged
> network.
> 
> Participation in the local STP would mean that the local bridges 
> would determine that the RBridge campus had a redundant path.  As
> a result, certain of the local bridges would put their ports in a
> non-forwarding mode - making use of the redundant path impossible.

Isn't that just an STP per VLAN?

> Clearly this can be applied to other mechanisms for differentiating
> frame-streams than by VLAN-ID, but it should be sufficient to show
> a single example of when participating in local STP is a bad idea.
> 
> Finally, note once again that all of this applies equally to both
> "internal" and "external" ports.

FWIW, nobody has answered the basic question:

	replace an rbridge in BLOCK mode with a bridge

	run whatever rbridges run internally within the bridge
	(i.e., emulate it)

	would THAT device be able to replace a bridge?
	would THAT device be able to partition the STPs of its leaves?
	
So far, the ONLY reason I can see that the rbridge *might* get away
doing anything different from a bridge is the requirement/assumption
that all rbridge devices in an L2 aggregate into a single campus.

If that IS the case, there *might* be a way it can do something other
than TRANSPARENT or PARTICIPATE, but it's not clear how different it
ends up being from PARTICIPATE (it seems like it still has to be roots
on each STP - how does it do that?)

If that IS NOT the case, someone needs to show how these behaviours
couldn't be used to augment a conventional bridge to result in
partitioned, faster-converging STPs.

Joe

--------------enigFF8CA7BF29078962B06ABDEF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigFF8CA7BF29078962B06ABDEF--

Content-class: urn:content-classes:message
Date: Fri, 14 Oct 2005 23:10:05 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking	input	on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 993

> The only reason it'd be blocked is if the spanning tree protocol knew
both rbridges were part of the same spanning tree. I thought that's what
the BPDUs would indicate.

A packet can be not forwarded at either an egress or ingress port Joe.
The rbridges fix this problem so the bridges don't have to. Two or more
more Rbridges that are connected to the same broadcast domain (i.e. STP
tree) will elect one of them to relay traffic to/from that STP domain
the others will ignor everything they see comming from that port and not
forward anything to that port (i.e. they block it). I think this is the
critical piece you are missing. In your mind this is PARTICIPATE but its
not because its one sided, only the Rbridges need to agree on this
behaviour. The bridges don't need to know the Rbridges are doing it.

Like I've said, take two disjoint trees, join with a single link and you
have a tree. It is the behaviour above that guarantees the single
connection between the two trees.

Peter

Date: Sat, 15 Oct 2005 02:55:01 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking	input	on	abstractfor	problemand	applicabili tystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2027

Eric,
       The difficulties you mention regarding per VLAN trees are among 
the reasons I would recommend (instead of per VLAN Rbridge trees) one 
spanning tree per Rbridge to all other Rbridges, carrying all VLANs, 
irrespective of VLAN membership. Rbridges in this way act as double root 
bridges, for the edge tree of bridges and (route wise) for the Rbridges 
tree.
       Guillermo

Gray, Eric wrote:

>Guillermo,
>
>	I agree with your comments to Joe, but I want to expand
>on the last comment that you made (included below).
>
>	One of the big problems with assuming that STP is used
>across the entire RBridge campus is that this doesn't allow
>us to take advantage of things we know now that were not known 
>when STP was designed.  For example, VLANs.
>
>	One of the proposals for creating a shortest path spanning
>tree within the campus is to allow a spanning tree per VLAN.  A
>set of 802 bridges cannot do that.  However, it is incredibly 
>likely that small spanning trees at the edge of a campus will 
>have significant non-intersecting VLAN membership.  This implies 
>that there is a potentially significant benefit from having per
>VLAN shortest path spanning trees within the RBridge campus.  In
>this case, topology that must be correctly understood by RBridges
>in order to correctly forward STP BPDUs from one edge spanning 
>tree to other edge spanning trees is very complicated.  Also, in
>this case, the root RBridges should not be the same for all VLAN
>specific shortest path spanning trees.
>
>--
>Eric
>
> 
>--> >
>--> There is no problem as there is only one Designated Rbridge in 
>--> the bridges spanning tree, the only that forward frames to/from 
>--> that tree into the rbridges region. IMMO, the Designated Rbridge 
>--> should act as Root bridge of the bridges spanning tree, so the
>--> path is optimum to all bridges of that tree.
>--> 
>[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 14 Oct 2005 21:18:57 -0300
Subject: Re: [rbridge] seeking	input	on	abstractfor	problemand	applicabili	tystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1437

Guillermo,

	I agree with your comments to Joe, but I want to expand
on the last comment that you made (included below).

	One of the big problems with assuming that STP is used
across the entire RBridge campus is that this doesn't allow
us to take advantage of things we know now that were not known 
when STP was designed.  For example, VLANs.

	One of the proposals for creating a shortest path spanning
tree within the campus is to allow a spanning tree per VLAN.  A
set of 802 bridges cannot do that.  However, it is incredibly 
likely that small spanning trees at the edge of a campus will 
have significant non-intersecting VLAN membership.  This implies 
that there is a potentially significant benefit from having per
VLAN shortest path spanning trees within the RBridge campus.  In
this case, topology that must be correctly understood by RBridges
in order to correctly forward STP BPDUs from one edge spanning 
tree to other edge spanning trees is very complicated.  Also, in
this case, the root RBridges should not be the same for all VLAN
specific shortest path spanning trees.

--
Eric

--> >
--> There is no problem as there is only one Designated Rbridge in 
--> the bridges spanning tree, the only that forward frames to/from 
--> that tree into the rbridges region. IMMO, the Designated Rbridge 
--> should act as Root bridge of the bridges spanning tree, so the
--> path is optimum to all bridges of that tree.
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 14 Oct 2005 20:56:46 -0300
Subject: Re: [rbridge] seeking input on abstract	for problem and applicabi	lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 15178

Joe,

	You said: The edges are individual spanning trees. The rbridge 
	can have more than one internal path between two edge trees, 
	but that's it, that's all the redundency that's provided. 
	Turning off ports on the outside edge of the rbridge has no 
	effect on the internal multipath potential.

	And then later, you also said: Yes [STP would be disabled by 
	default]. And not to forward ingress frames until internal 
	routing (IS-IS in this case) is established. At that point, 
	STP should be enabled at the 'edges', STP PARTICIPATEd, and 
	-then- ingress enabled.

	What's the problem?

"Internal" and "external" are not meaningful terms.  How would an
RBridge distinguish an "internal" bridge from an "external" bridge?
You suggest that this would occur as a result of recognizing that
another RBridge exists on the local bridged network.  That appears
to assume that the only way to keep RBridges from being part of the
same campus is to put a router between them.  That - in turn - has
some interesting implications with respect to colocation of router
and RBridge functionality.

The key reason why I don't think that the presence of other RBridge 
on a port makes it an "internal" port is that there is a distinction
between reaching other RBridges in certain extended topologies and
reaching them in other densely interconnected topologies.  But that
may simply be a terminology issue.

The same applies to "ingress" and "edge".

But there's a larger issue.  I am not at all convinced that it is
ever necessary to differentiate the behavior of "internal" verses
"external" interfaces.  Consequently, I think it is an unecessary
complication, especially given that - if it is indeed based on the
presence of another RBridge on the same link - it is something that
can change very quickly, causing an RBridge to change operational
modes.  There's no reason I can see for taking on the additional 
complexity.

	You also said: Rbridges have nothing to do with the convergence 
	of the spanning tree external to them, IMO. All they do is have 
	their INTERNAL routing converge faster than spanning tree would
	have - that's where the benefit comes from. I never thought it 
	had anything to do with an effect on the external trees.

	And then later said: That's an interesting question - [a longer 
	initial convergence time] may be the result of having an internal 
	routing protocol that isn't setup ahead of time. [That is], maybe
	rbridges DO take longer to *initially* converge the STP of an 
	existing net, but react faster *afterwards* to changes.

This is only true if RBridges do not participate in STP with the
bridges in a local bridged network. If they do participate, then
the STP will not converge until after the RBridges have determined
forwarding paths among themselves, which will not occur until any
bridges between RBridges have converged on their STP.

So, the bridges between RBridges do STP.  The links between RBridges
come up.  The RBridges "hello" each other, peer, exchange link state
and reachability information, and then announce a topology change to
at least all ports that they have not heard other RBridges on (though
this is not sufficient, let's assume for simplicity that it is).  Now
the bridges on the affected links re-start STP - only now the network
of bridges is very much larger, because it includes at least bridges
that hang off of the RBridge's peer's other interfaces.

How is it that this does not take longer than if the RBridges didn't
exist?  Also, there appears to be a misconception that STP takes a
long time in comparison with routing.  Given that STP must complete 
before routing can begin, this is a bit of a misleading concern, at
best.

Let's take a specific case: An "internal" bridge goes down, taking
one or more links between RBridges with it.  The RBridges lose a
forwarding path and make the corresponding LSDB updates. Further,
let's assume that this partitions the RBridge campus temporarily.

The link is redundant, so a neighbor will announce a topology change 
and STP will re-run to switch port forwarding states so that the 
redundant path is now available.  

The link returns and IS-IS reconverges.  Now the RBridges might be 
clever and recognize that the net change (no pun intended) is NIL - 
assuming that all of this happened fast enough that the RBridges
have not previously announced a topology change to "external" bridges.

In this case, nothing else happens.  

However, let's assume that the re-establishment of the "internal" 
link did not happen fast enough.  In that case, the "external" 
bridges will see two topology change notifications and STP will be 
run each time.  If the second topology change occurs before the STP 
completes for the first topology change, it will be as if the whole 
system is being restarted from scratch.

	You also said: [STP convergence is] just like adding a bridge 
	to an existing bridged system. The new bridge doesn't forward 
	frames until STP finishes, but the existing bridges can finish 
	just fine. The rbridge is the 'new' bridge. 

	All the other bridges are the existing bridge system. No chicken 
	and egg, AFAICT; the sequence is determined by rbridge's reliance 
	on bridges.

I think that in this case (and maybe in others) we're not talking
about the same kind of convergence problem. I am talking about the
time that initial convergence takes and you're (apparently) talking 
about the time it take to re-converge after a minor topology change.

Also, STP convergence - as explained above - is different if a 
bridge goes down.

I think - even so - that there's a flaw in your reasoning that is
based on a mistaken assumption that you specifically state below.

	Also, you said: Again, I'm back to 'what would a bridge do'. 
	Either this is a bridge (PARTICIPATE) or a link (e.g., hub, 
	which means TRANSPARENT). Those are the only two options that 
	have correlaries in existing L2.

That's simply not true.  Hosts exist at L2.  Routers exist at L2.
Neither of them do either of these.

	Finally, you also said: [RBridges] can't make redundent paths 
	in the non-rbridge portion of an L2 net. They can only do so 
	within the rbridge.

This is a flawed assumption.

Note that even bridges can carry L2 traffic for more than one VLAN.
It's a simple matter - if you're starting from scratch to implement
a bridge - to allow an RBridge (for instance) to use one port in a
local bridged network to forward frames associated with one set of
VLANs, and another port in the same local bridged network to forward
frames associate with another set of VLANs.

Also note that there is no possibility of looping traffic introduced
by this behavior.

Also note that the same would obviously apply if another RBridge
in the same RBridge campus had a port in the same local bridged
network.

Participation in the local STP would mean that the local bridges 
would determine that the RBridge campus had a redundant path.  As
a result, certain of the local bridges would put their ports in a
non-forwarding mode - making use of the redundant path impossible.

Clearly this can be applied to other mechanisms for differentiating
frame-streams than by VLAN-ID, but it should be sufficient to show
a single example of when participating in local STP is a bad idea.

Finally, note once again that all of this applies equally to both
"internal" and "external" ports.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Friday, October 14, 2005 5:15 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstract for problemand
--> applicabil itystatement
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier, you said:

Gray, Eric wrote:
> Joe,
> 
> 	I want to address specific comments/questions you 
> had below:
> 
> -> All of this sounds like stuff the rbridge already 
>    needs to do; there needs to be an internal spanning 
>    tree anyway.
> 
> We have not yet decided how many "spanning trees" there
> needs to be, and that is a part of the problem.  One of
> the goals of the original proposal - as I understand it
> - was to allow efficient use of redundant links that may 
> exist between RBridges.  
> 
> This is why the confusion keeps coming up with the use 
> of the term spanning tree.  Its NOT the right term in 
> the RBridge context, because the RBridges WILL NOT be
> turning ports off and WILL be forwarding distinguishable
> streams of frames on as many of the available links as 
> it makes sense to use, given the destinations and - for
> example - VLAN contexts that apply to each stream.

I'm not sure I agree. The edges are individual spanning trees. The
rbridge can have more than one internal path between two edge trees, but
that's it, that's all the redundency that's provided. Turning off ports
on the outside edge of the rbridge has no effect on the internal
multipath potential.

> Another goal - again as I understand it - is to reduce
> the time for convergence on spanning trees for those
> portions of the network that MUST use STP (the bridges).
> For that goal to be achieved, it is a good idea not to
> extend STP across the RBridges.

I definitely disagree with this. Rbridges have nothing to do with the
convergence of the spanning tree external to them, IMO. All they do is
have their INTERNAL routing converge faster than spanning tree would
have - that's where the benefit comes from. I never thought it had
anything to do with an effect on the external trees.

> Finally, there is a huge "chicken-and-egg" problem with
> any intention to have RBridges participate in STP.
> 
> The "spanning tree(s)" determined by RBridges are the
> result of shortest path analysis of reachability info
> provided by IS-IS.  If this is not the case, then there
> was never any reason to suggest using a shortest-path,
> Link State Routing Protocol in the first place.
> 
> However, before the RBridges can reliably determine
> link state and advertise reachability, any "internal"
> bridges MUST have already determined a spanning tree
> (using STP).  As I pointed out previously, and Radia
> stated as well, bridges typically do not forward during 
> STP, consequently some or all of the links between the
> RBridges will be DOWN as far as IS-IS is concerned.

That's just like adding a bridge to an existing bridged system. The new
bridge doesn't forward frames until STP finishes, but the existing
bridges can finish just fine. The rbridge is the 'new' bridge. All the
other bridges are the existing bridge system. No chicken and egg,
AFAICT; the sequence is determined by rbridge's reliance on bridges.

> Also, again as pointeed out previously, "internal" and 
> "external" are topologically meaningless terms as far 
> as RBridges are concerned - unless that information is
> explicitly configured.  Consequently, default RBridge
> behavior really MUST be to ignore STP on any port not
> explicitly configured to participate in STP.

Yes. And not to forward ingress frames until internal routing (IS-IS in
this case) is established. At that point, STP should be enabled at the
'edges', STP PARTICIPATEd, and -then- ingress enabled.

What's the problem?

> Also, because the link state between RBridges is not
> determined until after any internal STP required has
> been completed between bridges that may be involved 
> in those links, either the RBridges have to wait a
> pre-determined period of time (to blindly allow for 
> "internal" STP) or send topology change BPDUs on all 
> ports every time they discover new links. Either way 
> will result in potentially huge delays in overall STP 
> convergence time for the network.

Again, I'm back to 'what would a bridge do'. Either this is a bridge
(PARTICIPATE) or a link (e.g., hub, which means TRANSPARENT). Those are
the only two options that have correlaries in existing L2.

> -> I'd like someone to explain which of these are valid 
>    if we replace the rbridge campus with an existing 
>    bridge.
> 
> I am not sure that this concept of a "virtual bridge"
> is - or ever has been - a goal for RBridges.

It's not a goal; it's a definition, IMO.

> If you 
> want a "virtual bridge", one approach that already is
> out there is VPLS.  Consequently, why would we need
> to specify how to do it with RBridges?

VPLS, depending on where I look, are either pseudowires (virtual hubs)
or L2 over L3. Rbridge is L2 over L2 with routing.

> If it is not a goal, then the notion of replacing an
> RBridge with a single bridge is not something we need
> to consider.
> 
> -> My understanding is that PARTICIPATE is valid, if not 
>    required. TRANSPARENT seems like it turns the bridge 
>    into a hub. And BLOCK would break things.
> 
> Assuming that this _is_ a goal, there is no particular
> reason why someone would not replace a hub (even a 
> "virtual hub") with a bridge.  For reasons explained
> above, however, PARTICIPATE - while potentially valid
> - is extremely undesirable.

If you replace a hub with a bridge that refuses to PARTICIPATE, what's
the effect? Nothing. That assumes that hubs weren't in rings, which they
weren't supposed to be.

However, you CAN wire bridges in rings and they're supposed to do the
right thing. That's only because they PARTICIPATE, though.

> Transparent also is not good because the path through
> the RBridges will not exist (or not be complete) until 
> A) STP is completed between any "internal" bridges and 
> B) the RBridges have converged on a complete LSDB and 
> determine SPSTs (shortest path spanning trees).

I already answered this in a separate email; yes, both of these steps
need to happen in order, and they will.

> So, even with Transparent, the insertion of RBridges
> would result in increased STP convergence time, even
> if the network size has not changed.

That's an interesting question - that may be the result of having an
internal routing protocol that isn't setup ahead of time. I.e., maybe
rbridges DO take longer to *initially* converge the STP of an existing
net, but react faster *afterwards* to changes.

> In addition, TRANSPARENT would require configuration
> of the RBridges to recognize "external" interfaces -

The need to know which interfaces they can reach rbridges on, which can
(and should) be autoconfigured.

> since it is clearly not the case that, even in this 
> mode, you would want bridges inside an RBridge campus
> to participate with bridges outside that campus.  As
> implied previously, having all bridges - both inside
> and outside of an RBridge campus - participating in 
> forming a single spanning tree would prevent using
> redundant paths (and would very likely drop RBridge
> ports out of the topology as the corresponding bridge
> ports - at the other end of the physical link - are
> put in the non-forwarding state).

I also already answered this - rbridges can't make redundent paths in
the non-rbridge portion of an L2 net. They can only do so within the
rbridge.

Joe

Date: Sat, 15 Oct 2005 01:34:35 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seekinginput	on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1594

Joe Touch wrote:

>Guillermo Ib??ez wrote:
>  
>
>>Guillermo Ib??ez wrote:
>> 
>>OK. So the designated Rbridge should act as root bridge of that spanning 
>>tree, for a shortest path to all bridges of spanning trees.
>>    
>>
>
>To do that, it would need to emit BPDUs to all edge trees to announce it
>was the root, wouldn't it? Only then could it KNOW that the ingresses it
>expects from each spanning tree would be the ones used (e.g., for those
>attached multiple times).
>
>(which would be back to PARTICIPATE)
>
>  
>
>Joe
>
>  
>
Sorry, I did not follow the whole discussion. My understanding is that 
rbridges can participate in the spanning tree they are attached to but 
do not forward BPDUs. Each port emits BPDUs based solely on its port 
information, opposite to the standard  operation ,  where the bridge 
builds the BPDUs to be transmitted  based on information collected from 
all bridge ports and selecting the best BPDU, thus conveyed the distance 
to root bridge. I would call this mode PARTICIPATE PER PORT.
Rbridge ports should announce themselves as designated ports of  Rbridge 
(root). The Rbridge ports will be in role Designated if the win the 
competition in the link or in Back-Up or Alternate role (that means 
blocked) if they lost the competition of best BPDU heard in the local 
link.  They would never be in  Root port role.
Guillermo

>------------------------------------------------------------------------
>
>[email-masked]

Date: Sat, 15 Oct 2005 01:02:14 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking	input	on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3796

Guillermo Ib??ez wrote:

Joe Touch wrote:

>Guillermo Ib??ez wrote:
>  
>
>>I am not sure I interpreted the terms right. My understanding is that 
>>rbridges must participate  in the spanning tree. This is required to 
>>avoid loops  if two links of same network get attached to same rbridge. 
>>But rbridges must act as hosts,
>>    
>>
>
>I have always disagreed with that assertion.
>
>To the outside of the network:
>
>I thought they would always act as if a single bridge (meaning
>PARTICIPATE); I understand now how they might act as if a single
>hub/link (TRANSPARENT).
>
>To bridges they send encapsulated packets over, the ingress rbridges
>look like hosts, but that's only to transit the L2.
>
>  
>
>>should not
>>forward received BPDUs to other ports of rbridge, as it is much more  
>>efficient and faster to converge, to have many small spanning trees than 
>>a big one.
>>    
>>
>
>I agree with that, except that this argues that existing bridges should
>act in the same way. But they don't. I'm not sure they can.
>
>  
>
I do not see the point. Existing bridges should forward their spanning 
tree BPDUs. Tree extends till a link terminates in an Rbridge.

>>Trying to emulate MSTP and combine STP with rbridges (a la CIST) is a 
>>path to complexity, opposite to selfconfiguration.
>>    
>>
>
>Manual configuration is the opposite of selfconfiguration.
>Selfconfiguration does not prohibit complexity, provided the complexity
>can be selfconfigured - which I think it can.
>
>  
>
I agree, but I does not look easy to obtain selconfiguration. Linking 
spanning trees with the rbridges network creates dependencies in 
transitions in case of reconfigurations.  Linking spanning trees 802.1D 
with the rbridge protocol increases the risks of interference between 
protocols.

>>See below my comment on loops with broadcast frames.
>>    
>>
>...
>  
>
>>>How do I know they're disjoint trees, and what happens if (when) they
>>>get interconnected?
>>>
>>>If a spanning tree is attached to the rbridge in more than one place,
>>>what happens with broadcasts? Won't they create a loop?
>>>      
>>>
>>If there are two attachments to the same spanning tree to the same 
>>rbridge one of them acts as designated port and the other will be
>>blocked by the spanning tree protocol.
>>    
>>
>
>The only reason it'd be blocked is if the spanning tree protocol knew
>both rbridges were part of the same spanning tree. I thought that's what
>the BPDUs would indicate.
>
>  
>
>>Participation in STP is needed 
>>for that.
>>    
>>
>
>That's what I thought - but that requires PARTICIPATE, right?
>  
>

>I see the potential problem you mention with the attachment of spanning 
>tree to /different/ rbridges
>  
>
>
>In the same campus? Why does that matter?
>
>  
>
>>with broadcast  frames. An rbridge receives 
>>the broadcast frame from the spanning tree, encapsulates it with the 
>>all_rbridges_multicast address and forwards to all rbridges.
>>    
>>
>
>The same would happen to all ports on a single rbridge, though.
>
>  
>
>>The frame 
>>is received by an rbridge of the same spanning tree, decapsulated and 
>>retransmitted to same spanning tree. Do I miss something?
>>Guillermo
>>    
>>
>
>That's what I think happens too.
>
>  
>
There is no problem as there is only one Designated Rbridge in the 
bridges spanning tree, the only that forward frames to/from that tree 
into the rbridges region. IMMO, the Designated Rbridge should act as 
Root bridge of the bridges spanning tree, so the path is optimum to all 
bridges of that tree.

>Joe
>
>  
>
>------------------------------------------------------------------------
>
>[email-masked]

Content-class: urn:content-classes:message
Date: Fri, 14 Oct 2005 15:49:09 -0700
From: "Michael Smith \(michsmit\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] seekinginput	on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1016

> From: [email-masked] 
> 
> Saikat Ray wrote:
> > I see the potential problem you mention with the attachment of 
> > spanning tree to /different/ rbridges with broadcast  frames. An 
> > rbridge receives the broadcast frame from the spanning tree, 
> > encapsulates it with the all_rbridges_multicast address and 
> forwards 
> > to all rbridges. The frame is received by an rbridge of the same 
> > spanning tree, decapsulated and retransmitted to same 
> spanning tree. Do I miss something?
> > Guillermo
> > 
> > [Saikat] Only one of the RBridges would be *designated* to 
> encapsulate 
> > the packets from and decapsulate the packets to that spanning tree.
> 
> Designated works for decapsulation, since the rbridge can 
> control that.
> 
> How does the rbridge campus control which ingress is used if 
> the spanning tree touches it multiple times?

I would expect it would be the same way.  Only the designated rbridge
accepts the packet.

Michael

> Joe

Date: Fri, 14 Oct 2005 15:34:47 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seekinginput	on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1201

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB9D991D5B4447FB83E4CAF8B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Guillermo Ib=E1=F1ez wrote:
> Guillermo Ib=E1=F1ez wrote:
> =20
> OK. So the designated Rbridge should act as root bridge of that spannin=
g=20
> tree, for a shortest path to all bridges of spanning trees.

To do that, it would need to emit BPDUs to all edge trees to announce it
was the root, wouldn't it? Only then could it KNOW that the ingresses it
expects from each spanning tree would be the ones used (e.g., for those
attached multiple times).

(which would be back to PARTICIPATE)

Joe

--------------enigB9D991D5B4447FB83E4CAF8B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigB9D991D5B4447FB83E4CAF8B--

Date: Fri, 14 Oct 2005 15:33:16 -0700
From: Joe Touch <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seekinginput	on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1485

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE7A7203E3879955AB3DC3078
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Saikat Ray wrote:
> I see the potential problem you mention with the attachment of spanning 
> tree to /different/ rbridges with broadcast  frames. An rbridge receives 
> the broadcast frame from the spanning tree, encapsulates it with the 
> all_rbridges_multicast address and forwards to all rbridges. The frame 
> is received by an rbridge of the same spanning tree, decapsulated and 
> retransmitted to same spanning tree. Do I miss something?
> Guillermo
> 
> [Saikat] Only one of the RBridges would be *designated* to encapsulate the
> packets from and decapsulate the packets to that spanning tree.

Designated works for decapsulation, since the rbridge can control that.

How does the rbridge campus control which ingress is used if the
spanning tree touches it multiple times?

Joe

--------------enigE7A7203E3879955AB3DC3078
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigE7A7203E3879955AB3DC3078--

Date: Fri, 14 Oct 2005 15:30:15 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking	input	on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3337

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8CE0FB118C111118E40B6595
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Guillermo Ib=E1=F1ez wrote:
> I am not sure I interpreted the terms right. My understanding is that=20
> rbridges must participate  in the spanning tree. This is required to=20
> avoid loops  if two links of same network get attached to same rbridge.=
=20
> But rbridges must act as hosts,

I have always disagreed with that assertion.

To the outside of the network:

I thought they would always act as if a single bridge (meaning
PARTICIPATE); I understand now how they might act as if a single
hub/link (TRANSPARENT).

To bridges they send encapsulated packets over, the ingress rbridges
look like hosts, but that's only to transit the L2.

> should not
> forward received BPDUs to other ports of rbridge, as it is much more =20
> efficient and faster to converge, to have many small spanning trees tha=
n=20
> a big one.

I agree with that, except that this argues that existing bridges should
act in the same way. But they don't. I'm not sure they can.

> Trying to emulate MSTP and combine STP with rbridges (a la CIST) is a=20
> path to complexity, opposite to selfconfiguration.

Manual configuration is the opposite of selfconfiguration.
Selfconfiguration does not prohibit complexity, provided the complexity
can be selfconfigured - which I think it can.

> See below my comment on loops with broadcast frames.
=2E..
>>How do I know they're disjoint trees, and what happens if (when) they
>>get interconnected?
>>
>>If a spanning tree is attached to the rbridge in more than one place,
>>what happens with broadcasts? Won't they create a loop?
>=20
> If there are two attachments to the same spanning tree to the same=20
> rbridge one of them acts as designated port and the other will be
> blocked by the spanning tree protocol.

The only reason it'd be blocked is if the spanning tree protocol knew
both rbridges were part of the same spanning tree. I thought that's what
the BPDUs would indicate.

> Participation in STP is needed=20
> for that.

That's what I thought - but that requires PARTICIPATE, right?

> I see the potential problem you mention with the attachment of spanning=
=20
> tree to /different/ rbridges

In the same campus? Why does that matter?

> with broadcast  frames. An rbridge receives=20
> the broadcast frame from the spanning tree, encapsulates it with the=20
> all_rbridges_multicast address and forwards to all rbridges.

The same would happen to all ports on a single rbridge, though.

> The frame=20
> is received by an rbridge of the same spanning tree, decapsulated and=20
> retransmitted to same spanning tree. Do I miss something?
> Guillermo

That's what I think happens too.

Joe

--------------enig8CE0FB118C111118E40B6595
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig8CE0FB118C111118E40B6595--

Date: Sat, 15 Oct 2005 00:01:31 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seekinginput	on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1737

Guillermo Ib??ez wrote:
 
OK. So the designated Rbridge should act as root bridge of that spanning 
tree, for a shortest path to all bridges of spanning trees.

Saikat Ray wrote:

>I see the potential problem you mention with the attachment of spanning 
>tree to /different/ rbridges with broadcast  frames. An rbridge receives 
>the broadcast frame from the spanning tree, encapsulates it with the 
>all_rbridges_multicast address and forwards to all rbridges. The frame 
>is received by an rbridge of the same spanning tree, decapsulated and 
>retransmitted to same spanning tree. Do I miss something?
>Guillermo
>
>[Saikat] Only one of the RBridges would be *designated* to encapsulate the
>packets from and decapsulate the packets to that spanning tree.
>
>  
>
>> 
>>
>>    
>>
>>>The
>>>worst it can do is change the routes because you get two STP trees each
>>>with different root bridges ... which is not always ideal and why I
>>>think you need TRANSPARENT AND BLOCK options at different phases of a
>>>migration ... and possibly even Ships in the Night mode too.
>>>   
>>>
>>>      
>>>
>>SITN assumes some level of manual configuration - you have to know which
>>ship you're on ;-)
>>
>>Joe
>> 
>>
>>------------------------------------------------------------------------
>>
>>[email-masked]
>[email-masked]
>[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 14 Oct 2005 18:58:40 -0300
Subject: Re: [rbridge] seeking	inputon	abstractfor	problemand	applicabilit	ystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 844

Joe,

	You said: [Even] if each edge is its own tree, it can 
	touch the rbridge in more than one place (if not, why not?)

	It seems like the internal spanning tree needs to 'pick' 
	one of those tree attachment points to join to, so that 
	one overall tree is picked.

	But that's back to PARTICIPATE rather than BLOCK.

No. See earlier mail.  Please.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Friday, October 14, 2005 4:55 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking inputon abstractfor problemand
--> applicabilitystatement
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 14 Oct 2005 18:55:36 -0300
Subject: Re: [rbridge] seeking input on	abstractfor	problemand	applicabili	tystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3286

Joe,

	You said: I'm not sure whether the 802 specs allow for 
	a non-hub device to not participate in the spanning tree 
	alg. Anyone else know?

The 802 specs mostly address Ethernet forwarding and bridge
behavior for STP.  A lot of bridge behavior (like the entire
section on bridge learning) was removed in more recent versions
of the specification.  As an aside, the reason I know this is
that we (Cabletron at that time) had filed a patent application
that listed the removed text as "prior art" and - consequently
- had to dig up a prior version to hand over to the USPTO.

As pointed out by Dino earlier, irrespective of what 802 says,
many implementations allow STP to be turned off for specific
bridge ports.  Clearly this can work.

	You also asked: If a spanning tree is attached to the 
	rbridge in more than one place, what happens with 
	broadcasts? Won't they create a loop?

Radia had earlier answered this question for me though it may
have been in an unrecognizably similar form.  I had asked what
would happen if I deploy one RBridge into a network that does
not segment it.  Note that this is an isomorphism of the situ
you ask about.

The answer turns out to be straight forward.  RBridges do not 
have to completely ignore STP, so an RBridge can determine it
has more than one port on the same local bridged network (Erik
was uncomfortable with referring to it as a "local broadcast
domain"). Also, even if it does not do this, the RBridge will
hear its own hello messages on different interfaces - allowing
it to conclude that it has more than one interface on the same
local bridged network.

Note that - like bridges during STP - RBridges SHOULD not be
forwarding frames until they have determined how to do so.

Note that the same observation applies whether the interfaces
for which this is true are "internal" or "external" to the
RBridge campus.

Once the RBridge has determined that it has more than one port
in the same local briged network, then what it does next will
depend on whether it "hears" another RBridge on that same local
bridged network.  

Note that - again - this could occur for either the "internal" 
or "external" case, since nothing exists to preclude connecting 
one RBridge campus to another.

If the RBridge hears one or more additional RBridges on the same
port, then it will determine appropriate SPST paths via routing
protocol interactions with that (or those) other RBridge(s). If
it does not, then it may decide to only forward broadcast frames
on one of those interfaces - either way - thus preventing loops
in broadcast/multicast traffic, or it might do something clever
(that we do not need to specify in this context).  It is enough
to show that there is a single proof of concept way in which to
prevent looping broadcast frames.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Friday, October 14, 2005 4:50 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstractfor problemand
--> applicabilitystatement
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Fri, 14 Oct 2005 14:46:20 -0700
From: "Drake, John E" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 297

> 
> So I see no advantage in RBridges forwarding spanning tree messages.
In
> contrast, the
> advantage of having them discard them is that then the little spanning
> trees formed by
> bridged islands are smaller, and independent of each other.
[JD] 

When they get older, will they get bigger?

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 14 Oct 2005 17:42:48 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] seekinginput	on	abstractfor	problemand	applicabilitystatement
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1336

I see the potential problem you mention with the attachment of spanning 
tree to /different/ rbridges with broadcast  frames. An rbridge receives 
the broadcast frame from the spanning tree, encapsulates it with the 
all_rbridges_multicast address and forwards to all rbridges. The frame 
is received by an rbridge of the same spanning tree, decapsulated and 
retransmitted to same spanning tree. Do I miss something?
Guillermo

[Saikat] Only one of the RBridges would be *designated* to encapsulate the
packets from and decapsulate the packets to that spanning tree.

>  
>
>>The
>>worst it can do is change the routes because you get two STP trees each
>>with different root bridges ... which is not always ideal and why I
>>think you need TRANSPARENT AND BLOCK options at different phases of a
>>migration ... and possibly even Ships in the Night mode too.
>>    
>>
>
>SITN assumes some level of manual configuration - you have to know which
>ship you're on ;-)
>
>Joe
>  
>
>------------------------------------------------------------------------
>
>[email-masked]
[email-masked]

Date: Fri, 14 Oct 2005 23:36:00 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input	on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3274

I am not sure I interpreted the terms right. My understanding is that 
rbridges must participate  in the spanning tree. This is required to 
avoid loops  if two links of same network get attached to same rbridge. 
But rbridges must act as hosts, should not
forward received BPDUs to other ports of rbridge, as it is much more  
efficient and faster to converge, to have many small spanning trees than 
a big one.
Trying to emulate MSTP and combine STP with rbridges (a la CIST) is a 
path to complexity, opposite to selfconfiguration.
See below my comment on loops with broadcast frames.

Joe Touch wrote:

>Peter Ashwood-Smith wrote:
>  
>
>>>My understanding is that PARTICIPATE is valid, if not required.
>>>      
>>>
>>TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would
>>break things.
>>
>>  PARTICIPATE is definitely valid, but I disagree it is always required.
>>Its definitely useful though. It is only always required if both of
>>TRANSPARENT and BLOCK do not work.
>> 
>>  Yup, TRANSPARENT turns the rbridge network into a hub therefore it is
>>also valid with different trade-offs. Therefore PARTICIPATE is not
>>always required it is simply valid.
>>    
>>
>
>The only reason I could imagine a difference in requirement is that a
>hub broadcasts everything, so 'TRANSPARENT' is consistent with how it
>handles other frames.
>
>I'm not sure whether the 802 specs allow for a non-hub device to not
>participate in the spanning tree alg. Anyone else know?
>  
>
>(i.e., this might be a spec equivalance issue)
>
>  
>
>>  BLOCK will break things? How. I think I've convinced myself this is
>>not possible in the steady state (because you have nodally disjoint
>>trees joined by a single link therefore a loop is not possible).
>>    
>>
>
>How do I know they're disjoint trees, and what happens if (when) they
>get interconnected?
>
>If a spanning tree is attached to the rbridge in more than one place,
>what happens with broadcasts? Won't they create a loop?
>  
>
If there are two attachments to the same spanning tree to the same 
rbridge one of them acts as designated port and the other will be 
blocked by the spanning tree protocol. Participation in STP is needed 
for that.
I see the potential problem you mention with the attachment of spanning 
tree to /different/ rbridges with broadcast  frames. An rbridge receives 
the broadcast frame from the spanning tree, encapsulates it with the 
all_rbridges_multicast address and forwards to all rbridges. The frame 
is received by an rbridge of the same spanning tree, decapsulated and 
retransmitted to same spanning tree. Do I miss something?
Guillermo

>  
>
>>The
>>worst it can do is change the routes because you get two STP trees each
>>with different root bridges ... which is not always ideal and why I
>>think you need TRANSPARENT AND BLOCK options at different phases of a
>>migration ... and possibly even Ships in the Night mode too.
>>    
>>
>
>SITN assumes some level of manual configuration - you have to know which
>ship you're on ;-)
>
>Joe
>  
>
>------------------------------------------------------------------------
>
>[email-masked]

Date: Fri, 14 Oct 2005 14:15:17 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract	for	problemand	applicabil itystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7958

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2CFDAAF7052D2A866908C380
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Gray, Eric wrote:
> Joe,
> 
> 	I want to address specific comments/questions you 
> had below:
> 
> -> All of this sounds like stuff the rbridge already 
>    needs to do; there needs to be an internal spanning 
>    tree anyway.
> 
> We have not yet decided how many "spanning trees" there
> needs to be, and that is a part of the problem.  One of
> the goals of the original proposal - as I understand it
> - was to allow efficient use of redundant links that may 
> exist between RBridges.  
> 
> This is why the confusion keeps coming up with the use 
> of the term spanning tree.  Its NOT the right term in 
> the RBridge context, because the RBridges WILL NOT be
> turning ports off and WILL be forwarding distinguishable
> streams of frames on as many of the available links as 
> it makes sense to use, given the destinations and - for
> example - VLAN contexts that apply to each stream.

I'm not sure I agree. The edges are individual spanning trees. The
rbridge can have more than one internal path between two edge trees, but
that's it, that's all the redundency that's provided. Turning off ports
on the outside edge of the rbridge has no effect on the internal
multipath potential.

> Another goal - again as I understand it - is to reduce
> the time for convergence on spanning trees for those
> portions of the network that MUST use STP (the bridges).
> For that goal to be achieved, it is a good idea not to
> extend STP across the RBridges.

I definitely disagree with this. Rbridges have nothing to do with the
convergence of the spanning tree external to them, IMO. All they do is
have their INTERNAL routing converge faster than spanning tree would
have - that's where the benefit comes from. I never thought it had
anything to do with an effect on the external trees.

> Finally, there is a huge "chicken-and-egg" problem with
> any intention to have RBridges participate in STP.
> 
> The "spanning tree(s)" determined by RBridges are the
> result of shortest path analysis of reachability info
> provided by IS-IS.  If this is not the case, then there
> was never any reason to suggest using a shortest-path,
> Link State Routing Protocol in the first place.
> 
> However, before the RBridges can reliably determine
> link state and advertise reachability, any "internal"
> bridges MUST have already determined a spanning tree
> (using STP).  As I pointed out previously, and Radia
> stated as well, bridges typically do not forward during 
> STP, consequently some or all of the links between the
> RBridges will be DOWN as far as IS-IS is concerned.

That's just like adding a bridge to an existing bridged system. The new
bridge doesn't forward frames until STP finishes, but the existing
bridges can finish just fine. The rbridge is the 'new' bridge. All the
other bridges are the existing bridge system. No chicken and egg,
AFAICT; the sequence is determined by rbridge's reliance on bridges.

> Also, again as pointeed out previously, "internal" and 
> "external" are topologically meaningless terms as far 
> as RBridges are concerned - unless that information is
> explicitly configured.  Consequently, default RBridge
> behavior really MUST be to ignore STP on any port not
> explicitly configured to participate in STP.

Yes. And not to forward ingress frames until internal routing (IS-IS in
this case) is established. At that point, STP should be enabled at the
'edges', STP PARTICIPATEd, and -then- ingress enabled.

What's the problem?

> Also, because the link state between RBridges is not
> determined until after any internal STP required has
> been completed between bridges that may be involved 
> in those links, either the RBridges have to wait a
> pre-determined period of time (to blindly allow for 
> "internal" STP) or send topology change BPDUs on all 
> ports every time they discover new links. Either way 
> will result in potentially huge delays in overall STP 
> convergence time for the network.

Again, I'm back to 'what would a bridge do'. Either this is a bridge
(PARTICIPATE) or a link (e.g., hub, which means TRANSPARENT). Those are
the only two options that have correlaries in existing L2.

> -> I'd like someone to explain which of these are valid 
>    if we replace the rbridge campus with an existing 
>    bridge.
> 
> I am not sure that this concept of a "virtual bridge"
> is - or ever has been - a goal for RBridges.

It's not a goal; it's a definition, IMO.

> If you 
> want a "virtual bridge", one approach that already is
> out there is VPLS.  Consequently, why would we need
> to specify how to do it with RBridges?

VPLS, depending on where I look, are either pseudowires (virtual hubs)
or L2 over L3. Rbridge is L2 over L2 with routing.

> If it is not a goal, then the notion of replacing an
> RBridge with a single bridge is not something we need
> to consider.
> 
> -> My understanding is that PARTICIPATE is valid, if not 
>    required. TRANSPARENT seems like it turns the bridge 
>    into a hub. And BLOCK would break things.
> 
> Assuming that this _is_ a goal, there is no particular
> reason why someone would not replace a hub (even a 
> "virtual hub") with a bridge.  For reasons explained
> above, however, PARTICIPATE - while potentially valid
> - is extremely undesirable.

If you replace a hub with a bridge that refuses to PARTICIPATE, what's
the effect? Nothing. That assumes that hubs weren't in rings, which they
weren't supposed to be.

However, you CAN wire bridges in rings and they're supposed to do the
right thing. That's only because they PARTICIPATE, though.

> Transparent also is not good because the path through
> the RBridges will not exist (or not be complete) until 
> A) STP is completed between any "internal" bridges and 
> B) the RBridges have converged on a complete LSDB and 
> determine SPSTs (shortest path spanning trees).

I already answered this in a separate email; yes, both of these steps
need to happen in order, and they will.

> So, even with Transparent, the insertion of RBridges
> would result in increased STP convergence time, even
> if the network size has not changed.

That's an interesting question - that may be the result of having an
internal routing protocol that isn't setup ahead of time. I.e., maybe
rbridges DO take longer to *initially* converge the STP of an existing
net, but react faster *afterwards* to changes.

> In addition, TRANSPARENT would require configuration
> of the RBridges to recognize "external" interfaces -

The need to know which interfaces they can reach rbridges on, which can
(and should) be autoconfigured.

> since it is clearly not the case that, even in this 
> mode, you would want bridges inside an RBridge campus
> to participate with bridges outside that campus.  As
> implied previously, having all bridges - both inside
> and outside of an RBridge campus - participating in 
> forming a single spanning tree would prevent using
> redundant paths (and would very likely drop RBridge
> ports out of the topology as the corresponding bridge
> ports - at the other end of the physical link - are
> put in the non-forwarding state).

I also already answered this - rbridges can't make redundent paths in
the non-rbridge portion of an L2 net. They can only do so within the
rbridge.

Joe

--------------enig2CFDAAF7052D2A866908C380
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig2CFDAAF7052D2A866908C380--

Date: Fri, 14 Oct 2005 13:54:55 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking	inputon	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2539

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig545E008B86EF181E7C3FCE4C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Ashwood-Smith wrote:
>>>I think I missed something, what breaks if we block BPDUs ?
> 
> 
>>If nothing, then lets. For bridges too.
>>Now what happens? (i.e., if bridges block BPDUs) - won't that kill the
> 
> spanning tree?
> 
>  Yes of course if you block a BPDU the bridge will stop the STP tree at
> that point. Thats exactly what we are trying to do. Stop the STP
> computed portion of the FULL tree at that point. 
>   
>  With BLOCK. Each protocol computes its own smaller part of the bigger
> spanning tree.
>  STP computes using BPDUS etc. and Rbridge computes using
> IS-IS/Krusal's.

Eve if each edge is its own tree, it can touch the rbridge in more than
one place (if not, why not?)

It seems like the internal spanning tree needs to 'pick' one of those
tree attachment points to join to, so that one overall tree is picked.
But that's back to PARTICIPATE rather than BLOCK.

>  When done you have a bunch of unconnected spanning trees which are made
> into one big tree by the designated rbridge concept i.e. single link.

The rbridge isn't acting like a link. It acts like a link in TRANSPARENT
mode; in that case, when one edge tree send a BPDU to the link, everyone
on the link (all the other edge trees) will receive it.

> To convince yourself that this really works. Draw an arbitrary tree on
> a piece of paper. Then draw another disjoint tree somewhere else on the
> paper. You can make one big tree by connecting any two of the points
> between the two trees and you cannot create a loop with single link.
> That is why BLOCK works.

The only way it'll work like a single link is in TRANSPARENT - consider
a spanning tree that touches the 'connecting link' (the rbridge) in more
than one place (which is valid). The reason the spanning tree would pick
only one of those to join is because of the BDPU messages.

Joe

--------------enig545E008B86EF181E7C3FCE4C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig545E008B86EF181E7C3FCE4C--

Date: Fri, 14 Oct 2005 13:50:12 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2398

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2A839AA38DEDE46A826D8662
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Ashwood-Smith wrote:
>>My understanding is that PARTICIPATE is valid, if not required.
> 
> TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would
> break things.
> 
>   PARTICIPATE is definitely valid, but I disagree it is always required.
> Its definitely useful though. It is only always required if both of
> TRANSPARENT and BLOCK do not work.
>  
>   Yup, TRANSPARENT turns the rbridge network into a hub therefore it is
> also valid with different trade-offs. Therefore PARTICIPATE is not
> always required it is simply valid.

The only reason I could imagine a difference in requirement is that a
hub broadcasts everything, so 'TRANSPARENT' is consistent with how it
handles other frames.

I'm not sure whether the 802 specs allow for a non-hub device to not
participate in the spanning tree alg. Anyone else know?

(i.e., this might be a spec equivalance issue)

>   BLOCK will break things? How. I think I've convinced myself this is
> not possible in the steady state (because you have nodally disjoint
> trees joined by a single link therefore a loop is not possible).

How do I know they're disjoint trees, and what happens if (when) they
get interconnected?

If a spanning tree is attached to the rbridge in more than one place,
what happens with broadcasts? Won't they create a loop?

> The
> worst it can do is change the routes because you get two STP trees each
> with different root bridges ... which is not always ideal and why I
> think you need TRANSPARENT AND BLOCK options at different phases of a
> migration ... and possibly even Ships in the Night mode too.

SITN assumes some level of manual configuration - you have to know which
ship you're on ;-)

Joe

--------------enig2A839AA38DEDE46A826D8662
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig2A839AA38DEDE46A826D8662--

Date: Fri, 14 Oct 2005 13:44:24 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on	abstractfor	problemand	applicabili tystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 599

Actually, thinking about it a bit more...it really scares me to have 
RBridges forwarding
spanning tree messages. RBridges would then be wormholing spanning tree 
messages, so
bridges might mysteriously get spanning tree messages from someone that 
is really several
hops away. This probably would only occur during transient states, but 
it seems scary.

So I see no advantage in RBridges forwarding spanning tree messages. In 
contrast, the
advantage of having them discard them is that then the little spanning 
trees formed by
bridged islands are smaller, and independent of each other.

Radia

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 14 Oct 2005 16:30:32 -0300
Subject: Re: [rbridge] seeking input on abstractfor	problemand	applicabili	tystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2222

Michael,

	"What breaks" is - from the original context - the
assumption that an RBridge campus looks to the outside
world like a single bridge.

	As stated in other mail, I don't think this is a 
goal for the work we're doing.

	If BLOCKING is used - as I believe must be the case
by default - then an RBridge looks like "the rest of the 
world" to external bridges.  In other words, external 
bridges see and learn SA MAC addresses from all traffic 
the RBridge injects onto the shared link - just as if the 
devices corresponding to the addresses were also on that 
link.  As far as local bridges are concerned - in this 
case - the spanning tree ends (or starts, depending on 
perspective) with that link.

	The same is true for internal bridges - except 
that, owing to the encapsulation of frames in an extra
MAC header + shim, the internal bridges only see SA MAC
addresses for RBridges.

	The terms "internal" and "external" in this context
are not significant to the behavior of bridges or RBridges
in this mode.  I use them because they determine 1) the
scope of each STP and 2) SA MAC visibility at bridges.

	Note that this also works just fine if one RBridge
campus is attached to another.  In this case, no STP takes
place between the RBridges themselves (though STP may take
place between bridges on the link).  In this case, the 
term "external" is particularly "interesting".

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Michael Smith (michsmit)
--> Sent: Friday, October 14, 2005 1:39 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstractfor problemand
--> applicabilitystatement
--> 
--> 
-->  
--> > -----Original Message-----
--> > From: [email-masked] 
--> > 
--> > My understanding is that PARTICIPATE is valid, if not required.
--> > TRANSPARENT seems like it turns the bridge into a hub. And 
--> > BLOCK would break things.
--> 
--> I think I missed something, what breaks if we block BPDUs ?
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Content-class: urn:content-classes:message
Date: Fri, 14 Oct 2005 11:49:16 -0700
From: "Sanjay Sane \(sanjays\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seekinginputon	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2396

If rbridges blocked BPDUs, you may lose the root-id and root-cost
information of the spanning tree. Thus, the points at which the rbridge
spanning tree hooks up to L2 spanning tree may not be optimal. i.e.
Consider rbridge cloud having many intersections with external spanning
tree cloud. The choice about boundary ports (designated rbridges) may
have to be made entirely based on rbridge's view of the topology. 

Whereas, if rbridges participated, and  
-- created their own internal spanning tree
-- propogate the external L2 spanning tree BPDU over its internal
spanning tree, thus retaining the root-information to make good choices
about boundary ports. 
-- participate with external L2 spanning tree only at the "boundary
ports"
-- turn the rbridge cloud into a single virtual bridge. 

(this would look similar to how MSTP region (802.1s) interacts with CIST
at boundary ports) 

Thanks,
Sanjay

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Peter Ashwood-Smith
>Sent: Friday, October 14, 2005 11:18 AM
>Subject: Re: [rbridge] seekinginputon abstractfor problemand 
>applicabilitystatement
>
>
>>> I think I missed something, what breaks if we block BPDUs ?
>
>>If nothing, then lets. For bridges too.
>> Now what happens? (i.e., if bridges block BPDUs) - won't 
>that kill the
>spanning tree?
>
> Yes of course if you block a BPDU the bridge will stop the 
>STP tree at that point. Thats exactly what we are trying to 
>do. Stop the STP computed portion of the FULL tree at that point. 
>  
> With BLOCK. Each protocol computes its own smaller part of 
>the bigger spanning tree.
> STP computes using BPDUS etc. and Rbridge computes using 
>IS-IS/Krusal's.
>
> When done you have a bunch of unconnected spanning trees 
>which are made into one big tree by the designated rbridge 
>concept i.e. single link.
>
> To convince yourself that this really works. Draw an 
>arbitrary tree on a piece of paper. Then draw another disjoint 
>tree somewhere else on the paper. You can make one big tree by 
>connecting any two of the points between the two trees and you 
>cannot create a loop with single link.
>That is why BLOCK works.
>
> Peter
>[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 14 Oct 2005 15:49:37 -0300
Subject: Re: [rbridge] seeking input on abstract for	problemand	applicabil	itystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8023

Joe,

	I want to address specific comments/questions you 
had below:

-> All of this sounds like stuff the rbridge already 
   needs to do; there needs to be an internal spanning 
   tree anyway.

We have not yet decided how many "spanning trees" there
needs to be, and that is a part of the problem.  One of
the goals of the original proposal - as I understand it
- was to allow efficient use of redundant links that may 
exist between RBridges.  

This is why the confusion keeps coming up with the use 
of the term spanning tree.  Its NOT the right term in 
the RBridge context, because the RBridges WILL NOT be
turning ports off and WILL be forwarding distinguishable
streams of frames on as many of the available links as 
it makes sense to use, given the destinations and - for
example - VLAN contexts that apply to each stream.

Another goal - again as I understand it - is to reduce
the time for convergence on spanning trees for those
portions of the network that MUST use STP (the bridges).
For that goal to be achieved, it is a good idea not to
extend STP across the RBridges.

Finally, there is a huge "chicken-and-egg" problem with
any intention to have RBridges participate in STP.

The "spanning tree(s)" determined by RBridges are the
result of shortest path analysis of reachability info
provided by IS-IS.  If this is not the case, then there
was never any reason to suggest using a shortest-path,
Link State Routing Protocol in the first place.

However, before the RBridges can reliably determine
link state and advertise reachability, any "internal"
bridges MUST have already determined a spanning tree
(using STP).  As I pointed out previously, and Radia
stated as well, bridges typically do not forward during 
STP, consequently some or all of the links between the
RBridges will be DOWN as far as IS-IS is concerned.

Also, again as pointeed out previously, "internal" and 
"external" are topologically meaningless terms as far 
as RBridges are concerned - unless that information is
explicitly configured.  Consequently, default RBridge
behavior really MUST be to ignore STP on any port not
explicitly configured to participate in STP.

Also, because the link state between RBridges is not
determined until after any internal STP required has
been completed between bridges that may be involved 
in those links, either the RBridges have to wait a
pre-determined period of time (to blindly allow for 
"internal" STP) or send topology change BPDUs on all 
ports every time they discover new links. Either way 
will result in potentially huge delays in overall STP 
convergence time for the network.

-> I'd like someone to explain which of these are valid 
   if we replace the rbridge campus with an existing 
   bridge.

I am not sure that this concept of a "virtual bridge"
is - or ever has been - a goal for RBridges.  If you 
want a "virtual bridge", one approach that already is
out there is VPLS.  Consequently, why would we need
to specify how to do it with RBridges?

If it is not a goal, then the notion of replacing an
RBridge with a single bridge is not something we need
to consider.

-> My understanding is that PARTICIPATE is valid, if not 
   required. TRANSPARENT seems like it turns the bridge 
   into a hub. And BLOCK would break things.

Assuming that this _is_ a goal, there is no particular
reason why someone would not replace a hub (even a 
"virtual hub") with a bridge.  For reasons explained
above, however, PARTICIPATE - while potentially valid
- is extremely undesirable.

Transparent also is not good because the path through
the RBridges will not exist (or not be complete) until 
A) STP is completed between any "internal" bridges and 
B) the RBridges have converged on a complete LSDB and 
determine SPSTs (shortest path spanning trees).

So, even with Transparent, the insertion of RBridges
would result in increased STP convergence time, even
if the network size has not changed.

In addition, TRANSPARENT would require configuration
of the RBridges to recognize "external" interfaces -
since it is clearly not the case that, even in this 
mode, you would want bridges inside an RBridge campus
to participate with bridges outside that campus.  As
implied previously, having all bridges - both inside
and outside of an RBridge campus - participating in 
forming a single spanning tree would prevent using
redundant paths (and would very likely drop RBridge
ports out of the topology as the corresponding bridge
ports - at the other end of the physical link - are
put in the non-forwarding state).

--
Eric Gray

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Friday, October 14, 2005 1:21 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstract for problemand
--> applicabilitystatement
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge

Earlier, Joe Touch burbled...
--> 

Peter Ashwood-Smith wrote:
>>But isn't this just what STP does?
>>I.e., a bridge:
>>	
>>	accepts BPDUs as input
>>	determines an internal spanning tree based on port selection
>>	emits appropriate BPDUs on those ports
>>
>>Why isn't this exactly what an rbridge needs to do? I.e., neither a
> 
> bridge
> 
>>nor an rbridge 'transparently' forward BPDUs, but both are nodes in the
>>resulting spanning tree.
> 
> 
> Hmmm so you have added yet a third possibility. At this point I think
> giving them names is probably helpful. Here is what I'd suggest.
> 
>   [BLOCK]       Rbridge block BPDU's 
>   [TRANSPARENT] Rbridge transparently passes BPDU's
>   [PARTICIPATE] Rbridge participates (accepts/modifies/forwards BPDU's)
> 
> 
>>This still provides a benefit for an rbridge - that it is just ONE
> 
> node in > the spanning tree, not O(#rbridges) or even O(#egress
> rbridges).
> 
> Yeah, but its messy to implement this kind of thing. We refer to that as
> an abstract node in routing. Making a network appear as a single node to
> its neighbors. It requires more 'internal' messaging between the
> different 'parts' of the abstract node to create this illusion. For
> example the BPDUs must be gathered and sorted etc. so you'd have to
> elect one of the 'parts' of that node to act on behalf of the others, do
> the gather/sort and regeneration. A 'designated virtual bridge' so to
> speak.

All of this sounds like stuff the rbridge already needs to do; there
needs to be an internal spanning tree anyway.

> I'd suggest that the I.D mention the three (giving them concrete names
> to avoid further confusion). Personally, and I think from the emails it
> sounds like we'd recommend BLOCK, allow TRANSPARENT and leave
> PARTICIPATE for further study? (I can hear the graduate students
> sharpening their pencils already).

I'd like someone to explain which of these are valid if we replace the
rbridge campus with an existing bridge.

My understanding is that PARTICIPATE is valid, if not required.
TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would
break things.

> Oh, speaking of TRANSPARENT, it may be a very useful mode during a
> migration since it allows the installation of rbridges without affecting
> the bulk of the paths. BLOCK would result in a sudden change in root
> bridge on one side of the Rbridged network with resulting sudden shift
> in traffic patterns. For some carefully crafted networks that sudden
> change may be a bit of a shock and an impediment to migration so while
> undesirable in the final state, it may be useful during transition ...
> unless we mandate ships in the night with a quick switchover when all
> bridges were replaced with rbridges ... but I've not seen this done very
> often successfully.
> 
> Peter Ashwood-Smith
> 
> 
> [email-masked]

Content-class: urn:content-classes:message
Date: Fri, 14 Oct 2005 14:18:15 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking inputon	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1005

>> I think I missed something, what breaks if we block BPDUs ?

>If nothing, then lets. For bridges too.
> Now what happens? (i.e., if bridges block BPDUs) - won't that kill the
spanning tree?

 Yes of course if you block a BPDU the bridge will stop the STP tree at
that point. Thats exactly what we are trying to do. Stop the STP
computed portion of the FULL tree at that point. 
  
 With BLOCK. Each protocol computes its own smaller part of the bigger
spanning tree.
 STP computes using BPDUS etc. and Rbridge computes using
IS-IS/Krusal's.

 When done you have a bunch of unconnected spanning trees which are made
into one big tree by the designated rbridge concept i.e. single link.

 To convince yourself that this really works. Draw an arbitrary tree on
a piece of paper. Then draw another disjoint tree somewhere else on the
paper. You can make one big tree by connecting any two of the points
between the two trees and you cannot create a loop with single link.
That is why BLOCK works.

 Peter

Content-class: urn:content-classes:message
Date: Fri, 14 Oct 2005 14:00:16 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1014

> My understanding is that PARTICIPATE is valid, if not required.
TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would
break things.

  PARTICIPATE is definitely valid, but I disagree it is always required.
Its definitely useful though. It is only always required if both of
TRANSPARENT and BLOCK do not work.
 
  Yup, TRANSPARENT turns the rbridge network into a hub therefore it is
also valid with different trade-offs. Therefore PARTICIPATE is not
always required it is simply valid.

  BLOCK will break things? How. I think I've convinced myself this is
not possible in the steady state (because you have nodally disjoint
trees joined by a single link therefore a loop is not possible). The
worst it can do is change the routes because you get two STP trees each
with different root bridges ... which is not always ideal and why I
think you need TRANSPARENT AND BLOCK options at different phases of a
migration ... and possibly even Ships in the Night mode too.

  Peter Ashwood-Smith

Date: Fri, 14 Oct 2005 10:55:50 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on	abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1158

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6B371A5000287BD0D6E2DB47
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Michael Smith (michsmit) wrote:
>>From: [email-masked] 
>>
>>My understanding is that PARTICIPATE is valid, if not required.
>>TRANSPARENT seems like it turns the bridge into a hub. And 
>>BLOCK would break things.
> 
> 
> I think I missed something, what breaks if we block BPDUs ?

If nothing, then lets. For bridges too.

Now what happens? (i.e., if bridges block BPDUs) - won't that kill the
spanning tree?

Joe

--------------enig6B371A5000287BD0D6E2DB47
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig6B371A5000287BD0D6E2DB47--

Content-class: urn:content-classes:message
Date: Fri, 14 Oct 2005 10:38:40 -0700
From: "Michael Smith \(michsmit\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstractfor	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 287

> From: [email-masked] 
> 
> My understanding is that PARTICIPATE is valid, if not required.
> TRANSPARENT seems like it turns the bridge into a hub. And 
> BLOCK would break things.

I think I missed something, what breaks if we block BPDUs ?

Date: Fri, 14 Oct 2005 10:27:37 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Rbridges for MANETs?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2270

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig36DE0EB60B511D8EAE289B50
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Templin, Fred L wrote:
> I am wondering if anyone has considered Mobile Ad-hoc Networks
> (MANETs) as an instance of a "campus" that Rbridges might find
> themselves in?

For this WG, my understanding is no.

In particular, we assume that existing routing is used inside the campus
(perhaps modified to transit rbridge info, but otherwise as-is), and
that rbridge dynamics are similar to existing bridge dynamics.

> Due to node mobility, Rbridges would have to deal
> with frequent link state changes in such an environment which
> would give a constantly changing topology along with potentially
> multiplicative increase in routing protocol overhead. Do we see
> Rbridges as potentially extending to cover the MANET space?

That sounds like a job for a new routing protocol that an rbridge might
use, but not specific to rbridges.

> I ask this partly because there will be a BOF on Ad-Hoc Network
> Autonconfiguration (AUTOCONF) at the upcoming IETF and I wonder
> about the overlap between what is being considered there and
> TRILL. A quick overview makes it seem that the AUTOCONF approach
> has more of a layer 3 flavor while TRILL is more focused on the
> layer 2 proxy approach. Has anyone considered whether the two
> approaches are essentially addressing the same problem space?

Bridges live in a world of known (or at least assumed) unique,
predeployed global endpoint identifiers, and provide broadcast as well
as multicast. These are some of the more significant challenges that
AUTOCONF needs to address (sans broadcast), so I don't see them as related.

Joe

--------------enig36DE0EB60B511D8EAE289B50
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig36DE0EB60B511D8EAE289B50--

Date: Fri, 14 Oct 2005 10:21:04 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for	problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3633

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC3D8BB5C8BF34C434B950190
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Ashwood-Smith wrote:
>>But isn't this just what STP does?
>>I.e., a bridge:
>>	
>>	accepts BPDUs as input
>>	determines an internal spanning tree based on port selection
>>	emits appropriate BPDUs on those ports
>>
>>Why isn't this exactly what an rbridge needs to do? I.e., neither a
> 
> bridge
> 
>>nor an rbridge 'transparently' forward BPDUs, but both are nodes in the
>>resulting spanning tree.
> 
> 
> Hmmm so you have added yet a third possibility. At this point I think
> giving them names is probably helpful. Here is what I'd suggest.
> 
>   [BLOCK]       Rbridge block BPDU's 
>   [TRANSPARENT] Rbridge transparently passes BPDU's
>   [PARTICIPATE] Rbridge participates (accepts/modifies/forwards BPDU's)
> 
> 
>>This still provides a benefit for an rbridge - that it is just ONE
> 
> node in > the spanning tree, not O(#rbridges) or even O(#egress
> rbridges).
> 
> Yeah, but its messy to implement this kind of thing. We refer to that as
> an abstract node in routing. Making a network appear as a single node to
> its neighbors. It requires more 'internal' messaging between the
> different 'parts' of the abstract node to create this illusion. For
> example the BPDUs must be gathered and sorted etc. so you'd have to
> elect one of the 'parts' of that node to act on behalf of the others, do
> the gather/sort and regeneration. A 'designated virtual bridge' so to
> speak.

All of this sounds like stuff the rbridge already needs to do; there
needs to be an internal spanning tree anyway.

> I'd suggest that the I.D mention the three (giving them concrete names
> to avoid further confusion). Personally, and I think from the emails it
> sounds like we'd recommend BLOCK, allow TRANSPARENT and leave
> PARTICIPATE for further study? (I can hear the graduate students
> sharpening their pencils already).

I'd like someone to explain which of these are valid if we replace the
rbridge campus with an existing bridge.

My understanding is that PARTICIPATE is valid, if not required.
TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would
break things.

> Oh, speaking of TRANSPARENT, it may be a very useful mode during a
> migration since it allows the installation of rbridges without affecting
> the bulk of the paths. BLOCK would result in a sudden change in root
> bridge on one side of the Rbridged network with resulting sudden shift
> in traffic patterns. For some carefully crafted networks that sudden
> change may be a bit of a shock and an impediment to migration so while
> undesirable in the final state, it may be useful during transition ...
> unless we mandate ships in the night with a quick switchover when all
> bridges were replaced with rbridges ... but I've not seen this done very
> often successfully.
> 
> Peter Ashwood-Smith
> 
> 
> [email-masked]

--------------enigC3D8BB5C8BF34C434B950190
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigC3D8BB5C8BF34C434B950190--

Content-class: urn:content-classes:message
Date: Fri, 14 Oct 2005 00:35:57 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problemand	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2291

> But isn't this just what STP does?
> I.e., a bridge:
>	
>	accepts BPDUs as input
>	determines an internal spanning tree based on port selection
>	emits appropriate BPDUs on those ports
>
>Why isn't this exactly what an rbridge needs to do? I.e., neither a
bridge
>nor an rbridge 'transparently' forward BPDUs, but both are nodes in the
>resulting spanning tree.

Hmmm so you have added yet a third possibility. At this point I think
giving them names is probably helpful. Here is what I'd suggest.

  [BLOCK]       Rbridge block BPDU's 
  [TRANSPARENT] Rbridge transparently passes BPDU's
  [PARTICIPATE] Rbridge participates (accepts/modifies/forwards BPDU's)

> This still provides a benefit for an rbridge - that it is just ONE
node in > the spanning tree, not O(#rbridges) or even O(#egress
rbridges).

Yeah, but its messy to implement this kind of thing. We refer to that as
an abstract node in routing. Making a network appear as a single node to
its neighbors. It requires more 'internal' messaging between the
different 'parts' of the abstract node to create this illusion. For
example the BPDUs must be gathered and sorted etc. so you'd have to
elect one of the 'parts' of that node to act on behalf of the others, do
the gather/sort and regeneration. A 'designated virtual bridge' so to
speak.

I'd suggest that the I.D mention the three (giving them concrete names
to avoid further confusion). Personally, and I think from the emails it
sounds like we'd recommend BLOCK, allow TRANSPARENT and leave
PARTICIPATE for further study? (I can hear the graduate students
sharpening their pencils already).

Oh, speaking of TRANSPARENT, it may be a very useful mode during a
migration since it allows the installation of rbridges without affecting
the bulk of the paths. BLOCK would result in a sudden change in root
bridge on one side of the Rbridged network with resulting sudden shift
in traffic patterns. For some carefully crafted networks that sudden
change may be a bit of a shock and an impediment to migration so while
undesirable in the final state, it may be useful during transition ...
unless we mandate ships in the night with a quick switchover when all
bridges were replaced with rbridges ... but I've not seen this done very
often successfully.

Peter Ashwood-Smith

Date: Thu, 13 Oct 2005 20:28:09 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2348

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA4F64E4D6D246C3DFC98EB6D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Ashwood-Smith wrote:
> 
>>I still think the rbridge MUST participate in order to avoid loops, 
>>but if that's contentious it can't be part of the abstract yet...)
> 
> 
> 
> Let me see if I can help. Radia gave a good description of why the
> Rbridge does not need to participate in STP/FSTP but here is another way
> to think of it and perhaps it will strike different chords:
> 
> Take two node disjoint trees A and B.
> 
> Now, connect the trees A and B with only ONE link. The result is still a
> tree.
> 
> This is "sort of" what the combination of STP and Rbridge protocols are
> doing.
> 
> STP computes one tree. Rbridge computes the other and finally Rbridge
> connects the two with only ONE link using the designated Rbridge
> concept.
> 
> Since we can apply this same mechanism over and over again, i.e.
> induction we are guaranteed the end result is indeed one big tree and
> therefore is loop free, ... at least in the steady state. 

But isn't this just what STP does?

I.e., a bridge:
	
	accepts BPDUs as input
	determines an internal spanning tree based on port selection
	emits appropriate BPDUs on those ports

Why isn't this exactly what an rbridge needs to do? I.e., neither a
bridge nor an rbridge 'transparently' forward BPDUs, but both are nodes
in the resulting spanning tree.

This still provides a benefit for an rbridge - that it is just ONE node
in the spanning tree, not O(#rbridges) or even O(#egress rbridges).

I.e., it still helps the remaining spanning tree converge faster and
react better. AND rbridges 'inside' the campus (acting as transits) can
move around without affecting the spanning tree at all.

Joe

--------------enigA4F64E4D6D246C3DFC98EB6D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigA4F64E4D6D246C3DFC98EB6D--

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Thu, 13 Oct 2005 21:50:34 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3003

Dino,

	This potential "scaling problem" comes from mixing goals.
It should not - simultaneously - be a goal to both extend STP
across an L2 network and target a larger L2 network.  If we are
planning to keep the spanning trees simple and small, then we
might be able to achieve better performance with larger scale
layer two networks.

	In any case, I believe it has already been said that it 
is not necessarily a goal of RBridges to make LANs larger.  If
LANs get larger because of RBridges, it will be because they 
allow them to - not because they force them to.

	I've yet to see what the reasoning is for wanting to have
STP take place over the entire extended L2 network (overlay).
I've seen people argue that we could do so - but not why we 
would do so.  I've also seen people argue that we should do so,
but the argument seems to be based on a somewhat "purest" point
of view based on the belief that L2 networks do this.

	The entire discussions seems to have been initiated as a
result of confusing use of the term "spanning tree".  The fact
that a spanning tree may be determined in one way or another
does not mean, or even imply, that STP is always used.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Dino Farinacci
--> Sent: Thursday, October 13, 2005 8:17 PM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> >> I think this is suboptimal, since the larger the 
--> spanning tree, the 
--> >> slower convergence would be.
--> 
-->     So that's a good point we should also decide on. If the 
--> introduction of
-->     RBridges causes traditional bridged networks to get 
--> larger, we could
-->     introduce a scaling problem by making STP work harder 
--> than it was
-->     originally designed for. 
--> 
-->     Now, yes, anyone could tunnel over any infrastructure 
--> and create an
-->     overlay topology (i.e. VPLS and L2 metro networks) but 
--> do we want to make 
-->     it more inherent in the architecture.
--> 
--> >> So I think it's a lot better to have RBridges not 
--> forward spanning tree 
--> >> messages, and keep the
--> >> bridge spanning trees really separate.
--> 
-->     I think I can go along with this too but we need to 
--> state that an RBridge
-->     network is not a traditional L2-based subnet. I think 
--> there are other
-->     reasons to claim this already (i.e. low incident 
--> forwarding loops and
-->     duplicate packets) so we wouldn't be setting a 
--> precedent for this case.
--> 
--> >> We could think of it as RBridges "participating" in 
--> 802.1d spanning tree 
--> >> by simply consuming
--> >> the messages (and not doing anything other than dropping them).
--> 
-->     Sure, makes sense.
--> 
--> Dino
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Thu, 13 Oct 2005 17:16:48 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1194

>> I think this is suboptimal, since the larger the spanning tree, the 
>> slower convergence would be.

    So that's a good point we should also decide on. If the introduction of
    RBridges causes traditional bridged networks to get larger, we could
    introduce a scaling problem by making STP work harder than it was
    originally designed for. 

    Now, yes, anyone could tunnel over any infrastructure and create an
    overlay topology (i.e. VPLS and L2 metro networks) but do we want to make 
    it more inherent in the architecture.

>> So I think it's a lot better to have RBridges not forward spanning tree 
>> messages, and keep the
>> bridge spanning trees really separate.

    I think I can go along with this too but we need to state that an RBridge
    network is not a traditional L2-based subnet. I think there are other
    reasons to claim this already (i.e. low incident forwarding loops and
    duplicate packets) so we wouldn't be setting a precedent for this case.

>> We could think of it as RBridges "participating" in 802.1d spanning tree 
>> by simply consuming
>> the messages (and not doing anything other than dropping them).

    Sure, makes sense.

Dino

Content-class: urn:content-classes:message
Date: Thu, 13 Oct 2005 16:12:42 -0700
From: "Templin, Fred L" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Rbridges for MANETs?
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 921

I am wondering if anyone has considered Mobile Ad-hoc Networks
(MANETs) as an instance of a "campus" that Rbridges might find
themselves in? Due to node mobility, Rbridges would have to deal
with frequent link state changes in such an environment which
would give a constantly changing topology along with potentially
multiplicative increase in routing protocol overhead. Do we see
Rbridges as potentially extending to cover the MANET space?

I ask this partly because there will be a BOF on Ad-Hoc Network
Autonconfiguration (AUTOCONF) at the upcoming IETF and I wonder
about the overlap between what is being considered there and
TRILL. A quick overview makes it seem that the AUTOCONF approach
has more of a layer 3 flavor while TRILL is more focused on the
layer 2 proxy approach. Has anyone considered whether the two
approaches are essentially addressing the same problem space?

Fred
[email-masked]    

From: Bill Sommerfeld <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Thu, 13 Oct 2005 17:15:01 -0400
Subject: Re: [rbridge] seeking input on abstract for problem and	applicability statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1281

On Wed, 2005-10-12 at 22:16, Erik Nordmark wrote:
> I assume you might want to be able to have a single MAC address and 
> receive packets over multiple ports - with the rbridges using the 
> shortest path. Is this correct?

Exactly.  You'll get better performance when all paths are working, and
simple failover when they aren't.

> That is more of a functional problem than a security problem I think.

so, a simple way to do this functionally is for the host to just become
an rbridge.  but then historically many sites are organized such that
the people who administer the network don't trust the people who run the
hosts and vice versa.....

> Since end stations might move around, one would assume that when a MAC 
> address appears on a different port, perhaps on a different rbridge as 
> well, that the host has moved. Thus it would make sense to add the route 
> which points to the new place, and remove the route that points to the 
> old place.
> 
> But in your case you would need that both routes remain in place 
> somehow. Perhaps we can do that by being smarter about when we remove a 
> route for a MAC address?

yup.  routing protocols already provide a way to solve that problem, but
then you get into the organizational issue alluded to above.

					- Bill

Content-class: urn:content-classes:message
Date: Thu, 13 Oct 2005 16:17:01 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4528

Agreed, this is why I said it is a SHOULD v.s. a MUST.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Thursday, October 13, 2005 4:06 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

I'm travelling and not necessarily following this whole thread.

However...I think it actually would work to have RBridges forwarding 
spanning tree messages. It would
result in lots of little trees, partitioned because data traffic must 
not be forwarded mindlessly along
that super-tree, but all the little trees would think the same ID was 
Root bridge.

I think this is suboptimal, since the larger the spanning tree, the 
slower convergence would be.
So I think it's a lot better to have RBridges not forward spanning tree 
messages, and keep the
bridge spanning trees really separate.

We could think of it as RBridges "participating" in 802.1d spanning tree

by simply consuming
the messages (and not doing anything other than dropping them).

Radia

Michael Smith (michsmit) wrote:

>>From: [email-masked]
>>
>>Dino,
>>
>>	The argument that an RBridge network provides a layer 2
>>service therefore any frames that are presented should be 
>>forwarded is a non sequitur.
>>
>>	This is not even true of bridges now.  Conditions under
>>which a bridge "should" forward frames are somewhat 
>>restricted, even if those conditions are typically satisfied 
>>under steady-state conditions, for most frames.  There are 
>>plenty of examples of situations in which a bridge must not 
>>forward frames and other in which a bridge should not forward frames.
>>    
>>
>
>For the most part, bridges only terminate their own control protocols, 
>link layer protocols, and local management traffic.  Since the rbridge 
>doesn't participate in STP, I see a valid argument that this protocol 
>should be passed.  This is basically what an 802.1ad bridge does, it 
>doesn't participate in the customer STP and simply passes the customer 
>BPDUs through and everything works fine.  On the other hand, since the 
>goal is to provide an alternative to spanning tree, this would imply 
>that the entire network will run both rbridging control plane and STP 
>until it is fully upgraded to rbridges.  If STP is terminated at the 
>rbridge, there would be incremental benefit of upgrading the network 
>with rbridges by localizing STP as rbridges are incrementally deployed.

>Personally, I feel passing or terminating STP can be equally justified 
>(and if this is used in the Metro space, we could end up doing both).
>
>Michael
>
>  
>
>>--
>>Eric
>>
>>--> -----Original Message-----
>>--> From: [email-masked] 
>>--> [mailto:[email-masked]]On
>>--> Behalf Of Dino Farinacci
>>--> Sent: Wednesday, October 12, 2005 5:46 PM
>>--> To: [email-masked]
>>--> Cc: [email-masked]
>>--> Subject: Re: [rbridge] loops in trill networks
>>--> 
>>--> 
>>--> >> 	No, actually, it is not like saying that.
>>--> 
>>-->     I think the fundamental question that needs to be answered is
>>--> does an
>>-->     RBridge network proivde a layer-2 serivce. And I think the 
>>--> answer should
>>-->     be yes. Therefore any frames that are sent on such a network 
>>--> should be
>>-->     forwarded.
>>--> 
>>-->     Two bridges connected via a cable or an RBridge-based network
>>--> should
>>-->     look no different. The two bridges should be able to run STP 
>>--> over it and
>>-->     decide if the ports leading to such a network are in 
>>Blocked or
>>--> Forward
>>-->     state.
>>--> 
>>-->     The RBridges should forward such packets like any
>>other frames.
>>--> The only
>>-->     frames that RBridges will consume and process are
>>IS-IS packets
>>--> (which
>>-->     will be multicasted on a *new MAC group address*).
>>--> 
>>--> Dino
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>--> 
>>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>>
>>    
>>
>[email-masked] http://www.postel.org/mailman/listinfo/rbridge
>  
>

_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

Date: Thu, 13 Oct 2005 13:06:17 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4081

I'm travelling and not necessarily following this whole thread.

However...I think it actually would work to have RBridges forwarding 
spanning tree messages. It would
result in lots of little trees, partitioned because data traffic must 
not be forwarded mindlessly along
that super-tree, but all the little trees would think the same ID was 
Root bridge.

I think this is suboptimal, since the larger the spanning tree, the 
slower convergence would be.
So I think it's a lot better to have RBridges not forward spanning tree 
messages, and keep the
bridge spanning trees really separate.

We could think of it as RBridges "participating" in 802.1d spanning tree 
by simply consuming
the messages (and not doing anything other than dropping them).

Radia

Michael Smith (michsmit) wrote:

>>From: [email-masked] 
>>
>>Dino,
>>
>>	The argument that an RBridge network provides a layer 2 
>>service therefore any frames that are presented should be 
>>forwarded is a non sequitur.
>>
>>	This is not even true of bridges now.  Conditions under 
>>which a bridge "should" forward frames are somewhat 
>>restricted, even if those conditions are typically satisfied 
>>under steady-state conditions, for most frames.  There are 
>>plenty of examples of situations in which a bridge must not 
>>forward frames and other in which a bridge should not forward frames.
>>    
>>
>
>For the most part, bridges only terminate their own control protocols,
>link layer protocols, and local management traffic.  Since the rbridge
>doesn't participate in STP, I see a valid argument that this protocol
>should be passed.  This is basically what an 802.1ad bridge does, it
>doesn't participate in the customer STP and simply passes the customer
>BPDUs through and everything works fine.  On the other hand, since the
>goal is to provide an alternative to spanning tree, this would imply
>that the entire network will run both rbridging control plane and STP
>until it is fully upgraded to rbridges.  If STP is terminated at the
>rbridge, there would be incremental benefit of upgrading the network
>with rbridges by localizing STP as rbridges are incrementally deployed.
>Personally, I feel passing or terminating STP can be equally justified
>(and if this is used in the Metro space, we could end up doing both).
>
>Michael
>
>  
>
>>--
>>Eric
>>
>>--> -----Original Message-----
>>--> From: [email-masked]
>>--> [mailto:[email-masked]]On
>>--> Behalf Of Dino Farinacci
>>--> Sent: Wednesday, October 12, 2005 5:46 PM
>>--> To: [email-masked]
>>--> Cc: [email-masked]
>>--> Subject: Re: [rbridge] loops in trill networks
>>--> 
>>--> 
>>--> >> 	No, actually, it is not like saying that.
>>--> 
>>-->     I think the fundamental question that needs to be answered is 
>>--> does an
>>-->     RBridge network proivde a layer-2 serivce. And I think the 
>>--> answer should
>>-->     be yes. Therefore any frames that are sent on such a network 
>>--> should be
>>-->     forwarded.
>>--> 
>>-->     Two bridges connected via a cable or an RBridge-based network 
>>--> should
>>-->     look no different. The two bridges should be able to run STP 
>>--> over it and
>>-->     decide if the ports leading to such a network are in 
>>Blocked or 
>>--> Forward
>>-->     state.
>>--> 
>>-->     The RBridges should forward such packets like any 
>>other frames. 
>>--> The only
>>-->     frames that RBridges will consume and process are 
>>IS-IS packets 
>>--> (which
>>-->     will be multicasted on a *new MAC group address*).
>>--> 
>>--> Dino
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> [email-masked]
>>--> http://www.postel.org/mailman/listinfo/rbridge
>>--> 
>>[email-masked]
>[email-masked]

Date: Thu, 13 Oct 2005 10:56:49 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 787

>> 	This is not even true of bridges now.  Conditions under which a
>> bridge "should" forward frames are somewhat restricted, even if those
>> conditions are typically satisfied under steady-state conditions, for
>> most frames.  There are plenty of examples of situations in which a
>> bridge must not forward frames and other in which a bridge should not
>> forward frames.

    I disagree. There are very few cases (I can think of only one standard
    case and one proprietary case) where architecturally a 802.1D bridge
    states "a bridge should not forward packet with ethertype foo or DA
    bar". 

    Now this is all modulo what vendors do for policy based forwarding/
    filtering. But that is an implementation extension and not an architectural
    specification.

Dino

Content-class: urn:content-classes:message
Date: Thu, 13 Oct 2005 09:35:45 -0700
From: "Michael Smith \(michsmit\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3094

> From: [email-masked] 
> 
> Dino,
> 
> 	The argument that an RBridge network provides a layer 2 
> service therefore any frames that are presented should be 
> forwarded is a non sequitur.
> 
> 	This is not even true of bridges now.  Conditions under 
> which a bridge "should" forward frames are somewhat 
> restricted, even if those conditions are typically satisfied 
> under steady-state conditions, for most frames.  There are 
> plenty of examples of situations in which a bridge must not 
> forward frames and other in which a bridge should not forward frames.

For the most part, bridges only terminate their own control protocols,
link layer protocols, and local management traffic.  Since the rbridge
doesn't participate in STP, I see a valid argument that this protocol
should be passed.  This is basically what an 802.1ad bridge does, it
doesn't participate in the customer STP and simply passes the customer
BPDUs through and everything works fine.  On the other hand, since the
goal is to provide an alternative to spanning tree, this would imply
that the entire network will run both rbridging control plane and STP
until it is fully upgraded to rbridges.  If STP is terminated at the
rbridge, there would be incremental benefit of upgrading the network
with rbridges by localizing STP as rbridges are incrementally deployed.
Personally, I feel passing or terminating STP can be equally justified
(and if this is used in the Metro space, we could end up doing both).

Michael

> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: [email-masked]
> --> [mailto:[email-masked]]On
> --> Behalf Of Dino Farinacci
> --> Sent: Wednesday, October 12, 2005 5:46 PM
> --> To: [email-masked]
> --> Cc: [email-masked]
> --> Subject: Re: [rbridge] loops in trill networks
> --> 
> --> 
> --> >> 	No, actually, it is not like saying that.
> --> 
> -->     I think the fundamental question that needs to be answered is 
> --> does an
> -->     RBridge network proivde a layer-2 serivce. And I think the 
> --> answer should
> -->     be yes. Therefore any frames that are sent on such a network 
> --> should be
> -->     forwarded.
> --> 
> -->     Two bridges connected via a cable or an RBridge-based network 
> --> should
> -->     look no different. The two bridges should be able to run STP 
> --> over it and
> -->     decide if the ports leading to such a network are in 
> Blocked or 
> --> Forward
> -->     state.
> --> 
> -->     The RBridges should forward such packets like any 
> other frames. 
> --> The only
> -->     frames that RBridges will consume and process are 
> IS-IS packets 
> --> (which
> -->     will be multicasted on a *new MAC group address*).
> --> 
> --> Dino
> --> _______________________________________________
> --> rbridge mailing list
> --> [email-masked]
> --> http://www.postel.org/mailman/listinfo/rbridge
> --> 
> [email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Thu, 13 Oct 2005 09:35:05 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1831

Dino,

	The argument that an RBridge network provides a layer 2 service
therefore any frames that are presented should be forwarded is a non
sequitur.

	This is not even true of bridges now.  Conditions under which a
bridge "should" forward frames are somewhat restricted, even if those
conditions are typically satisfied under steady-state conditions, for
most frames.  There are plenty of examples of situations in which a
bridge must not forward frames and other in which a bridge should not
forward frames.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Dino Farinacci
--> Sent: Wednesday, October 12, 2005 5:46 PM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> >> 	No, actually, it is not like saying that.
--> 
-->     I think the fundamental question that needs to be 
--> answered is does an 
-->     RBridge network proivde a layer-2 serivce. And I think 
--> the answer should
-->     be yes. Therefore any frames that are sent on such a 
--> network should be 
-->     forwarded.
--> 
-->     Two bridges connected via a cable or an RBridge-based 
--> network should 
-->     look no different. The two bridges should be able to 
--> run STP over it and 
-->     decide if the ports leading to such a network are in 
--> Blocked or Forward 
-->     state.
--> 
-->     The RBridges should forward such packets like any other 
--> frames. The only
-->     frames that RBridges will consume and process are IS-IS 
--> packets (which
-->     will be multicasted on a *new MAC group address*).
--> 
--> Dino
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Thu, 13 Oct 2005 09:29:16 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5039

Erik,

	I agree that sending a topology change BPDU might be
a better approach.  There are two things for us to look at
if that's what we're thinking of doing: what are the results
of having a device that is enough of a regular bridge to be
able to send topology change BPDUs but not enough of one to
be able to otherwise participate in bridging - and - what
are the consequences to forwarding when we put all of the
bridges in non-forwarding mode while they re-run STP and
then in flooding mode while they re-learn their filtering
DB?

	I think the latter is not so much of an issue, if we
subscribe to the philosophy stated earlier that having the
ability to create a larger L2 domain is an objective.  In
that case, the "trauma" thus induced would be no worse than
if the RBridge that went down was a regular bridge.

	The former issue is something we can maybe finesse,
if we allow RBridges to originate BPDUs but not (in the
normal case) forward them.  In this case, other bridges
will normally construe that an RBridge - rather than being
a host - is a bridge with no transit connectivity.  In that
case, the normal mode would be that local bridges would 
only forward frames to an RBridge that are MAC-addressed
to it.

	For the case where RBridges might forward BPDUs, it
must be the case that they are configured with information
that will allow them to determine which BPDUs to forward
an which not to forward.  Otherwise - for forwarding - it
will not be possible to take advantage of many redundant
paths as the bridges will see the RBridges as part of a 
single spanning tree and will forward and accept frames
only on that single spanning tree.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Erik Nordmark
--> Sent: Wednesday, October 12, 2005 10:35 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> Gray, Eric wrote:
--> 
--> > 	Instead, the normal case should be for RBridges
--> > to terminate the local broadcast domain and the local
--> > STP-based spanning tree. To do this, RBridges should
--> > act as if they were hosts to STP and ignore it.
--> 
--> Eric,
--> I'm not sure we have a useful definition for "local 
--> broadcast domain" - 
--> we have a broadcast domain which spans the whole rbridged 
--> network so 
--> that IP broadcast continues to work as before.
--> 
--> I think that having rbridges act as if they are hosts is a 
--> good starting 
--> point to think about the problem. But the desire to attach 
--> the local 
--> (bridged) segment to multiple rbridges for redundancy makes 
--> things a bit 
--> more complex. Take this picture:
--> 
--> 	   H4
-->              |
--> 	( Rest of rbridged network )
--> 	 |                       |
--> 	RB1                     RB2
-->           |                       |
--> 	( bridged cloud at edge    )
-->           |      |          |
--> 	H1     H2         H3
--> 
--> Suppose RB1 has been elected as the forwarder to/from the 
--> bridged cloud.
--> This means that the bridges have learned (from received 
--> packets) that 
--> packets to MAC addresses in the rest of the network (e.g., 
--> H4) should be 
--> sent towards RB1.
--> 
--> What happens when RB1 fails? RB2 would take over, and the routing 
--> protocol would quickly cause the other rbridges to find out.
--> But packets from H1 to H4 will continue to be forwarded by 
--> the bridges 
--> towards RB1 until those learning tables time out, or until 
--> a packet from 
--> H4 arrives via RB2.
--> 
--> If we want to ensure that the bridges more quickly find out 
--> that they 
--> should use RB2, it would seem like we need to add something in the 
--> interaction at the edge. Effectively we want RB2 to be able 
--> to tell the 
--> bridges in the cloud either
-->   - that they should discard their learning tables, or
-->   - that they should switch to use RB2.
--> 
--> I haven't looked at the options in detail, but perhaps we 
--> can do the 
--> first by RB2 injecting a toplogy change BPDU?
--> For the second approach, one could envision the RBs at the edge 
--> presenting themselves as a bridge with a low cost to an 
--> imaginary root 
--> bridge (which represents the rbridge core)? Of course, we 
--> can't ensure 
--> that the imaginary becomes the root bridge; the best we can 
--> do is to 
--> have it have a high probability of becoming the root bridge 
--> from the 
--> perspective of the bridged cloud at this part of the edge.
--> I don't think this requires that BPDUs be carried across 
--> the rbridged 
--> cloud - each bridged cloud at the edges can be treated as separate.
--> 
--> I don't know how fancy we need to be here, but waiting for 
--> the learning 
--> tables to time out when there is an RB failures seems a bid bad.
--> 
-->     Erik
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Wed, 12 Oct 2005 19:42:41 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1805

Dino Farinacci wrote:

>     I think the fundamental question that needs to be answered is does an 
>     RBridge network proivde a layer-2 serivce. And I think the answer should
>     be yes. Therefore any frames that are sent on such a network should be 
>     forwarded.
> 
>     Two bridges connected via a cable or an RBridge-based network should 
>     look no different. The two bridges should be able to run STP over it and 
>     decide if the ports leading to such a network are in Blocked or Forward 
>     state.
> 
>     The RBridges should forward such packets like any other frames. The only
>     frames that RBridges will consume and process are IS-IS packets (which
>     will be multicasted on a *new MAC group address*).

Dino,

I don't claim to understand the tradeoffs between this approach and the 
approach when BPDUs are filtered (so that they are not encapsulated 
between the rbridges like other packets).

Does anybody want to take a crack at describing what the tradeoffs might be?

If the rbridge cloud is BPDU transparent, then we will end up with a 
single, large 802.1D spanning tree across the whole network. Does or 
does this not cause more disruption when there are failures/changes in 
the rbridge core? When there are failures/changes in the far side of the 
network? (on the other side of the rbridge core)

If the rbridge cloud does not let BPDUs transit, then each edge will run 
its own 802.1D spanning tree, so the trees will be smaller. But the 
handling of rbridge failures causing the bridges to sent things to a new 
designated rbridge might be slower or at least different.

These are just off the top of my head. As I said it would be good if 
somebody could try to pull together a comparison of the pros and cons of 
the different approaches.

    Erik

Date: Wed, 12 Oct 2005 19:35:02 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2589

Gray, Eric wrote:

> 	Instead, the normal case should be for RBridges
> to terminate the local broadcast domain and the local
> STP-based spanning tree. To do this, RBridges should
> act as if they were hosts to STP and ignore it.

Eric,
I'm not sure we have a useful definition for "local broadcast domain" - 
we have a broadcast domain which spans the whole rbridged network so 
that IP broadcast continues to work as before.

I think that having rbridges act as if they are hosts is a good starting 
point to think about the problem. But the desire to attach the local 
(bridged) segment to multiple rbridges for redundancy makes things a bit 
more complex. Take this picture:

	   H4
             |
	( Rest of rbridged network )
	 |                       |
	RB1                     RB2
          |                       |
	( bridged cloud at edge    )
          |      |          |
	H1     H2         H3

Suppose RB1 has been elected as the forwarder to/from the bridged cloud.
This means that the bridges have learned (from received packets) that 
packets to MAC addresses in the rest of the network (e.g., H4) should be 
sent towards RB1.

What happens when RB1 fails? RB2 would take over, and the routing 
protocol would quickly cause the other rbridges to find out.
But packets from H1 to H4 will continue to be forwarded by the bridges 
towards RB1 until those learning tables time out, or until a packet from 
H4 arrives via RB2.

If we want to ensure that the bridges more quickly find out that they 
should use RB2, it would seem like we need to add something in the 
interaction at the edge. Effectively we want RB2 to be able to tell the 
bridges in the cloud either
  - that they should discard their learning tables, or
  - that they should switch to use RB2.

I haven't looked at the options in detail, but perhaps we can do the 
first by RB2 injecting a toplogy change BPDU?
For the second approach, one could envision the RBs at the edge 
presenting themselves as a bridge with a low cost to an imaginary root 
bridge (which represents the rbridge core)? Of course, we can't ensure 
that the imaginary becomes the root bridge; the best we can do is to 
have it have a high probability of becoming the root bridge from the 
perspective of the bridged cloud at this part of the edge.
I don't think this requires that BPDUs be carried across the rbridged 
cloud - each bridged cloud at the edges can be treated as separate.

I don't know how fancy we need to be here, but waiting for the learning 
tables to time out when there is an RB failures seems a bid bad.

    Erik

Date: Wed, 12 Oct 2005 19:16:07 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2932

Harald Tveit Alvestrand wrote:

> My worry is the end-user PC that attaches to an rbridge, calls itself an 
> rbridge, and injects fake mappings for another PC in order to deny service 
> to someone he doesn't like. Or perhaps sniff/modify the traffic ala 
> "dsniff".
> 
> I guess you could do the same thing with spanning tree.... the defense is 
> probably to let the bridges distinguish between "core ports" and "user 
> ports" - but then we're out of the "automatic" configuration space again....

Yes, you can do similar things with spanning tree; the details might be 
a bit different though.

I think the requirement for TRILL should be to do no harm, which I 
interpret as not being any worse than a bridged network. We can easily 
do that without any configuration.

There are two ways I think we can do better, but it requires 
configuration. The first one is to use the features in the routing 
protocol to make sure that your PC can't spoof routing protocol updates. 
As Bill said, this doesn't require distinguishing between different type 
of ports on the rbridges.

But since at the edge the rbridges, just like bridges, need to learn the 
location of the MAC address from received frames, this still doesn't 
prevent your PC from sourcing packets with my MAC address, thereby 
causing packets to be routed towards you. This is compatible with bridge 
behavior ;-)

If we want to prevent this we need something different (hence 
incompatible) at the edge. One way would be to use 802.1X at the edge, 
and some EAP backend which associates the authenticated identity with 
the allowed MAC address. If you do that, then the rbridges don't need to 
learn from received packets but can instead use the completion of the 
802.1X EAP exchange as the time when the route is injected.

Bill Sommerfeld wrote:

 > Indeed.  And to toss in another wrinkle, I may want my multi-ported
 > server to appear on the rbridge cloud simultaneously at multiple points
 > without necessarily being willing to provide "transit" to anything other
 > than the real or virtual end systems inside my box.

I assume you might want to be able to have a single MAC address and 
receive packets over multiple ports - with the rbridges using the 
shortest path. Is this correct?

That is more of a functional problem than a security problem I think.
Since end stations might move around, one would assume that when a MAC 
address appears on a different port, perhaps on a different rbridge as 
well, that the host has moved. Thus it would make sense to add the route 
which points to the new place, and remove the route that points to the 
old place.

But in your case you would need that both routes remain in place 
somehow. Perhaps we can do that by being smarter about when we remove a 
route for a MAC address?

I don't think 802.1X type security changes this, because 802.1X doesn't 
(reliably) indicate when something goes away.

    Erik

Content-class: urn:content-classes:message
Date: Wed, 12 Oct 2005 21:54:48 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 704

> Instead, the normal case should be for RBridges
> to terminate the local broadcast domain 

  No argument about the 'should'. I was simply trying to
understand if this is an absolute 'must'. Your statement
below implies this is an absolute 'must' or STP breaks.
So I guess I need to take out a sheet of paper and try
to understand how...

  Cheers,

  Peter

> If they do not, then there may be scenarios in
which a bridge - thinking that an RBridge is another
bridge - will make an incorrect assumption about the
forwarding state of the local port of that "bridge".
There are doubtless many ways we could finesse this,
but what would we gain from doing so other than a lot
of needless complexity?

Date: Wed, 12 Oct 2005 14:46:02 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 745

>> 	No, actually, it is not like saying that.

    I think the fundamental question that needs to be answered is does an 
    RBridge network proivde a layer-2 serivce. And I think the answer should
    be yes. Therefore any frames that are sent on such a network should be 
    forwarded.

    Two bridges connected via a cable or an RBridge-based network should 
    look no different. The two bridges should be able to run STP over it and 
    decide if the ports leading to such a network are in Blocked or Forward 
    state.

    The RBridges should forward such packets like any other frames. The only
    frames that RBridges will consume and process are IS-IS packets (which
    will be multicasted on a *new MAC group address*).

Dino

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Wed, 12 Oct 2005 18:35:35 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 6450

Peter,

	With some exceptions (already discussed between
Dino and Radia), we don't want an STP based spanning
tree being setup across RBridges.

	There are a lot of potential interaction models
between bridges and RBridges. RBridges could be made
to appear transparent to bridges, but this is not the
reason why RBridges are being defined, nor would we
need to define - or use - an encapsulation between 
pairs of RBridges if this is all we wanted to do.

	Instead, the normal case should be for RBridges
to terminate the local broadcast domain and the local
STP-based spanning tree. To do this, RBridges should
act as if they were hosts to STP and ignore it.

	If they do not, then there may be scenarios in
which a bridge - thinking that an RBridge is another
bridge - will make an incorrect assumption about the
forwarding state of the local port of that "bridge".
There are doubtless many ways we could finesse this,
but what would we gain from doing so other than a lot
of needless complexity?

	For specific exceptions, it is possible to use
tunneling to create additional "virtual link(s)" -
between a broadcast domain on one side (RBridge port)
and one or more other broadcast domains on (an)other
side (RBridge port).  In this case, the RBridges that
are involved would absolutely pass all traffic between
each such broadcast domains - including flooded and
BPDU frames - most likely without looking at them.
In this sense, such exceptions would appear to the 
broadcast domains (and any directly attached bridges)
as a Hub - i.e. - they would be transparent except to
the extent that they would make multiple connections
possible.

	Because RBridges in this case would appear as a
Hub, it would then be up to the STP between bridges
in each connected broadcast domain to ensure that a
loop-free STP exists.  This works today, and we have 
no reason to suspect that it should not work in the
future.

	Another model that has been suggested is that
the RBridges in this case would act like an aggregate
bridge.  This could be done, but it cannot be done as
the default because - as has been indicated previously 
- it is not possible for RBridges to distinguish LANs
that are "outside" the RBridge domain from LANs that 
are "inside" the RBridge domain except by configuration.

	If the RBridges are configured to act as a bridge
in the aggregate, then the IS-IS MAC reachability will
need to provide sufficient information to those RBridges
to allow them to effectively populate filtering database
information for the "outward" facing RBridge ports, and 
those ports will have to collectively participate in STP 
across the "outside" collective broadcast domains - to 
include managing port forwarding state.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Peter Ashwood-Smith
--> Sent: Wednesday, October 12, 2005 4:20 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> 
--> What 'precisely' is the problem with a BPDU getting through 
--> an Rbriged
--> network ? It certainly does not break Rbridge so how does 
--> it break STP?
--> 
--> The designated Rbridge pretty much ensures that the STP on each side
--> only sees one link to it, the STP protocol should continue 
--> normally on
--> either side of the Rbridge. No?
--> 
--> 
--> Peter
--> 
--> 
--> 
--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On
--> Behalf Of Gray, Eric
--> Sent: Wednesday, October 12, 2005 3:46 PM
--> To: 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> Dino,
--> 
--> 	No, actually, it is not like saying that.
--> 
--> 	Given that we expect to have bridges between Rbridges
--> (though they're supposed to be invisible to RBridges), and
--> the fact that we expect to have Rbridges connected to each 
--> other, it is
--> not at all bizarre to expect that we might end up with a bridge
--> connected to an RBridge on the same port that the RBridge 
--> is connected
--> to another RBridge.  Like this:
--> 
--> 
--> 	RB-1 ---+--- RB-2
-->               |
-->               |
-->              B-3
-->               |
-->               |
-->       RB-4 ---+
--> 
--> Moreover, there should be nothing problematic about this 
--> topology either as it will look to the RBridges like this:
--> 
-->       RB-1 ---+--- RB-2
-->               |
-->               |
-->             RB-4
--> 
--> And to B-3 like this:
--> 
-->        H-1 ---+--- H-2
-->               |
-->               |
-->              B-3
-->               |
-->               |
-->              H-4
--> 
--> As you implied, the normal case is that enclosing RBridges
--> - like routers - will look to enclosed bridges like hosts.
--> I merely stated that RBridges - like hosts - can ignore any 
--> BPDUs they
--> receive.
--> 
--> --
--> Eric
--> 
--> --> -----Original Message-----
--> --> From: [email-masked]
--> --> [mailto:[email-masked]]On
--> --> Behalf Of Dino Farinacci
--> --> Sent: Wednesday, October 12, 2005 3:08 PM
--> --> To: [email-masked]
--> --> Cc: [email-masked]
--> --> Subject: Re: [rbridge] loops in trill networks
--> --> 
--> --> 
--> --> >> 	I believe that many of today's bridges can be 
--> configured to not 
--> --> >> send BPDUs on specific ports, but we do _not_ want 
--> to rely on 
--> --> >> this.  For example, what do we do if both a bridge 
--> and an RBridge
--> 
--> --> >> are connected to the same port of the bridge we are 
--> talking about
--> 
--> --> >> (imagine a simple Hub between three+ devices)?
--> --> 
--> -->     This is like saying if you run IS-IS on an interface
--> --> you should not run
--> -->     OSPF on the interface. And to make sure you don't the 
--> --> IS-IS standard
--> -->     states you must drop all other protocol messages. Which 
--> --> it does not!
--> --> 
--> --> Dino    
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked] 
http://www.postel.org/mailman/listinfo/rbridge
--> 
_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

[email-masked]

Content-class: urn:content-classes:message
Date: Wed, 12 Oct 2005 16:40:37 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3794

Yes, clearly but that is a SHOULD not a MUST. I was looking for the
MUST.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Saikat Ray
Sent: Wednesday, October 12, 2005 4:30 PM
To: 'Developing a hybrid router/bridge.'
Subject: Re: [rbridge] loops in trill networks

I think one wants to make the spanning tree fragments as small as
possible.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Ashwood-Smith
Sent: Wednesday, October 12, 2005 4:20 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

What 'precisely' is the problem with a BPDU getting through an Rbriged
network ? It certainly does not break Rbridge so how does it break STP?

The designated Rbridge pretty much ensures that the STP on each side
only sees one link to it, the STP protocol should continue normally on
either side of the Rbridge. No?

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gray, Eric
Sent: Wednesday, October 12, 2005 3:46 PM
To: 'Developing a hybrid router/bridge.'
Subject: Re: [rbridge] loops in trill networks

Dino,

	No, actually, it is not like saying that.

	Given that we expect to have bridges between Rbridges
(though they're supposed to be invisible to RBridges), and
the fact that we expect to have Rbridges connected to each other, it is
not at all bizarre to expect that we might end up with a bridge
connected to an RBridge on the same port that the RBridge is connected
to another RBridge.  Like this:

	RB-1 ---+--- RB-2
              |
              |
             B-3
              |
              |
      RB-4 ---+

Moreover, there should be nothing problematic about this 
topology either as it will look to the RBridges like this:

      RB-1 ---+--- RB-2
              |
              |
            RB-4

And to B-3 like this:

       H-1 ---+--- H-2
              |
              |
             B-3
              |
              |
             H-4

As you implied, the normal case is that enclosing RBridges
- like routers - will look to enclosed bridges like hosts.
I merely stated that RBridges - like hosts - can ignore any BPDUs they
receive.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Dino Farinacci
--> Sent: Wednesday, October 12, 2005 3:08 PM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> >> 	I believe that many of today's bridges can be configured to not
--> >> send BPDUs on specific ports, but we do _not_ want to rely on 
--> >> this.  For example, what do we do if both a bridge and an RBridge

--> >> are connected to the same port of the bridge we are talking about

--> >> (imagine a simple Hub between three+ devices)?
--> 
-->     This is like saying if you run IS-IS on an interface you should 
--> not run
-->     OSPF on the interface. And to make sure you don't the
--> IS-IS standard
-->     states you must drop all other protocol messages. Which 
--> it does not!
--> 
--> Dino    
--> _______________________________________________
--> rbridge mailing list
--> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
--> 
_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Wed, 12 Oct 2005 16:30:26 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] loops in trill networks
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3323

I think one wants to make the spanning tree fragments as small as possible.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Ashwood-Smith
Sent: Wednesday, October 12, 2005 4:20 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

What 'precisely' is the problem with a BPDU getting through an Rbriged
network ? It certainly does not break Rbridge so how does it break STP?

The designated Rbridge pretty much ensures that the STP on each side
only sees one link to it, the STP protocol should continue normally on
either side of the Rbridge. No?

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gray, Eric
Sent: Wednesday, October 12, 2005 3:46 PM
To: 'Developing a hybrid router/bridge.'
Subject: Re: [rbridge] loops in trill networks

Dino,

	No, actually, it is not like saying that.

	Given that we expect to have bridges between Rbridges
(though they're supposed to be invisible to RBridges), and
the fact that we expect to have Rbridges connected to each other, it is
not at all bizarre to expect that we might end up with a bridge
connected to an RBridge on the same port that the RBridge is connected
to another RBridge.  Like this:

	RB-1 ---+--- RB-2
              |
              |
             B-3
              |
              |
      RB-4 ---+

Moreover, there should be nothing problematic about this 
topology either as it will look to the RBridges like this:

      RB-1 ---+--- RB-2
              |
              |
            RB-4

And to B-3 like this:

       H-1 ---+--- H-2
              |
              |
             B-3
              |
              |
             H-4

As you implied, the normal case is that enclosing RBridges
- like routers - will look to enclosed bridges like hosts.
I merely stated that RBridges - like hosts - can ignore any BPDUs they
receive.

--
Eric

--> -----Original Message-----
--> From: [email-masked]
--> [mailto:[email-masked]]On
--> Behalf Of Dino Farinacci
--> Sent: Wednesday, October 12, 2005 3:08 PM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> >> 	I believe that many of today's bridges can be configured to not 
--> >> send BPDUs on specific ports, but we do _not_ want to rely on 
--> >> this.  For example, what do we do if both a bridge and an RBridge

--> >> are connected to the same port of the bridge we are talking about

--> >> (imagine a simple Hub between three+ devices)?
--> 
-->     This is like saying if you run IS-IS on an interface
--> you should not run
-->     OSPF on the interface. And to make sure you don't the 
--> IS-IS standard
-->     states you must drop all other protocol messages. Which 
--> it does not!
--> 
--> Dino    
--> _______________________________________________
--> rbridge mailing list
--> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
--> 
_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

[email-masked]

Content-class: urn:content-classes:message
Date: Wed, 12 Oct 2005 16:20:18 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2852

What 'precisely' is the problem with a BPDU getting through an Rbriged
network ? It certainly does not break Rbridge so how does it break STP?

The designated Rbridge pretty much ensures that the STP on each side
only sees one link to it, the STP protocol should continue normally on
either side of the Rbridge. No?

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gray, Eric
Sent: Wednesday, October 12, 2005 3:46 PM
To: 'Developing a hybrid router/bridge.'
Subject: Re: [rbridge] loops in trill networks

Dino,

	No, actually, it is not like saying that.

	Given that we expect to have bridges between Rbridges
(though they're supposed to be invisible to RBridges), and
the fact that we expect to have Rbridges connected to each other, it is
not at all bizarre to expect that we might end up with a bridge
connected to an RBridge on the same port that the RBridge is connected
to another RBridge.  Like this:

	RB-1 ---+--- RB-2
              |
              |
             B-3
              |
              |
      RB-4 ---+

Moreover, there should be nothing problematic about this 
topology either as it will look to the RBridges like this:

      RB-1 ---+--- RB-2
              |
              |
            RB-4

And to B-3 like this:

       H-1 ---+--- H-2
              |
              |
             B-3
              |
              |
             H-4

As you implied, the normal case is that enclosing RBridges
- like routers - will look to enclosed bridges like hosts.
I merely stated that RBridges - like hosts - can ignore any BPDUs they
receive.

--
Eric

--> -----Original Message-----
--> From: [email-masked]
--> [mailto:[email-masked]]On
--> Behalf Of Dino Farinacci
--> Sent: Wednesday, October 12, 2005 3:08 PM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> >> 	I believe that many of today's bridges can be configured to not 
--> >> send BPDUs on specific ports, but we do _not_ want to rely on 
--> >> this.  For example, what do we do if both a bridge and an RBridge

--> >> are connected to the same port of the bridge we are talking about

--> >> (imagine a simple Hub between three+ devices)?
--> 
-->     This is like saying if you run IS-IS on an interface
--> you should not run
-->     OSPF on the interface. And to make sure you don't the 
--> IS-IS standard
-->     states you must drop all other protocol messages. Which 
--> it does not!
--> 
--> Dino    
--> _______________________________________________
--> rbridge mailing list
--> [email-masked] http://www.postel.org/mailman/listinfo/rbridge
--> 
_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Wed, 12 Oct 2005 16:45:38 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2138

Dino,

	No, actually, it is not like saying that.

	Given that we expect to have bridges between Rbridges
(though they're supposed to be invisible to RBridges), and
the fact that we expect to have Rbridges connected to each
other, it is not at all bizarre to expect that we might end
up with a bridge connected to an RBridge on the same port
that the RBridge is connected to another RBridge.  Like this:

	RB-1 ---+--- RB-2
              |
              |
             B-3
              |
              |
      RB-4 ---+

Moreover, there should be nothing problematic about this 
topology either as it will look to the RBridges like this:

      RB-1 ---+--- RB-2
              |
              |
            RB-4

And to B-3 like this:

       H-1 ---+--- H-2
              |
              |
             B-3
              |
              |
             H-4

As you implied, the normal case is that enclosing RBridges
- like routers - will look to enclosed bridges like hosts.
I merely stated that RBridges - like hosts - can ignore any
BPDUs they receive.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Dino Farinacci
--> Sent: Wednesday, October 12, 2005 3:08 PM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> >> 	I believe that many of today's bridges can be configured
--> >> to not send BPDUs on specific ports, but we do _not_ want to
--> >> rely on this.  For example, what do we do if both a bridge and
--> >> an RBridge are connected to the same port of the bridge we are
--> >> talking about (imagine a simple Hub between three+ devices)?
--> 
-->     This is like saying if you run IS-IS on an interface 
--> you should not run
-->     OSPF on the interface. And to make sure you don't the 
--> IS-IS standard
-->     states you must drop all other protocol messages. Which 
--> it does not!
--> 
--> Dino    
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Wed, 12 Oct 2005 12:08:11 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 554

>> 	I believe that many of today's bridges can be configured
>> to not send BPDUs on specific ports, but we do _not_ want to
>> rely on this.  For example, what do we do if both a bridge and
>> an RBridge are connected to the same port of the bridge we are
>> talking about (imagine a simple Hub between three+ devices)?

    This is like saying if you run IS-IS on an interface you should not run
    OSPF on the interface. And to make sure you don't the IS-IS standard
    states you must drop all other protocol messages. Which it does not!

Dino    

Date: Wed, 12 Oct 2005 10:14:16 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2198

Gray, Eric wrote:
> Joe/Radia,
> 
> 	While the case in which a new RBridge does not partition 
> the bridged network is uninteresting from the perspective that
> we want to take to figure out how the presence of RBridges is
> going to make networking more efficient, useful and exciting -
> it is extremely interesting from the perspective of how does a
> network continue to work while RBridges are in the process of
> being deployed.
> 
> 	For example, in the case Radia mentioned in which there
> appears to be an unpartitioned network after replacing one or
> more of the bridges with one or more RBridge(s).  From what 
> Radia and others have been saying, the network still works for
> all forms of traffic for which it previously worked. A ST will
> be determined between bridges and the (one or more) RBridges
> will sit there doing nothing interesting (or disruptive).

It *is* distruptive if it blocks previous spanning tree paths, since
it'd end up creating a detour in the spanning tree which might cause
paths to be much more circuitous.

> 	This would also be the case when an RBridge is added to
> a network topology where no previous bridge existed.

That ought to do not much, AFAICT.

> 	Subsequently, one or more additional bridges are replaced
> by Rbridges.  This time, the previously existing ST is segmented
> (as would imediately be the case when the existing bridge was
> removed, even before adding the RBridge).  Again, from what has
> been said, the network will now work again for all forms of 
> traffic for which it previously worked.  The difference is that
> - as Radia said - the RBridges are now doing interesting stuff.

Once the spanning tree is segmented; the trick is that I don't think we
can know where to deploy rbridges to *force* segmentation. We can know
where we disrupt the existing spanning tree, but not where we need to be
to partition it.

Joe

Date: Wed, 12 Oct 2005 10:09:07 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and	applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1470

Michael Smith (michsmit) wrote:
>>From: [email-masked] 
>>
> Here's a proposed abstract.
> 
> Thoughts appreciated.
> 
> Joe
> 
> -----
> 
> RBridges are layer-2 devices that automatically aggregate 
> into a virtual device that emulates a single bridge on a 
> conventional 802.1 Ethernet.
> 
> 
>> Within this mailing list, I think the above statement is understood but
>> to the rest of the community, I think it would be very confusing.  It
>> gives the impression that the set of rbridges are managed as a single
>> device, source L2 protocols as if from the same device, etc.  I would
>> summarize Rbridges as simply a new form of L2 bridges which use routing
>> protocols as the control plane. 

That's better, IMO.

>> A secondary point is that they
>> terminate the spanning tree domain of current bridges and attempt to
>> retain as much of the "plug-and-play" aspects of current bridges as
>> possible.  They don't really emulate a single bridge.

Agreed - but I'm not sure whether the abstract needs to address spanning
tree termination - does it? It should say the part about retaining... as
well.

Joe

Date: Wed, 12 Oct 2005 10:07:13 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and	applicabi lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1740

Gray, Eric wrote:
> Joe,
> 
> 	The way I interpret Loa's question is "do we expect that
> we will have to apply concerns about security similar to those
> we have to apply to routing?"  I don't think the question has
> to do with any expectation that RBridges _generally_ act like
> routers.

Agreed; sorry to pick that nit ;-)

> 	The answer to this question is that we cannot leave the
> security issues unanswered.  We can say that we will introduce
> no new security issues, but that's not automatic.  We plan to
> use IS-IS to propagate reachability information and security 
> concerns that apply generally to IS-IS, will apply also to
> RBridges.  In addition, we plan to change the way L2 networks
> work in a way that allows for larger L2 broadcast domains and
> may introduce new security exposures from this as well.

IS-IS acts similarly to the existing spanning tree; we need to address
its stability to attacks vs. that to a spanning tree. So that looks like
a security issue, but not one where the rbridge is intended to be more
secure.

I.e., all security issues I'm thinking of reduce to 'is this as secure
as a bridged L2'.

As to larger domains, that's been out of scope for a while. The point of
the work is increased functionality - not scale. We probably will need
to address the fact that increased functionality may lead to larger
deployments, but these aren't larger than a conventional L2 _could_ support.

Joe

Content-class: urn:content-classes:message
Date: Wed, 12 Oct 2005 09:26:12 -0700
From: "Michael Smith \(michsmit\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2339

> From: [email-masked] 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Here's a proposed abstract.
> 
> Thoughts appreciated.
> 
> Joe
> 
> - -----
> 
> RBridges are layer-2 devices that automatically aggregate 
> into a virtual device that emulates a single bridge on a 
> conventional 802.1 Ethernet.

Within this mailing list, I think the above statement is understood but
to the rest of the community, I think it would be very confusing.  It
gives the impression that the set of rbridges are managed as a single
device, source L2 protocols as if from the same device, etc.  I would
summarize Rbridges as simply a new form of L2 bridges which use routing
protocols as the control plane.  A secondary point is that they
terminate the spanning tree domain of current bridges and attempt to
retain as much of the "plug-and-play" aspects of current bridges as
possible.  They don't really emulate a single bridge.

Michael

> 
> (I had thought that was a concise description, but with 
> recent discussion about non-participation in some bridge 
> protocols, I'm not sure. I still think the rbridge MUST 
> participate in order to avoid loops, but if that's 
> contentious it can't be part of the abstract yet...)
> 
> They combine layer 2?s ability to allow hosts to reattach 
> without renumbering with layer 3?s routing benefits. RBridges 
> use existing link state routing to provide higher internal 
> cross-section bandwidth, faster convergence under 
> reconfiguration, and more robustness to link interruption 
> than an equivalent set of conventional bridges using existing 
> spanning tree forwarding. They are intended to apply to similar
> L2 network sizes as conventional bridges and are intended to 
> be backward compatible with those bridges as well. This 
> document describes the need for RBridges and describes 
> situations where it will be useful.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDTFz0E5f5cImnZrsRAh/nAKCbhP6eVoNCX97zC9/L2zT0WXq9rQCdHBz/
> j6oUNPt5Rmv657FhszmCZzg=
> =EpCS
> -----END PGP SIGNATURE-----
> [email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Wed, 12 Oct 2005 13:09:17 -0300
Subject: Re: [rbridge] seeking input on abstract for problem and applicabi	lity statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2486

Joe,

	The way I interpret Loa's question is "do we expect that
we will have to apply concerns about security similar to those
we have to apply to routing?"  I don't think the question has
to do with any expectation that RBridges _generally_ act like
routers.

	The answer to this question is that we cannot leave the
security issues unanswered.  We can say that we will introduce
no new security issues, but that's not automatic.  We plan to
use IS-IS to propagate reachability information and security 
concerns that apply generally to IS-IS, will apply also to
RBridges.  In addition, we plan to change the way L2 networks
work in a way that allows for larger L2 broadcast domains and
may introduce new security exposures from this as well.

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Wednesday, October 12, 2005 11:34 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstract for problem and
--> applicability statement
--> 
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Loa Andersson wrote:
--> > 
--> > Joe Touch wrote:
--> > 
--> > <snip>
--> > 
--> > do we have any idea on to what level security enters into the
--> > trill work? not at all, or do the rbridges also in this respect
--> > behave as routers?
--> 
--> IMO, they behave as bridges - except perhaps in participation in the
--> spanning trees with bridges at their edge.
--> 
--> They do NOT behave as routers - they can't. Routers would kill
--> broadcasts, for one. Routers don't exist at L2 anyway - as 
--> far as the L2
--> is concerned, they're just nodes.
--> 
--> RBridge MAC addresses should only ever be known or used by other
--> rbridges, never by other nodes on the L2.
--> 
--> Joe
--> 
--> > /Loa
--> > 
--> > 
--> >>My understanding is that rbridges are not intended to fix 
--> any security
--> >>problems that persist with an equivalent deployment of bridges.
--> >>
--> > 
--> > 
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDTSz0E5f5cImnZrsRAuUmAJ9jcqFQjstl/E4Ua9r89LAsI0gmfgCgr4Aq
--> mDfONYAdHIoTZOD8swx2HPk=
--> =eG4G
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Wed, 12 Oct 2005 11:56:16 -0400
From: Stephen Suryaputra <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 8087

------=_Part_14351_8003839.1129132576300
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Let's see if I understand this: only designated Rbridge port
encapsulate L2 packet, forward, and decapsulate Rbridge (shim) packet
back to its L2 format. So, from forwarding point of view, non
designated port is not connected to the L2 network.

Please see the attached network diagram (A text file. Sorry, it's hard
to draw a text diagram using my email client) for the following
description.
A, B, C and D are endnodes. RB1 is the designated Rbridge for segment 1
(with i as the designated port, noted by an asterisk). RB3 is the designate=
d
Rbridge for segment 2 (j is the designated port).

D sends a broadcast frame. Only RB1 encapsulates the frame with the shim he=
ader
and forwards it unicast to the IS-IS spanning tree (to RB2, RB3 and RB4). R=
B2
and RB3 decapsulates the frame and send it to their endnodes, but RB4 does =
not
because it is not the designated Rbridge for segment 2.

If my understanding is correct, I agree that loops won't exist and
Rbridge does not need to participate in 802.1 spanning tree protocol.
The drawback is the broadcast frame is seen multiple times on segment
1. The description in section 2.3 of the draft on the role of
designated bridge and designated port must be clarified to avoid
confusion.

Stephen.

On 10/11/05, Radia Perlman <[email-masked]> wrote:
>  Re: Joe's comments about my scenario (first saying that
> replacing some bridges with RBridges may not partition the campus, which
> is true but not relevant
> to the point I was making, and second saying that RBridges have to join
> in the bridge spanning tree
> or else there will be loops, which is not true, and it's important that
> we all understand that).
>
> **********************
> There's confusion here. Sorry if I'm not explaining properly.
>
> Let's start over again with the steps I was saying:
>
> You start with one giant bridged campus. There is one spanning tree.
>
> Then you replace some of the bridges with RBridges.
>
> Pretend that the RBridges don't forward ANY packets.
>
> Now the campus is likely partitioned into several pieces, let's say 5,
> with no connectivity
> between the pieces.
>
> ***********
> Perhaps you are quibbling with "likely partitioned". If the
>  topology is such that the particular bridges you've replaced with RBridg=
es doesn't
> partition things, then you will wind up with what looks to the RBridges l=
ike they
> are all connected to the same link. One port of one will get elected Desi=
gnated RBridge.
> But it won't *do* anything. It won't decapsulate or encapsulate or forwar=
d any
> data packets. It will just sit there unless there is another "link" in th=
e topology.
> But all the RBridges just see a single link. Even if they have multiple p=
orts onto
> the same link.
>
> But I'm trying to explain a topology in which RBridges *will* do somethin=
g. That
> is when the topology, if you halted all the RBridges, *is* partitioned. S=
o assume
> you have replaced enough bridges with (for now halted) RBridges, so the w=
orld
> is partitioned into 5 pieces.
> **************
>
> Back to the story I was telling. To reiterate, you've either partitioned
> things, or you haven't. If you haven't,
> then the RBridges aren't doing anything. The bridges will all compute a
> single spanning tree that connects
> all the segments that the RBridges see, so all the RBridges see is the
> simple topology of them all connecting
> to a single link, and as I said, they won't be forwarding any data
> packets. The only thing they'll be doing is
> transmitting LSPs and Hello messages. But none of them will forward
> anything. That's not a very interesting
> topology. Let's get on to what happens in the interesting case.
>
> So now let's assume you have managed to partition the campus. Then let's
> continue with what I was saying:
>
> *************
>
> The bridges in each partition compute their own spanning tree, with their
>  own Root bridge. The different spanning trees will not see each other, a=
nd will not merge (because we've said the RBridges are not forwarding the B=
PDUs).
>
> Now let's turn on the RBridges, and let them do their thing.
>
>
> Each of the pieces looks to the RBridges like a single link. The
> RBridges don't see the difference between
> a single Ethernet segment, or a bridged Ethernet segment. Just like
> routers don't see the bridges.
>
> So now we can ignore the bridges, and think of a topology consisting of
> 5 links, and a bunch of
> RBridges connecting the links. Some of the RBridges might have multiple
> ports onto the same link.
>
> Now the RBridges are similar to routers, where they compute optimal
> paths between each other, over those
> "links".
>
> Everything works, just as it works to have routers connected in an
> arbitrary topology over an arbitrary
> set of links.
>
> ***************
>
> I hope I'm making things clearer...
>
> Radia
>
>
> Now you (Joe) said:
>
> >Those links can touch the rbridge in multiple places - there's no reason
> >they necessarily connect to a single port.
> >
> What happens if an RBridge has two ports onto what it sees as the same
> "link" is that only one of
> the ports winds up Designated. So an RBridge will not decapsulate a
> packet onto port i and then
> pick it up and encapsulate it on port j, if the RBridge things that port
> i and port j are the same link,
> which it will, if port i and j are connected through a path of bridges.
>
> It is most definitely the case that RBridges do not participate in, nor
> do they need to participate in,
> the bridge spanning tree protocol. They need to have a forwarding entry
> for the multicast address
> on which the BPDUs are sent, to *not forward* packets sent to that
> multicast address.
>
> Radia
>
>
>
> > While this is OK for the
> >rbridge egress (it picks one designated rbridge on that link to send
> >things out), it's entirely possible that a broadcast will end up cycling
> >back over that link to another ingress port.
> >
> >That's why the rbridge needs to be in the spanning tree protocol.
> >Otherwise the 'links' outside can loop back onto the rbridge.
> >
> >Joe
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG  v1.2.4 (MingW32)
> >Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> >
> >iD8DBQFDTD7mE5f5cImnZrsRAp+lAJ91dAP3vrxQDXiaU2gRHC1a+1slQwCg3Ssk
> >UPKxoEu4qB+tJlVtDS8ylRo=3D
> >=3Dwc2h
> >-----END PGP SIGNATURE-----
> >[email-masked]
> [email-masked]

------=_Part_14351_8003839.1129132576300
Content-Type: text/plain; name="Understanding Designated Rbridge.txt"; 
	charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Understanding Designated Rbridge.txt"

Physical topology
-----------------

                  segment 1
                  |
             D----+
                  |   *+-------+*
                  +----+i RB1 j+----A
                  |    +-------+
    *+-------+    |
C----+i RB2 j+----+                 segment 2
     +-------+    |    +-------+*   |
                  +----+i RB3 j+----+
                  |    +-------+    |
                  |                 +----B
                  |    +-------+    |
                  +----+i RB4 j+----+
                  |    +-------+    |

Topology from Rbridge point of view
-----------------------------------

                 D   A            
                 |   |
                 |   |
     +-----+    +-----+     +-----+
C----+ RB2 +====+ RB1 +=====+ RB3 +----B
     +-----+    +-----+     +-----+
                  ||
                  ||
                  ||
                +-----+
                + RB4 +
                +-----+

------=_Part_14351_8003839.1129132576300--

Date: Wed, 12 Oct 2005 08:37:26 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem	and	applicability statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2894

Bill Sommerfeld wrote:
> I support "can automatically" because the customers will always want
> knobs.
> (Seems we're arguing about defaults).

Yes, I think so.

>>Joe Touch wrote:
>>
>>>'can' implies they might not, which would be bad (consider bridges that
>>>refused to participate in spanning tree).
> 
> I've run into managed switches which, as best as I can tell, came from
> the factory with spanning tree turned off by default.  

Are those compliant? Or is that just a vendor choice to distribute them
in non-compliant mode for some reason?

> Harald wrote:
> 
>>My worry is the end-user PC that attaches to an rbridge, calls itself an 
>>rbridge, and injects fake mappings for another PC in order to deny service 
>>to someone he doesn't like. Or perhaps sniff/modify the traffic ala 
>>"dsniff".
> 
> Indeed.  And to toss in another wrinkle, I may want my multi-ported
> server to appear on the rbridge cloud simultaneously at multiple points
> without necessarily being willing to provide "transit" to anything other
> than the real or virtual end systems inside my box. 

That's not a wrinkle. That's a single physical box that - as far as L2
is concerned - *IS* multiple nodes on the L2.

L2 doesn't care whether a node is an L3 transit (router) or an L3
source/sink (host). Nodes are L2 sources/sinks, and everything else is a
link or emulation thereof (bridges, hubs, etc.)

>>I guess you could do the same thing with spanning tree.... the defense is 
>>probably to let the bridges distinguish between "core ports" and "user 
>>ports" - but then we're out of the "automatic" configuration space again.... 
> 
> Yep.  People who actually manage their networks will want those knobs.

Sure. Right now, ports can be both core and user at the same time, but
there could be options to prohibit traffic of either type.

> On the other hand, given crypto authentication support in the underlying
> routing protocol, the "core" vs "user" distinction might be managed by
> what the other device "knows" rather than by which port it's plugged
> into.

'core' traffic is defined by the existence of the campus transit header
(CTH) [the shim header].

everything else is user traffic.

There's no need to designate the two per-port; the rbridge device
already needs to know the distiction between the two. Core is forwarded
or decapsulated (if the L2 destination matches); edge is encapsulated
and forwarded.

While crypto for campus routing would be nice, it's like crypto for the
spanning tree - it would inhibit plug-and-play, and the lack of it
doesn't add a new vulnerability.

Joe

Date: Wed, 12 Oct 2005 08:34:12 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1071

Loa Andersson wrote:
> 
> Joe Touch wrote:
> 
> <snip>
> 
> do we have any idea on to what level security enters into the
> trill work? not at all, or do the rbridges also in this respect
> behave as routers?

IMO, they behave as bridges - except perhaps in participation in the
spanning trees with bridges at their edge.

They do NOT behave as routers - they can't. Routers would kill
broadcasts, for one. Routers don't exist at L2 anyway - as far as the L2
is concerned, they're just nodes.

RBridge MAC addresses should only ever be known or used by other
rbridges, never by other nodes on the L2.

Joe

> /Loa
> 
> 
>>My understanding is that rbridges are not intended to fix any security
>>problems that persist with an equivalent deployment of bridges.
>>
> 
> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Wed, 12 Oct 2005 12:36:00 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5136

Joe/Radia,

	While the case in which a new RBridge does not partition 
the bridged network is uninteresting from the perspective that
we want to take to figure out how the presence of RBridges is
going to make networking more efficient, useful and exciting -
it is extremely interesting from the perspective of how does a
network continue to work while RBridges are in the process of
being deployed.

	For example, in the case Radia mentioned in which there
appears to be an unpartitioned network after replacing one or
more of the bridges with one or more RBridge(s).  From what 
Radia and others have been saying, the network still works for
all forms of traffic for which it previously worked. A ST will
be determined between bridges and the (one or more) RBridges
will sit there doing nothing interesting (or disruptive).

	This would also be the case when an RBridge is added to
a network topology where no previous bridge existed.

	Subsequently, one or more additional bridges are replaced
by Rbridges.  This time, the previously existing ST is segmented
(as would imediately be the case when the existing bridge was
removed, even before adding the RBridge).  Again, from what has
been said, the network will now work again for all forms of 
traffic for which it previously worked.  The difference is that
- as Radia said - the RBridges are now doing interesting stuff.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Tuesday, October 11, 2005 11:04 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier, Joe said...

Radia Perlman wrote:
...
> But I'm trying to explain a topology in which RBridges *will* do
something. That
> is when the topology, if you halted all the RBridges, *is* partitioned. So
assume
> you have replaced enough bridges with (for now halted) RBridges, so the
world
> is partitioned into 5 pieces.

AOK - I was thinking of this in particular for the applicability part of
the problem/applicability statement.

The catch is that this is going to be less useful if this is required
but cannot be detected or encouraged somehow.

...
> Now let's turn on the RBridges, and let them do their thing.
> 
> Each of the pieces looks to the RBridges like a single link. The 
> RBridges don't see the difference between
> a single Ethernet segment, or a bridged Ethernet segment. Just like 
> routers don't see the bridges.

You've said here and before that the rbridge looks like a router - but
it does not, because routers have ethernet addresses and source and sink
packets.

Routers and hosts are just nodes on a ethernet segment, nodes that have
802 addresses. Now if the rbridge has an 802 address, then we have a big
problem about how to cross the rbridge and come out the right place - we
need to do proxy ARP on all the external links, we need to rewrite the
packets we receive, and we potentially pollute the ARP caches of nodes
on the links that then move elsewhere in the system.

So we need to have some other analogy - e.g., it's a bridge that blocks
BPDUs.

Back to the key question...
...
>>Those links can touch the rbridge in multiple places - there's no reason
>>they necessarily connect to a single port.
> 
> What happens if an RBridge has two ports onto what it sees as the same 
> "link" is that only one of
> the ports winds up Designated. So an RBridge will not decapsulate a 
> packet onto port i and then
> pick it up and encapsulate it on port j, if the RBridge things that port 
> i and port j are the same link,
> which it will, if port i and j are connected through a path of bridges.

OK. I'm understanding the trick -maybe.

Basically, there's effectively a phantom spanning tree inside the
rbridge. You just made one by saying there's exactly one 'designated' port.

So I *can* think of this as one big bridge. One that has internal logic
that makes sure that it touches each spanning tree it sees externally in
one place (isn't that what spanning tree does?) and then ends up acting
like a terminus on each spanning tree (again, what spanning tree does).
So although BPDUs aren't forwarded, the net effect of a spanning tree is
retained.

So maybe (***here's the interesting point, IMO - if I understand this
now***) this also works for bridges.

They don't strictly need to forward BPDUs either (by analogy). All they
need to do is act sufficiently like an rbridge campus and things will
work - and the spanning trees will be partitioned.

Can anyone explain to me why this won't work with a regular bridge if we
built it? And if it did, wouldn't it make the spanning trees a LOT
simpler at the edges?

All we have to do is make sure these 'magic bridges' are deployed in
ways that partition the existing bridges into non-connected stubs -
which we have to figure a way to do with rbridges too.

So does that work? (and if so, has anybody tried it?)

Joe

Content-class: urn:content-classes:message
Date: Wed, 12 Oct 2005 11:23:01 -0400
From: "Peter Ashwood-Smith" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicabilitystatement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 913

> I still think the rbridge MUST participate in order to avoid loops, 
> but if that's contentious it can't be part of the abstract yet...)

Let me see if I can help. Radia gave a good description of why the
Rbridge does not need to participate in STP/FSTP but here is another way
to think of it and perhaps it will strike different chords:

Take two node disjoint trees A and B.

Now, connect the trees A and B with only ONE link. The result is still a
tree.

This is "sort of" what the combination of STP and Rbridge protocols are
doing.

STP computes one tree. Rbridge computes the other and finally Rbridge
connects the two with only ONE link using the designated Rbridge
concept.

Since we can apply this same mechanism over and over again, i.e.
induction we are guaranteed the end result is indeed one big tree and
therefore is loop free, ... at least in the steady state. 

Cheers,

Peter Ashwood-Smith

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Wed, 12 Oct 2005 12:18:23 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3365

Joe,

	If RBridges are connected by a single broadcast domain,
"outside" of the RBridge domain, this is the same as having a
common LAN/broadcast-domain inside the RBridge domain.  The
term "outside" is topologically meaningless.

	Consequently, the potential for looping traffic through
this "outside" broadcast domain is exactly the same as looping
traffic through an "inside" broadcast domain.  Therefore, the
same process for selecting a designated forwarder would be used
for either common broadcast domain.

	It should _not_ be done using STP. It is not necessary 
and results in the same disuse of redundant capacity as would
be the case without RBridges.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Tuesday, October 11, 2005 6:39 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Radia Perlman wrote:
--> > Let me try explaining it a different way.
--> > 
--> > You start with one giant bridged campus. There is one 
--> spanning tree.
--> > 
--> > Then you replace some of the bridges with RBridges.
--> > 
--> > Pretend that the RBridges don't forward ANY packets.
--> > 
--> > Now the campus is likely partitioned into several pieces, 
--> let's say 5, 
--> > with no connectivity
--> > between the pieces.
--> 
--> That's not necessarily likely. That would only occur if the 
--> network were
--> wired as a spanning tree; if we could expect that, we 
--> wouldn't need to
--> generate one.
--> 
--> I.e., it's more likely that such partitioning might not 
--> occur - however,
--> the rbridge system might not provide a benefit in those 
--> cases. AFAICT,
--> an rbridge helps only where it does partition the bridges as above.
--> 
--> Let's thus assume that's the case, as engineered:
--> 
--> > Each piece computes its own spanning tree, with its own 
--> Root bridge. So you
--> > have 5 independent, disconnected spanning trees.
--> > 
--> > Now think of each of those 5 pieces as a single link. The 
--> fact that each 
--> > piece
--> > is glued together with spanning tree with bridges is 
--> invisible outside 
--> > that piece. So we
--> > can stop thinking about bridges, and now only look at the 
--> next layer 
--> > up...the RBridges.
--> 
--> Those links can touch the rbridge in multiple places - 
--> there's no reason
--> they necessarily connect to a single port. While this is OK for the
--> rbridge egress (it picks one designated rbridge on that link to send
--> things out), it's entirely possible that a broadcast will 
--> end up cycling
--> back over that link to another ingress port.
--> 
--> That's why the rbridge needs to be in the spanning tree protocol.
--> Otherwise the 'links' outside can loop back onto the rbridge.
--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDTD7mE5f5cImnZrsRAp+lAJ91dAP3vrxQDXiaU2gRHC1a+1slQwCg3Ssk
--> UPKxoEu4qB+tJlVtDS8ylRo=
--> =wc2h
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Wed, 12 Oct 2005 12:09:19 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1834

Dino,

	I believe that many of today's bridges can be configured
to not send BPDUs on specific ports, but we do _not_ want to
rely on this.  For example, what do we do if both a bridge and
an RBridge are connected to the same port of the bridge we are
talking about (imagine a simple Hub between three+ devices)?

	Also, I am not sure that all bridges have this capability
- since it is not necessary even for hosts (hosts ignore BPDUs,
even if they get them).  If it is not necessary for any current
deployment, it is an unnecessary complication and may be left
out.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Dino Farinacci
--> Sent: Tuesday, October 11, 2005 8:10 PM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> >> As for providing glue to two broadcast domains in order to merge 
--> >> them...yes, an RBridged "campus"
--> >> could be used to tunnel packets from the two broadcast 
--> domains in order 
--> >> to merge them.
--> 
-->     Yes, agree.
--> 
--> >> But in general an RBridge would not forward a native 
--> BPDU. It would 
--> >> recognize it as something
--> >> it shouldn't forward. Because RBridges intend to make 
--> the spanning trees 
--> 
-->     So we have to put special checks in the hardware 
--> forwarding plane? I
-->     would rather not put this in the architecture and just 
--> document that
-->     bridges should not send BPDUs on links where rBridges 
--> exist. Just like
-->     bridges don't generally send BPDUs on host ports today.
--> 
--> Dino
--> 
--> 
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Wed, 12 Oct 2005 12:02:34 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 10778

Larry,

	I don't think we're disagreeing.  The trouble is in the 
phrase "spanning tree".  What I am trying to say is that how
frames are forwarded between RBridges (e.g. - RB3 and RB4) is
determined by a different protocol than is used to make the
same determination for frame forwarding between bridges.

	Yes, the effect is similar to a "spanning tree" as will
be determined by STP between bridges, but it is not the same.
For RBridges RB1, RB2, RB3 and RB4, the topology you posit is
going to be marginally simpler:

      A--RB1----+--RB2--B
          |     |
          |     |
      D--RB4---RB3--C

All of the RBridges see the topology this same way. I assume
that the difference between this and any other form of link
state routing is that routers aren't _normally_ concerned
with broadcast. However, routers will have to deal with IP
multicast, and the difference between broadcast and multicast
is not important, as the same topology issues arise in IP 
multicast routing - especially if you assume a majority of
routers in any locality might be serving the same multicast
group.

	We don't want to use STP to determine how to avoid loops
and duplicate transmissions because using a link-state routing
protocol allows us to make clever use of redundant connections.
This is the important logical distinction.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Larry Kreeger (kreeger)
--> Sent: Tuesday, October 11, 2005 7:42 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> Eric,
--> 
--> Notice that in my example below, I am only talking about broadcast
--> connectivity - not unicast.  There is not MAC advertisements for
--> broadcast.  A broadcast must go to every edge port.  In this case, a
--> spanning tree must exist (across both the RBridge and 802.1d bridged
--> network) or a broadcast loop will occur.
--> 
-->  - Larry
--> 
--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On
--> Behalf Of Gray, Eric
--> Sent: Tuesday, October 11, 2005 3:45 PM
--> To: 'Developing a hybrid router/bridge.'
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> Larry,
--> 
--> 	You have to think of bridges and RBridges as existing at two
--> layers.  How frames are forwarded between RBridges will be 
--> determined by
--> shortest path computation based on MAC advertisements in IS-IS.  How
--> frames are forwarded across
--> 802.1 bridges between RBridges is based on STP.
--> 
--> --
--> E
--> 
--> --> -----Original Message-----
--> --> From: [email-masked]
--> --> [mailto:[email-masked]]On
--> --> Behalf Of Larry Kreeger (kreeger)
--> --> Sent: Tuesday, October 11, 2005 5:08 PM
--> --> To: Developing a hybrid router/bridge.
--> --> Subject: Re: [rbridge] loops in trill networks
--> --> 
--> --> 
--> --> Radia,
--> --> 
--> --> How about the case where the two ports connected to the 
--> same bridged
--> 
--> --> domain are on different RBridges?
--> --> 
--> --> Consider, the following topology where A,B,C are hosts.
--> --> 
--> --> A--RB1--Bridged-Domain--RB2--B
--> -->               |
--> -->               |
--> -->              RB3--C
--> --> 
--> --> In this case, would all RB's forward a L2 broadcast to their 
--> --> respective edge ports?  I was assuming, yes.  If so, 
--> then RB1,RB2 
--> --> and
--> --> RB3 are all
--> --> designated RBs in order to have broadcast connectivity between 
--> --> A,B,C.
--> --> 
--> --> Now a new RB4 is added to the topology which connects 
--> RB1 and RB3,
--> --> 
--> --> A--RB1--Bridged-Domain--RB2--B
--> -->     |         |
--> -->     |         |
--> --> D--RB4-------RB3--C
--> --> 
--> --> Are you saying that RB1 and RB3 detect that they now have new 
--> --> connectivity and battle to be a Designated RB to serve 
--> their side of
--> 
--> --> the network?  Assuming RB3 wins, all broadcasts must 
--> enter and leave
--> 
--> --> the Bridged-Domain via RB3 to get between hosts A,C,D and B.
--> --> RB2 must still
--> --> be the Designated RB for traffic to reach B.
--> --> 
--> --> I didn't think routers needed to deal with this since 
--> they don't 
--> --> forward broadcasts.  Are you saying that routing 
--> protocols already 
--> --> deal with these types of scenarios?
--> --> 
--> --> Thanks, Larry
--> --> 
--> --> -----Original Message-----
--> --> From: [email-masked]
--> --> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> --> Sent: Tuesday, October 11, 2005 12:46 PM
--> --> To: Developing a hybrid router/bridge.
--> --> Subject: Re: [rbridge] loops in trill networks
--> --> 
--> --> The intention is that deployment not have to be 
--> careful. If two of 
--> --> an RBridge's ports are connected to the same bridged broadcast 
--> --> domain (i.e., there is a bridge-connected path between the two 
--> --> ports), then the RBridge will think it has two ports 
--> connected to 
--> --> the same link. Which is OK.
--> --> It won't forward any packets, including not BPDUs, 
--> between those 
--> --> ports.
--> --> At most one of
--> --> its ports will become "designated" for sourcing/sinking 
--> --> unencapsulated traffic to/from that link.
--> --> 
--> --> It would be just like a router having two ports 
--> connected to the 
--> --> same link, which should work with no problem.
--> --> 
--> --> Radia
--> --> 
--> --> 
--> --> 
--> --> Gray, Eric wrote:
--> --> 
--> --> >Radia,
--> --> >
--> --> >	If I am understanding what you are saying 
--> correctly, there are
--> --> some
--> --> >deployment issues with Rbridges into a 802.1 bridged 
--> environment.
--> --> >
--> --> >	The deployment issues arise when individual RBridges are
--> --> installed, if
--> --> >this is not carefully planned in advance.
--> --> >If an Rbridge is installed on a link where it is connected
--> --> to two or
--> --> >more 802.1 bridges and there is another L2 path 
--> between those two 
--> --> >bridges, the RBridge will either have to forward BPDUs 
--> or - like a 
--> --> >router - recognize that multiple ports are connected to
--> --> the same LAN.
--> --> >
--> --> >	Is there an intention that the latter would be 
--> the default case
--> --> until
--> --> >and unless the installed RBridge is able to discover a 
--> connected 
--> --> >RBridge peer?
--> --> >
--> --> >--
--> --> >Eric Gray
--> --> >
--> --> >--> -----Original Message-----
--> --> >--> From: [email-masked] 
--> --> >--> [mailto:[email-masked]]On
--> --> >--> Behalf Of Radia Perlman
--> --> >--> Sent: Tuesday, October 11, 2005 12:44 PM
--> --> >--> To: Developing a hybrid router/bridge.
--> --> >--> Subject: Re: [rbridge] loops in trill networks
--> --> >--> 
--> --> >--> 
--> --> >--> There's nothing an RBridge can do about loops
--> --> consisting of just
--> --> >--> bridges.
--> --> >--> Which is why it's good to partition the spanning trees
--> --> formed by
--> --> >--> the bridges so that the remaining spanning trees are
--> --> as small, and
--> --> >--> therefore as stable, as possible.
--> --> >--> 
--> --> >--> RBridges are like routers. They sit at a layer above
--> --> bridges. The
--> --> >--> bridges form what looks like a single link to the 
--> RBridges. If 
--> --> >--> there are a bunch of bridges connecting a bunch of
--> --> segments, all
--> --> >--> the RBridges attached to that portion of the 
--> network see that 
--> --> >--> bridged segment as a single link.
--> --> >--> 
--> --> >--> Radia
--> --> >--> 
--> --> >--> Loa Andersson wrote:
--> --> >--> 
--> --> >--> >Oh, yes it is true ...
--> --> >--> >
--> --> >--> >but I thought that a trill network could consist of a
--> --> mixed of
--> --> >--> >rbridges and the type of bridges that exist today, if
--> --> that is the
--> --> >--> >case you can possibly form the loop over only non-rbridges
--> --> >--> >
--> --> >--> >but I'm not up to speed on this, there might be a way
--> --> to handle
--> --> >--> >this also
--> --> >--> >
--> --> >--> >/Loa
--> --> >--> >
--> --> >--> >Joe Touch wrote:
--> --> >--> >  
--> --> >--> >
--> --> >--> >>There is, and that's what it's there for.
--> --> >--> >>
--> --> >--> >>Joe
--> --> >--> >>
--> --> >--> >>Mike Hughes wrote:
--> --> >--> >>
--> --> >--> >>    
--> --> >--> >>
--> --> >--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson 
--> <[email-masked]>
--> --> wrote:
--> --> >--> >>>
--> --> >--> >>>
--> --> >--> >>>
--> --> >--> >>>      
--> --> >--> >>>
--> --> >--> >>>>this might be an old discussion, but it is some
--> --> time since it
--> --> >--> >>>>look at it. What do we do in trill networks about
--> --> transient
--> --> >--> >>>>loops, i.e. if use link state protocols there is a
--> --> possibility
--> --> >--> >>>>that we have transient loops. With no TTL mechanisms
--> --> >--> those looping
--> --> >--> >>>>frames could cause quite a bit of problem.
--> --> >--> >>>>        
--> --> >--> >>>>
--> --> >--> >>>Unless I've missed something, or things have changed
--> --> >--> overnight, there is a
--> --> >--> >>>TTL provided in the SHIM header.
--> --> >--> >>>
--> --> >--> >>>Mike
--> --> >--> >>>
--> --> >--> >>>
--> --> >--> 
--> >>>---------------------------------------------------------
--> --> >--> ---------------
--> --> >--> >>>
--> --> >--> >>>_______________________________________________
--> --> >--> >>>rbridge mailing list
--> --> >--> >>>[email-masked]
--> --> >--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> --> >--> >>>      
--> --> >--> >>>
--> --> >--> >
--> --> >--> >
--> --> >--> >  
--> --> >--> >
--> --> >--> 
--> --> >--> _______________________________________________
--> --> >--> rbridge mailing list
--> --> >--> [email-masked]
--> --> >--> http://www.postel.org/mailman/listinfo/rbridge
--> --> >--> 
--> --> >_______________________________________________
--> --> >rbridge mailing list
--> --> >[email-masked]
--> --> >http://www.postel.org/mailman/listinfo/rbridge
--> --> >  
--> --> >
--> --> 
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked]
--> --> http://www.postel.org/mailman/listinfo/rbridge
--> --> _______________________________________________
--> --> rbridge mailing list
--> --> [email-masked]
--> --> http://www.postel.org/mailman/listinfo/rbridge
--> --> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: Bill Sommerfeld <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Date: Wed, 12 Oct 2005 10:46:32 -0400
Subject: Re: [rbridge] seeking input on abstract for problem and	applicability statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1443

I support "can automatically" because the customers will always want
knobs.
(Seems we're arguing about defaults).

> Joe Touch wrote:
> > 'can' implies they might not, which would be bad (consider bridges that
> > refused to participate in spanning tree).

I've run into managed switches which, as best as I can tell, came from
the factory with spanning tree turned off by default.  

Harald wrote:
> My worry is the end-user PC that attaches to an rbridge, calls itself an 
> rbridge, and injects fake mappings for another PC in order to deny service 
> to someone he doesn't like. Or perhaps sniff/modify the traffic ala 
> "dsniff".

Indeed.  And to toss in another wrinkle, I may want my multi-ported
server to appear on the rbridge cloud simultaneously at multiple points
without necessarily being willing to provide "transit" to anything other
than the real or virtual end systems inside my box. 

> I guess you could do the same thing with spanning tree.... the defense is 
> probably to let the bridges distinguish between "core ports" and "user 
> ports" - but then we're out of the "automatic" configuration space again....

Yep.  People who actually manage their networks will want those knobs.

On the other hand, given crypto authentication support in the underlying
routing protocol, the "core" vs "user" distinction might be managed by
what the other device "knows" rather than by which port it's plugged
into.

					- Bill

Date: Wed, 12 Oct 2005 16:17:54 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 617

Joe Touch wrote:
<snip>

do we have any idea on to what level security enters into the
trill work? not at all, or do the rbridges also in this respect
behave as routers?

/Loa

> 
> My understanding is that rbridges are not intended to fix any security
> problems that persist with an equivalent deployment of bridges.
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Date: Wed, 12 Oct 2005 07:02:24 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1851

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE2089271106CDD6CCB7B341D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Harald Tveit Alvestrand wrote:
> 
> --On tirsdag, oktober 11, 2005 23:19:07 -0700 Joe Touch <[email-masked]> 
> wrote:
> 
> 
>>>somehow I get this awful feeling when I see a disruption-sensitive
>>>infrastructure that devices can "automatically" join..... too many IETFs
>>>watching NOC crew hunt down rogue devices of various kinds...
>>>
>>>no objection to "can automatically".....
>>
>>'can' implies they might not, which would be bad (consider bridges that
>>refused to participate in spanning tree).
> 
> My worry is the end-user PC that attaches to an rbridge, calls itself an 
> rbridge, and injects fake mappings for another PC in order to deny service 
> to someone he doesn't like. Or perhaps sniff/modify the traffic ala 
> "dsniff".
> 
> I guess you could do the same thing with spanning tree.... the defense is 
> probably to let the bridges distinguish between "core ports" and "user 
> ports" - but then we're out of the "automatic" configuration space again....

My understanding is that rbridges are not intended to fix any security
problems that persist with an equivalent deployment of bridges.

Somebody let me know if otherwise ;-)

Joe

--------------enigE2089271106CDD6CCB7B341D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigE2089271106CDD6CCB7B341D--

Date: Wed, 12 Oct 2005 11:48:01 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 956

--On tirsdag, oktober 11, 2005 23:19:07 -0700 Joe Touch <[email-masked]> 
wrote:

>> somehow I get this awful feeling when I see a disruption-sensitive
>> infrastructure that devices can "automatically" join..... too many IETFs
>> watching NOC crew hunt down rogue devices of various kinds...
>>
>> no objection to "can automatically".....
>
> 'can' implies they might not, which would be bad (consider bridges that
> refused to participate in spanning tree).

My worry is the end-user PC that attaches to an rbridge, calls itself an 
rbridge, and injects fake mappings for another PC in order to deny service 
to someone he doesn't like. Or perhaps sniff/modify the traffic ala 
"dsniff".

I guess you could do the same thing with spanning tree.... the defense is 
probably to let the bridges distinguish between "core ports" and "user 
ports" - but then we're out of the "automatic" configuration space again....

                   Harald, paranoid.

Date: Tue, 11 Oct 2005 23:19:07 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicability statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1718

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0AC5C4A321491B37DBF5C56A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Harald Tveit Alvestrand wrote:
> 
> --On tirsdag, oktober 11, 2005 17:46:44 -0700 Joe Touch <[email-masked]> 
> wrote:
> 
> 
>>RBridges are layer-2 devices that automatically aggregate into a virtual
>>device that emulates a single bridge on a conventional 802.1 Ethernet.
> 
> 
> question: is the "automatically" part necessary & sufficient?

I thought so, in the same sense that bridges automatically aggregate
into a single spanning tree.

> somehow I get this awful feeling when I see a disruption-sensitive 
> infrastructure that devices can "automatically" join..... too many IETFs 
> watching NOC crew hunt down rogue devices of various kinds...
> 
> no objection to "can automatically".....

'can' implies they might not, which would be bad (consider bridges that
refused to participate in spanning tree).

>>This document describes the need
>>for RBridges and describes situations where it will be useful. 
> 
> nit: singular/plural mismatch (or I parsed the sentence incorrectly)

Nope - thanks for the catch.

Joe

--------------enig0AC5C4A321491B37DBF5C56A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig0AC5C4A321491B37DBF5C56A--

Date: Wed, 12 Oct 2005 07:57:04 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] seeking input on abstract for problem and applicability	statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 716

--On tirsdag, oktober 11, 2005 17:46:44 -0700 Joe Touch <[email-masked]> 
wrote:

>
> RBridges are layer-2 devices that automatically aggregate into a virtual
> device that emulates a single bridge on a conventional 802.1 Ethernet.

question: is the "automatically" part necessary & sufficient?
somehow I get this awful feeling when I see a disruption-sensitive 
infrastructure that devices can "automatically" join..... too many IETFs 
watching NOC crew hunt down rogue devices of various kinds...

no objection to "can automatically".....

> This document describes the need
> for RBridges and describes situations where it will be useful.

nit: singular/plural mismatch (or I parsed the sentence incorrectly)

Date: Tue, 11 Oct 2005 20:04:08 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3980

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCE65287A22FCEBDD3941C49A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Radia Perlman wrote:
...
> But I'm trying to explain a topology in which RBridges *will* do something. That
> is when the topology, if you halted all the RBridges, *is* partitioned. So assume
> you have replaced enough bridges with (for now halted) RBridges, so the world
> is partitioned into 5 pieces.

AOK - I was thinking of this in particular for the applicability part of
the problem/applicability statement.

The catch is that this is going to be less useful if this is required
but cannot be detected or encouraged somehow.

...
> Now let's turn on the RBridges, and let them do their thing.
> 
> Each of the pieces looks to the RBridges like a single link. The 
> RBridges don't see the difference between
> a single Ethernet segment, or a bridged Ethernet segment. Just like 
> routers don't see the bridges.

You've said here and before that the rbridge looks like a router - but
it does not, because routers have ethernet addresses and source and sink
packets.

Routers and hosts are just nodes on a ethernet segment, nodes that have
802 addresses. Now if the rbridge has an 802 address, then we have a big
problem about how to cross the rbridge and come out the right place - we
need to do proxy ARP on all the external links, we need to rewrite the
packets we receive, and we potentially pollute the ARP caches of nodes
on the links that then move elsewhere in the system.

So we need to have some other analogy - e.g., it's a bridge that blocks
BPDUs.

Back to the key question...
...
>>Those links can touch the rbridge in multiple places - there's no reason
>>they necessarily connect to a single port.
> 
> What happens if an RBridge has two ports onto what it sees as the same 
> "link" is that only one of
> the ports winds up Designated. So an RBridge will not decapsulate a 
> packet onto port i and then
> pick it up and encapsulate it on port j, if the RBridge things that port 
> i and port j are the same link,
> which it will, if port i and j are connected through a path of bridges.

OK. I'm understanding the trick -maybe.

Basically, there's effectively a phantom spanning tree inside the
rbridge. You just made one by saying there's exactly one 'designated' port.

So I *can* think of this as one big bridge. One that has internal logic
that makes sure that it touches each spanning tree it sees externally in
one place (isn't that what spanning tree does?) and then ends up acting
like a terminus on each spanning tree (again, what spanning tree does).
So although BPDUs aren't forwarded, the net effect of a spanning tree is
retained.

So maybe (***here's the interesting point, IMO - if I understand this
now***) this also works for bridges.

They don't strictly need to forward BPDUs either (by analogy). All they
need to do is act sufficiently like an rbridge campus and things will
work - and the spanning trees will be partitioned.

Can anyone explain to me why this won't work with a regular bridge if we
built it? And if it did, wouldn't it make the spanning trees a LOT
simpler at the edges?

All we have to do is make sure these 'magic bridges' are deployed in
ways that partition the existing bridges into non-connected stubs -
which we have to figure a way to do with rbridges too.

So does that work? (and if so, has anybody tried it?)

Joe

--------------enigCE65287A22FCEBDD3941C49A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigCE65287A22FCEBDD3941C49A--

Date: Tue, 11 Oct 2005 19:21:31 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4980

Re: Joe's comments about my scenario (first saying that
replacing some bridges with RBridges may not partition the campus, which 
is true but not relevant
to the point I was making, and second saying that RBridges have to join 
in the bridge spanning tree
or else there will be loops, which is not true, and it's important that 
we all understand that).

**********************
There's confusion here. Sorry if I'm not explaining properly.

Let's start over again with the steps I was saying:

You start with one giant bridged campus. There is one spanning tree.

Then you replace some of the bridges with RBridges.

Pretend that the RBridges don't forward ANY packets.

Now the campus is likely partitioned into several pieces, let's say 5, 
with no connectivity
between the pieces.

***********
Perhaps you are quibbling with "likely partitioned". If the
topology is such that the particular bridges you've replaced with RBridges doesn't
partition things, then you will wind up with what looks to the RBridges like they
are all connected to the same link. One port of one will get elected Designated RBridge.
But it won't *do* anything. It won't decapsulate or encapsulate or forward any
data packets. It will just sit there unless there is another "link" in the topology.
But all the RBridges just see a single link. Even if they have multiple ports onto
the same link.

But I'm trying to explain a topology in which RBridges *will* do something. That
is when the topology, if you halted all the RBridges, *is* partitioned. So assume
you have replaced enough bridges with (for now halted) RBridges, so the world
is partitioned into 5 pieces.
**************

Back to the story I was telling. To reiterate, you've either partitioned 
things, or you haven't. If you haven't,
then the RBridges aren't doing anything. The bridges will all compute a 
single spanning tree that connects
all the segments that the RBridges see, so all the RBridges see is the 
simple topology of them all connecting
to a single link, and as I said, they won't be forwarding any data 
packets. The only thing they'll be doing is
transmitting LSPs and Hello messages. But none of them will forward 
anything. That's not a very interesting
topology. Let's get on to what happens in the interesting case.

So now let's assume you have managed to partition the campus. Then let's 
continue with what I was saying:

*************

The bridges in each partition compute their own spanning tree, with their
own Root bridge. The different spanning trees will not see each other, and will not merge (because we've said the RBridges are not forwarding the BPDUs).

Now let's turn on the RBridges, and let them do their thing.

Each of the pieces looks to the RBridges like a single link. The 
RBridges don't see the difference between
a single Ethernet segment, or a bridged Ethernet segment. Just like 
routers don't see the bridges.

So now we can ignore the bridges, and think of a topology consisting of 
5 links, and a bunch of
RBridges connecting the links. Some of the RBridges might have multiple 
ports onto the same link.

Now the RBridges are similar to routers, where they compute optimal 
paths between each other, over those
"links".

Everything works, just as it works to have routers connected in an 
arbitrary topology over an arbitrary
set of links.

***************

I hope I'm making things clearer...

Radia

Now you (Joe) said:

>Those links can touch the rbridge in multiple places - there's no reason
>they necessarily connect to a single port.
>
What happens if an RBridge has two ports onto what it sees as the same 
"link" is that only one of
the ports winds up Designated. So an RBridge will not decapsulate a 
packet onto port i and then
pick it up and encapsulate it on port j, if the RBridge things that port 
i and port j are the same link,
which it will, if port i and j are connected through a path of bridges.

It is most definitely the case that RBridges do not participate in, nor 
do they need to participate in,
the bridge spanning tree protocol. They need to have a forwarding entry 
for the multicast address
on which the BPDUs are sent, to *not forward* packets sent to that 
multicast address.

Radia

> While this is OK for the
>rbridge egress (it picks one designated rbridge on that link to send
>things out), it's entirely possible that a broadcast will end up cycling
>back over that link to another ingress port.
>
>That's why the rbridge needs to be in the spanning tree protocol.
>Otherwise the 'links' outside can loop back onto the rbridge.
>
>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDTD7mE5f5cImnZrsRAp+lAJ91dAP3vrxQDXiaU2gRHC1a+1slQwCg3Ssk
>UPKxoEu4qB+tJlVtDS8ylRo=
>=wc2h
>-----END PGP SIGNATURE-----
>[email-masked]

Date: Tue, 11 Oct 2005 17:46:44 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] seeking input on abstract for problem and applicability statement
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1407

Here's a proposed abstract.

Thoughts appreciated.

Joe

- -----

RBridges are layer-2 devices that automatically aggregate into a virtual
device that emulates a single bridge on a conventional 802.1 Ethernet.

(I had thought that was a concise description, but with recent
discussion about non-participation in some bridge protocols, I'm not
sure. I still think the rbridge MUST participate in order to avoid
loops, but if that's contentious it can't be part of the abstract yet...)

They combine layer 2?s ability to allow hosts to reattach without
renumbering with layer 3?s routing benefits. RBridges use existing link
state routing to provide higher internal cross-section bandwidth, faster
convergence under reconfiguration, and more robustness to link
interruption than an equivalent set of conventional bridges using
existing spanning tree forwarding. They are intended to apply to similar
L2 network sizes as conventional bridges and are intended to be backward
compatible with those bridges as well. This document describes the need
for RBridges and describes situations where it will be useful.

Date: Tue, 11 Oct 2005 17:10:23 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 687

>> As for providing glue to two broadcast domains in order to merge 
>> them...yes, an RBridged "campus"
>> could be used to tunnel packets from the two broadcast domains in order 
>> to merge them.

    Yes, agree.

>> But in general an RBridge would not forward a native BPDU. It would 
>> recognize it as something
>> it shouldn't forward. Because RBridges intend to make the spanning trees 

    So we have to put special checks in the hardware forwarding plane? I
    would rather not put this in the architecture and just document that
    bridges should not send BPDUs on links where rBridges exist. Just like
    bridges don't generally send BPDUs on host ports today.

Dino

Content-class: urn:content-classes:message
Date: Tue, 11 Oct 2005 16:41:44 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7884

Eric,

Notice that in my example below, I am only talking about broadcast
connectivity - not unicast.  There is not MAC advertisements for
broadcast.  A broadcast must go to every edge port.  In this case, a
spanning tree must exist (across both the RBridge and 802.1d bridged
network) or a broadcast loop will occur.

 - Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gray, Eric
Sent: Tuesday, October 11, 2005 3:45 PM
To: 'Developing a hybrid router/bridge.'
Subject: Re: [rbridge] loops in trill networks

Larry,

	You have to think of bridges and RBridges as existing at two
layers.  How frames are forwarded between RBridges will be determined by
shortest path computation based on MAC advertisements in IS-IS.  How
frames are forwarded across
802.1 bridges between RBridges is based on STP.

--
E

--> -----Original Message-----
--> From: [email-masked]
--> [mailto:[email-masked]]On
--> Behalf Of Larry Kreeger (kreeger)
--> Sent: Tuesday, October 11, 2005 5:08 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> Radia,
--> 
--> How about the case where the two ports connected to the same bridged

--> domain are on different RBridges?
--> 
--> Consider, the following topology where A,B,C are hosts.
--> 
--> A--RB1--Bridged-Domain--RB2--B
-->               |
-->               |
-->              RB3--C
--> 
--> In this case, would all RB's forward a L2 broadcast to their 
--> respective edge ports?  I was assuming, yes.  If so, then RB1,RB2 
--> and
--> RB3 are all
--> designated RBs in order to have broadcast connectivity between 
--> A,B,C.
--> 
--> Now a new RB4 is added to the topology which connects RB1 and RB3,
--> 
--> A--RB1--Bridged-Domain--RB2--B
-->     |         |
-->     |         |
--> D--RB4-------RB3--C
--> 
--> Are you saying that RB1 and RB3 detect that they now have new 
--> connectivity and battle to be a Designated RB to serve their side of

--> the network?  Assuming RB3 wins, all broadcasts must enter and leave

--> the Bridged-Domain via RB3 to get between hosts A,C,D and B.
--> RB2 must still
--> be the Designated RB for traffic to reach B.
--> 
--> I didn't think routers needed to deal with this since they don't 
--> forward broadcasts.  Are you saying that routing protocols already 
--> deal with these types of scenarios?
--> 
--> Thanks, Larry
--> 
--> -----Original Message-----
--> From: [email-masked]
--> [mailto:[email-masked]] On Behalf Of Radia Perlman
--> Sent: Tuesday, October 11, 2005 12:46 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> The intention is that deployment not have to be careful. If two of 
--> an RBridge's ports are connected to the same bridged broadcast 
--> domain (i.e., there is a bridge-connected path between the two 
--> ports), then the RBridge will think it has two ports connected to 
--> the same link. Which is OK.
--> It won't forward any packets, including not BPDUs, between those 
--> ports.
--> At most one of
--> its ports will become "designated" for sourcing/sinking 
--> unencapsulated traffic to/from that link.
--> 
--> It would be just like a router having two ports connected to the 
--> same link, which should work with no problem.
--> 
--> Radia
--> 
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >Radia,
--> >
--> >	If I am understanding what you are saying correctly, there are
--> some
--> >deployment issues with Rbridges into a 802.1 bridged environment.
--> >
--> >	The deployment issues arise when individual RBridges are
--> installed, if
--> >this is not carefully planned in advance.
--> >If an Rbridge is installed on a link where it is connected
--> to two or
--> >more 802.1 bridges and there is another L2 path between those two 
--> >bridges, the RBridge will either have to forward BPDUs or - like a 
--> >router - recognize that multiple ports are connected to
--> the same LAN.
--> >
--> >	Is there an intention that the latter would be the default case
--> until
--> >and unless the installed RBridge is able to discover a connected 
--> >RBridge peer?
--> >
--> >--
--> >Eric Gray
--> >
--> >--> -----Original Message-----
--> >--> From: [email-masked] 
--> >--> [mailto:[email-masked]]On
--> >--> Behalf Of Radia Perlman
--> >--> Sent: Tuesday, October 11, 2005 12:44 PM
--> >--> To: Developing a hybrid router/bridge.
--> >--> Subject: Re: [rbridge] loops in trill networks
--> >--> 
--> >--> 
--> >--> There's nothing an RBridge can do about loops
--> consisting of just
--> >--> bridges.
--> >--> Which is why it's good to partition the spanning trees
--> formed by
--> >--> the bridges so that the remaining spanning trees are
--> as small, and
--> >--> therefore as stable, as possible.
--> >--> 
--> >--> RBridges are like routers. They sit at a layer above
--> bridges. The
--> >--> bridges form what looks like a single link to the RBridges. If 
--> >--> there are a bunch of bridges connecting a bunch of
--> segments, all
--> >--> the RBridges attached to that portion of the network see that 
--> >--> bridged segment as a single link.
--> >--> 
--> >--> Radia
--> >--> 
--> >--> Loa Andersson wrote:
--> >--> 
--> >--> >Oh, yes it is true ...
--> >--> >
--> >--> >but I thought that a trill network could consist of a
--> mixed of
--> >--> >rbridges and the type of bridges that exist today, if
--> that is the
--> >--> >case you can possibly form the loop over only non-rbridges
--> >--> >
--> >--> >but I'm not up to speed on this, there might be a way
--> to handle
--> >--> >this also
--> >--> >
--> >--> >/Loa
--> >--> >
--> >--> >Joe Touch wrote:
--> >--> >  
--> >--> >
--> >--> >>There is, and that's what it's there for.
--> >--> >>
--> >--> >>Joe
--> >--> >>
--> >--> >>Mike Hughes wrote:
--> >--> >>
--> >--> >>    
--> >--> >>
--> >--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]>
--> wrote:
--> >--> >>>
--> >--> >>>
--> >--> >>>
--> >--> >>>      
--> >--> >>>
--> >--> >>>>this might be an old discussion, but it is some
--> time since it
--> >--> >>>>look at it. What do we do in trill networks about
--> transient
--> >--> >>>>loops, i.e. if use link state protocols there is a
--> possibility
--> >--> >>>>that we have transient loops. With no TTL mechanisms
--> >--> those looping
--> >--> >>>>frames could cause quite a bit of problem.
--> >--> >>>>        
--> >--> >>>>
--> >--> >>>Unless I've missed something, or things have changed
--> >--> overnight, there is a
--> >--> >>>TTL provided in the SHIM header.
--> >--> >>>
--> >--> >>>Mike
--> >--> >>>
--> >--> >>>
--> >--> >>>---------------------------------------------------------
--> >--> ---------------
--> >--> >>>
--> >--> >>>_______________________________________________
--> >--> >>>rbridge mailing list
--> >--> >>>[email-masked]
--> >--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >--> >>>      
--> >--> >>>
--> >--> >
--> >--> >
--> >--> >  
--> >--> >
--> >--> 
--> >--> _______________________________________________
--> >--> rbridge mailing list
--> >--> [email-masked]
--> >--> http://www.postel.org/mailman/listinfo/rbridge
--> >--> 
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 
_______________________________________________
rbridge mailing list
[email-masked]
http://www.postel.org/mailman/listinfo/rbridge

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 11 Oct 2005 19:44:35 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 7232

Larry,

	You have to think of bridges and RBridges as existing
at two layers.  How frames are forwarded between RBridges
will be determined by shortest path computation based on MAC
advertisements in IS-IS.  How frames are forwarded across 
802.1 bridges between RBridges is based on STP.

--
E

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Larry Kreeger (kreeger)
--> Sent: Tuesday, October 11, 2005 5:08 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> Radia,
--> 
--> How about the case where the two ports connected to the same bridged
--> domain are on different RBridges?
--> 
--> Consider, the following topology where A,B,C are hosts.
--> 
--> A--RB1--Bridged-Domain--RB2--B
-->               |
-->               |
-->              RB3--C
--> 
--> In this case, would all RB's forward a L2 broadcast to 
--> their respective
--> edge ports?  I was assuming, yes.  If so, then RB1,RB2 and 
--> RB3 are all
--> designated RBs in order to have broadcast connectivity 
--> between A,B,C.
--> 
--> Now a new RB4 is added to the topology which connects RB1 and RB3,
--> 
--> A--RB1--Bridged-Domain--RB2--B
-->     |         |
-->     |         |
--> D--RB4-------RB3--C
--> 
--> Are you saying that RB1 and RB3 detect that they now have new
--> connectivity and battle to be a Designated RB to serve 
--> their side of the
--> network?  Assuming RB3 wins, all broadcasts must enter and leave the
--> Bridged-Domain via RB3 to get between hosts A,C,D and B.  
--> RB2 must still
--> be the Designated RB for traffic to reach B.
--> 
--> I didn't think routers needed to deal with this since they 
--> don't forward
--> broadcasts.  Are you saying that routing protocols already deal with
--> these types of scenarios?
--> 
--> Thanks, Larry 
--> 
--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On
--> Behalf Of Radia Perlman
--> Sent: Tuesday, October 11, 2005 12:46 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> The intention is that deployment not have to be careful. If 
--> two of an
--> RBridge's ports are connected to the same bridged broadcast domain
--> (i.e., there is a bridge-connected path between the two 
--> ports), then the
--> RBridge will think it has two ports connected to the same 
--> link. Which is
--> OK.
--> It won't forward any packets, including not BPDUs, between 
--> those ports. 
--> At most one of
--> its ports will become "designated" for sourcing/sinking 
--> unencapsulated
--> traffic to/from that link.
--> 
--> It would be just like a router having two ports connected 
--> to the same
--> link, which should work with no problem.
--> 
--> Radia
--> 
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >Radia,
--> >
--> >	If I am understanding what you are saying correctly, there are
--> some 
--> >deployment issues with Rbridges into a 802.1 bridged environment.
--> >
--> >	The deployment issues arise when individual RBridges are
--> installed, if 
--> >this is not carefully planned in advance.
--> >If an Rbridge is installed on a link where it is connected 
--> to two or 
--> >more 802.1 bridges and there is another L2 path between those two 
--> >bridges, the RBridge will either have to forward BPDUs or - like a 
--> >router - recognize that multiple ports are connected to 
--> the same LAN.
--> >
--> >	Is there an intention that the latter would be the default case
--> until 
--> >and unless the installed RBridge is able to discover a connected 
--> >RBridge peer?
--> >
--> >--
--> >Eric Gray
--> >
--> >--> -----Original Message-----
--> >--> From: [email-masked]
--> >--> [mailto:[email-masked]]On
--> >--> Behalf Of Radia Perlman
--> >--> Sent: Tuesday, October 11, 2005 12:44 PM
--> >--> To: Developing a hybrid router/bridge.
--> >--> Subject: Re: [rbridge] loops in trill networks
--> >--> 
--> >--> 
--> >--> There's nothing an RBridge can do about loops 
--> consisting of just 
--> >--> bridges.
--> >--> Which is why it's good to partition the spanning trees 
--> formed by 
--> >--> the bridges so that the remaining spanning trees are 
--> as small, and 
--> >--> therefore as stable, as possible.
--> >--> 
--> >--> RBridges are like routers. They sit at a layer above 
--> bridges. The 
--> >--> bridges form what looks like a single link to the RBridges. If 
--> >--> there are a bunch of bridges connecting a bunch of 
--> segments, all 
--> >--> the RBridges attached to that portion of the network see that 
--> >--> bridged segment as a single link.
--> >--> 
--> >--> Radia
--> >--> 
--> >--> Loa Andersson wrote:
--> >--> 
--> >--> >Oh, yes it is true ...
--> >--> >
--> >--> >but I thought that a trill network could consist of a 
--> mixed of 
--> >--> >rbridges and the type of bridges that exist today, if 
--> that is the 
--> >--> >case you can possibly form the loop over only non-rbridges
--> >--> >
--> >--> >but I'm not up to speed on this, there might be a way 
--> to handle 
--> >--> >this also
--> >--> >
--> >--> >/Loa
--> >--> >
--> >--> >Joe Touch wrote:
--> >--> >  
--> >--> >
--> >--> >>There is, and that's what it's there for.
--> >--> >>
--> >--> >>Joe
--> >--> >>
--> >--> >>Mike Hughes wrote:
--> >--> >>
--> >--> >>    
--> >--> >>
--> >--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]>
--> wrote:
--> >--> >>>
--> >--> >>>
--> >--> >>>
--> >--> >>>      
--> >--> >>>
--> >--> >>>>this might be an old discussion, but it is some 
--> time since it 
--> >--> >>>>look at it. What do we do in trill networks about 
--> transient 
--> >--> >>>>loops, i.e. if use link state protocols there is a 
--> possibility 
--> >--> >>>>that we have transient loops. With no TTL mechanisms
--> >--> those looping
--> >--> >>>>frames could cause quite a bit of problem.
--> >--> >>>>        
--> >--> >>>>
--> >--> >>>Unless I've missed something, or things have changed
--> >--> overnight, there is a
--> >--> >>>TTL provided in the SHIM header.
--> >--> >>>
--> >--> >>>Mike
--> >--> >>>
--> >--> >>>
--> >--> >>>---------------------------------------------------------
--> >--> ---------------
--> >--> >>>
--> >--> >>>_______________________________________________
--> >--> >>>rbridge mailing list
--> >--> >>>[email-masked]
--> >--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >--> >>>      
--> >--> >>>
--> >--> >
--> >--> >
--> >--> >  
--> >--> >
--> >--> 
--> >--> _______________________________________________
--> >--> rbridge mailing list
--> >--> [email-masked]
--> >--> http://www.postel.org/mailman/listinfo/rbridge
--> >--> 
--> >_______________________________________________
--> >rbridge mailing list
--> >[email-masked]
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Tue, 11 Oct 2005 15:38:30 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1969

Radia Perlman wrote:
> Let me try explaining it a different way.
> 
> You start with one giant bridged campus. There is one spanning tree.
> 
> Then you replace some of the bridges with RBridges.
> 
> Pretend that the RBridges don't forward ANY packets.
> 
> Now the campus is likely partitioned into several pieces, let's say 5, 
> with no connectivity
> between the pieces.

That's not necessarily likely. That would only occur if the network were
wired as a spanning tree; if we could expect that, we wouldn't need to
generate one.

I.e., it's more likely that such partitioning might not occur - however,
the rbridge system might not provide a benefit in those cases. AFAICT,
an rbridge helps only where it does partition the bridges as above.

Let's thus assume that's the case, as engineered:

> Each piece computes its own spanning tree, with its own Root bridge. So you
> have 5 independent, disconnected spanning trees.
> 
> Now think of each of those 5 pieces as a single link. The fact that each 
> piece
> is glued together with spanning tree with bridges is invisible outside 
> that piece. So we
> can stop thinking about bridges, and now only look at the next layer 
> up...the RBridges.

Those links can touch the rbridge in multiple places - there's no reason
they necessarily connect to a single port. While this is OK for the
rbridge egress (it picks one designated rbridge on that link to send
things out), it's entirely possible that a broadcast will end up cycling
back over that link to another ingress port.

That's why the rbridge needs to be in the spanning tree protocol.
Otherwise the 'links' outside can loop back onto the rbridge.

Joe

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 11 Oct 2005 19:36:58 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2130

I think what Radia is saying is that RBridges do not 
participate (originate or forward) BPDUs.  In addition,
an RBridge that determines it has more than one port in
the same LAN/Broadcast domain does not forward between
those ports.  It does not need to directly participate
in STP to know this and this behavior will prevent loop
behavior.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Joe Touch
--> Sent: Tuesday, October 11, 2005 5:02 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Gray, Eric wrote:
--> > Larry,
--> > 
--> > 	You've got the sense of Radia's reply reversed.  It's the
--> > 802.1 bridges that look like a single link to the RBridges.
--> > 
--> > 	This is pretty much how I expected this to work.  A cloud
--> > of 802.1 bridges MUST be completely enclosed in either RBridges
--> > or routers. 
--> 
--> I was expecting that to say "or there will be little or no 
--> benefit from
--> the rbridges" - i.e., topology restrictions can't be 
--> enforced per se if
--> we're expecting plug-and-play.
--> 
--> > Rbridges - like routers - do not forward BPDUs.
--> 
--> Let me propose a question. Let's say an rbridge campus looks like a
--> single giant bridge (humor me).
--> 
--> There are two cases:
--> 
--> 	- the bridge participates in BPDU
--> 
--> 	- the bridge does not participate in BPDU
--> 
--> Is it possible in existing systems to have a bridge that does not
--> participate in BPDU? Wouldn't this end up creating loops?
--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDTChhE5f5cImnZrsRAkAqAKCrkBhoqAYQsRB1/W1OlhWtuOlg0QCgyfj7
--> +kCndWeVdgjyigTPYUF4U3Y=
--> =wt7Z
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 11 Oct 2005 19:23:29 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3378

Larry,

	During a bridge-level topology change, bridges only 
deal with BPDUs.  Other traffic is held up until the ST is
determined.  Otherwise, traffic in a bridged network would
be out of control and stay out of control.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Larry Kreeger (kreeger)
--> Sent: Tuesday, October 11, 2005 4:45 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> Joe,
--> 
--> The context was that during a topology change, there could be a
--> temporary loop.  While this temporary loop exists, 
--> multicast/broadcasts
--> would duplicate to edge ports each time they came around - 
--> until the TTL
--> reaches its limit.
--> 
-->  - Larry
--> 
--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On
--> Behalf Of Joe Touch
--> Sent: Tuesday, October 11, 2005 1:02 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Larry Kreeger (kreeger) wrote:
--> > OK, I can see how a TTL will stop loops, and would 
--> prevent duplicate 
--> > known unicasts from being delivered, but how does a TTL stop 
--> > broadcast/multicast/unknown unicast frames from being 
--> duplicated to 
--> > edge ports each time the frame comes round the loop?
--> 
--> The multicast/broadcast packets are forwarded by one or 
--> more spanning
--> trees. There should never be loops in those anyway as a result.
--> 
--> Joe
--> 
--> > Or is this considered
--> > OK behavior in an RBridge network compared to an 802.1 bridged
--> network?
--> > 
--> > New to all this...  - Larry
--> > 
--> > -----Original Message-----
--> > From: [email-masked] 
[mailto:[email-masked]] 
> On Behalf Of Joe Touch
> Sent: Tuesday, October 11, 2005 7:07 AM
> Subject: Re: [rbridge] loops in trill networks
> 
> There is, and that's what it's there for.
> 
> Joe
> 
> Mike Hughes wrote:
> 
>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>
>>
>>
>>>this might be an old discussion, but it is some time since it look at

>>>it. What do we do in trill networks about transient loops, i.e. if 
>>>use
> 
> 
>>>link state protocols there is a possibility that we have transient 
>>>loops. With no TTL mechanisms those looping frames could cause quite 
>>>a
> 
> 
>>>bit of problem.
>>
>>
>>Unless I've missed something, or things have changed overnight, there 
>>is a TTL provided in the SHIM header.
>>
>>Mike
> 
> [email-masked]
[email-masked]
[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 11 Oct 2005 15:21:48 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2986

Radia,

I agree that loops happen within 802.1d bridged networks due to
circumstances such as misconfiguration, HW bugs, SW bugs etc, and that
these tend to cause the network to melt down.  This is why a TTL is a
good thing, and I have no objection to it.

However, I'd like to separate out meltdown behavior (which is driven by
events which happen less often), and temporary loops which can be caused
by much more commonplace events (link up/down).

In the case of simple link up/down events, 802.1d networks don't
duplicate unicast frames.  If we are calculating the RBridge
bcast/mcast/unknown spanning tree using IS-IS, then unknown unicasts
will get duplicated in some topologies.  If this is deemed acceptable
behavior for an RBridge network, it should be documented as a known
behavior.  If this causes problems for some protocols, users will be
able to choose to either fix the protocol or not use RBridges.  If it is
not deemed acceptable behavior, then it should be fixed.

I'm just trying to point out what I see as difference between the two
technologies as defined.

 - Larry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Tuesday, October 11, 2005 2:48 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

There was never a "guarantee" in STP that there not be loops. STP
attempted to avoid them by waiting before turning ports on. RSTP,
instead of waiting before turning on ports, attempts to avoid loops by
using local information to turn some links on while turning others off.

Although it's certainly good to try to avoid temporary loops, it's never
possible to *guarantee* no temporary loops. These can be caused by
misconfiguration (someone claiming a port will only have endnodes,
whereas it actually does get connected to a switch), by bringing up a
repeater, or having enough consecutive BPDUs lost for whatever reason
(congestion on the link causing packets to not reach a bridge, or the
bridge not being able to keep up with worst case wire speed).

The thing that got me interested in this again is finding out that
bridge meltdowns (due to temporary loops) do occur, and apparently with
increasing frequency with new features that have been added to bridges
that involve configuration that can be disastrous if set incorrectly, or
with bridges deployed that can't keep up with wire speeds.

So the idea is that although it's certainly good to try to avoid
temporary loops, we want to make it not a disaster if they do occur.

Radia

Larry Kreeger (kreeger) wrote:

>Joe,
>
>As far as I know, all variations of STP guaranteed that bridged 
>networks never have temporary loops, so existing bridges never have
this problem.
>If they did, then I'd agree that it is no different. 
>
> - Larry
>
>
>  
>

[email-masked]

Date: Tue, 11 Oct 2005 15:18:33 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] rbridge Digest, Vol 17, Issue 5
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3997

Actually, Stephen,
you are right. The possibility you mention was also considered, and I left
it off that list below. If I remember correctly, I think people didn't 
like it
because it made the shim header larger on every packet, and it required
learning while forwarding data packets. The arguments for it, though,
are that inactive endnodes don't occupy space, and there's no explicit
protocol necessary for learning endnode information.

Perhaps there wasn't consensus on dropping that possibility.

It would be good to restart a thread (with a subject line more 
descriptive than
"rbridge Digest, Vol 17, Issue 5" probably),
specifically just on this one issue...possibilities for
learning endnode information, that has at least the three choices I put 
in below, plus the
one Stephen added, which is to have both ingress and egress RBridges in 
the shim header,
and have either all RBridges that forward the encapsulated packet, or 
just the egress
RBridge, learn the mapping of (ingress RBridge, source MAC) for that 
packet.

Radia

*******************

Stephen Suryaputra wrote:

On 10/11/05, *Radia Perlman* <[email-masked] 
<mailto:[email-masked]>> wrote:

    So...how should VLAN A endnode membership be passed around? There are
    various choices:
    a) in one instance of IS-IS, along with the RBridge topology
    information
    b) have an instance of IS-IS per VLAN, just for passing around the
    endnode information for that VLAN.
    This would be a fairly trivial subset of IS-IS, because there is no
    forwarding of link state information.
    The VLAN A instance of IS-IS would use the VLAN A broadcast domain
    created by the main
    IS-IS instance, to have each RBridge in VLAN A announce its directly
    attached VLAN A endnodes
    c) have some other protocol, simpler than IS-IS (because link state
    information never needs to be forwarded),
    that just sends out endnode information.

This may have been discussed before. Since the first packet will go 
through the spanning tree due to multicast/broadcast/unknown, why not 
the shim header contain both ingress and egress Rbridge and let the 
egress Rbridge learn the original L2 source address to ingress Rbridge 
mapping (the same as bridge learning today with aging timer)? Rbridges 
on the path that are connected to the same VLAN can use the same 
information.

Stephen.

Stephen Suryaputra wrote:

>
>
> On 10/11/05, *Radia Perlman* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     So...how should VLAN A endnode membership be passed around? There are
>     various choices:
>     a) in one instance of IS-IS, along with the RBridge topology
>     information
>     b) have an instance of IS-IS per VLAN, just for passing around the
>     endnode information for that VLAN.
>     This would be a fairly trivial subset of IS-IS, because there is no
>     forwarding of link state information.
>     The VLAN A instance of IS-IS would use the VLAN A broadcast domain
>     created by the main
>     IS-IS instance, to have each RBridge in VLAN A announce its directly
>     attached VLAN A endnodes
>     c) have some other protocol, simpler than IS-IS (because link state
>     information never needs to be forwarded),
>     that just sends out endnode information.
>
>
> This may have been discussed before. Since the first packet will go 
> through the spanning tree due to multicast/broadcast/unknown, why not 
> the shim header contain both ingress and egress Rbridge and let the 
> egress Rbridge learn the original L2 source address to ingress Rbridge 
> mapping (the same as bridge learning today with aging timer)? Rbridges 
> on the path that are connected to the same VLAN can use the same 
> information.
>
> Stephen.
>
>------------------------------------------------------------------------
>
>[email-masked]

Date: Tue, 11 Oct 2005 15:05:35 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5700

No. When Joe said "STP" he didn't mean the good old 802.1d STP that we 
all know and love...
instead it's a spanning tree topology calcuated from the link state 
database distributed by IS-IS.

Radia

Larry Kreeger (kreeger) wrote:

>Joe,
>
>Sorry, but I totally missed the fact that Spanning Tree Protocol is
>being used within the RBridged network!  All I had seen were references
>to routing protocols such as IS-IS.
>
>Nevermind...
>
> - Larry
>
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Joe Touch
>Sent: Tuesday, October 11, 2005 2:22 PM
>Subject: Re: [rbridge] loops in trill networks
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Larry Kreeger (kreeger) wrote:
>  
>
>>Joe,
>>
>>As far as I know, all variations of STP guaranteed that bridged 
>>networks never have temporary loops, so existing bridges never have
>>    
>>
>this problem.
>  
>
>>If they did, then I'd agree that it is no different. 
>>    
>>
>
>I'm confused. We are using STP for multicast/broadcast inside the
>campus. Why then will that STP cause loops whereas current bridges do
>not?
>
>Joe
>
>
>  
>
>> - Larry
>>
>>From: [email-masked] [mailto:[email-masked]] 
>>On Behalf Of Joe Touch
>>Sent: Tuesday, October 11, 2005 1:47 PM
>>Subject: Re: [rbridge] loops in trill networks
>>
>>Yes - but I think Radia pointed out that this is no different than how
>>    
>>
>
>  
>
>>existing bridges would behave in that circumstance.
>>
>>joe
>>
>>
>>Larry Kreeger (kreeger) wrote:
>>
>>    
>>
>>>>Joe,
>>>>
>>>>The context was that during a topology change, there could be a 
>>>>temporary loop.  While this temporary loop exists, 
>>>>multicast/broadcasts would duplicate to edge ports each time they 
>>>>came
>>>>        
>>>>
>>    
>>
>>>>around - until the TTL reaches its limit.
>>>>
>>>>- Larry
>>>>
>>>>From: [email-masked] [mailto:[email-masked]]
>>>>On Behalf Of Joe Touch
>>>>Sent: Tuesday, October 11, 2005 1:02 PM
>>>>Subject: Re: [rbridge] loops in trill networks
>>>>
>>>>
>>>>
>>>>Larry Kreeger (kreeger) wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>>OK, I can see how a TTL will stop loops, and would prevent 
>>>>>>duplicate known unicasts from being delivered, but how does a TTL 
>>>>>>stop broadcast/multicast/unknown unicast frames from being 
>>>>>>duplicated to edge ports each time the frame comes round the loop?
>>>>>>            
>>>>>>
>>>>The multicast/broadcast packets are forwarded by one or more spanning
>>>>        
>>>>
>
>  
>
>>>>trees. There should never be loops in those anyway as a result.
>>>>
>>>>Joe
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>>Or is this considered
>>>>>>OK behavior in an RBridge network compared to an 802.1 bridged
>>>>>>            
>>>>>>
>>>>network?
>>>>
>>>>
>>>>        
>>>>
>>>>>>New to all this...  - Larry
>>>>>>
>>>>>>From: [email-masked] 
>>>>>>[mailto:[email-masked]]
>>>>>>On Behalf Of Joe Touch
>>>>>>Sent: Tuesday, October 11, 2005 7:07 AM
>>>>>>Subject: Re: [rbridge] loops in trill networks
>>>>>>
>>>>>>There is, and that's what it's there for.
>>>>>>
>>>>>>Joe
>>>>>>
>>>>>>Mike Hughes wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>this might be an old discussion, but it is some time since it 
>>>>>>>>look at
>>>>>>>>                
>>>>>>>>
>>>>        
>>>>
>>>>>>>>it. What do we do in trill networks about transient loops, i.e. 
>>>>>>>>if use
>>>>>>>>                
>>>>>>>>
>>>>>>            
>>>>>>
>>>>>>>>link state protocols there is a possibility that we have 
>>>>>>>>transient loops. With no TTL mechanisms those looping frames 
>>>>>>>>could cause quite a
>>>>>>>>                
>>>>>>>>
>>>>>>            
>>>>>>
>>>>>>>>bit of problem.
>>>>>>>>                
>>>>>>>>
>>>>>>>Unless I've missed something, or things have changed overnight, 
>>>>>>>there is a TTL provided in the SHIM header.
>>>>>>>
>>>>>>>Mike
>>>>>>>              
>>>>>>>
>>>>>>[email-masked]
>>[email-masked]
>>[email-masked]
>[email-masked]
>[email-masked]
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDTCz4E5f5cImnZrsRAupAAJ9uc9RO2M6nGvzxGY5UqzjYn0OafACgimKq
>R8mFDeQMzN6IdleEU574J4c=
>=F6gF
>-----END PGP SIGNATURE-----
>[email-masked]
>[email-masked]

Date: Tue, 11 Oct 2005 14:57:11 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2520

Let me try explaining it a different way.

You start with one giant bridged campus. There is one spanning tree.

Then you replace some of the bridges with RBridges.

Pretend that the RBridges don't forward ANY packets.

Now the campus is likely partitioned into several pieces, let's say 5, 
with no connectivity
between the pieces.

Each piece computes its own spanning tree, with its own Root bridge. So you
have 5 independent, disconnected spanning trees.

Now think of each of those 5 pieces as a single link. The fact that each 
piece
is glued together with spanning tree with bridges is invisible outside 
that piece. So we
can stop thinking about bridges, and now only look at the next layer 
up...the RBridges.

Now we have a topology of 5 links all interconnected in some rich 
topology (not necessarily
a tree) using RBridges.

The RBridges run a link state IGP. They know how to reach each other via 
shortest paths.
They might even compute multiple paths to each other. Data packets can 
use all the links,
so the actual topology for data packet forwarding need not be loop-free. 
Just like
routing IP packets over the same topology, if you replaced the RBridges 
with IP routers
and gave each of the 5 segments its own IP subnet prefix.

Using the link state database, the RBridges also calculate a spanning 
tree among themselves, in
order to forward multicasts/pkts to unknown destinations.

This spanning tree, when forwarded from RBridge to RBridge, might 
transit a bridged segment
with its own spanning tree. But it's a different tree.

Somehow...I'm not sure this will illuminate anything.

However, 5 minutes with interactive conversation and a whiteboard and 
I'm sure if there were
any remaining confusion it could be resolved.

Radia

Saikat Ray wrote:

>>What I mean by "n spanning trees that do not see each other" is that the 
>>RBridges don't glue the
>>802.1d spanning tree together into a single 802.1d spanning
>>tree with one Root Bridge, etc.
>>
>>They do, however, create a single broadcast domain, and ARPs go across
>>the RBridges. So indeed an ARP is carried over a spanning tree, but it's 
>>not THE spanning tree
>>calculated by the 802.1d spanning tree algorithm.
>>    
>>
>
>Won't that create possible loops?
>
>Joe
>
>[Saikat] RBridges would broadcast over a spanning tree (of the graph
>consisting of the RBridges), isn't it?
>
>[email-masked]

Date: Tue, 11 Oct 2005 17:53:03 -0400
From: Stephen Suryaputra <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] rbridge Digest, Vol 17, Issue 5
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3167

------=_Part_5220_26165615.1129067583611
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/11/05, Radia Perlman <[email-masked]> wrote:
>
>
> So...how should VLAN A endnode membership be passed around? There are
> various choices:
> a) in one instance of IS-IS, along with the RBridge topology information
> b) have an instance of IS-IS per VLAN, just for passing around the
> endnode information for that VLAN.
> This would be a fairly trivial subset of IS-IS, because there is no
> forwarding of link state information.
> The VLAN A instance of IS-IS would use the VLAN A broadcast domain
> created by the main
> IS-IS instance, to have each RBridge in VLAN A announce its directly
> attached VLAN A endnodes
> c) have some other protocol, simpler than IS-IS (because link state
> information never needs to be forwarded),
> that just sends out endnode information.

This may have been discussed before. Since the first packet will go through
the spanning tree due to multicast/broadcast/unknown, why not the shim
header contain both ingress and egress Rbridge and let the egress Rbridge
learn the original L2 source address to ingress Rbridge mapping (the same a=
s
bridge learning today with aging timer)? Rbridges on the path that are
connected to the same VLAN can use the same information.

Stephen.

------=_Part_5220_26165615.1129067583611
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div><span class=3D"gmail_quote">On 10/11/05, <b class=3D"gmail_sen=
dername">Radia Perlman</b> &lt;<a href=3D"mailto:[email-masked]">Rad=
[email-masked]</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" s=
tyle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8e=
x; padding-left: 1ex;">
<br>So...how should VLAN A endnode membership be passed around? There are<b=
r>various choices:<br>a) in one instance of IS-IS, along with the RBridge t=
opology information<br>b) have an instance of IS-IS per VLAN, just for pass=
ing around the
<br>endnode information for that VLAN.<br>This would be a fairly trivial su=
bset of IS-IS, because there is no<br>forwarding of link state information.=
<br>The VLAN A instance of IS-IS would use the VLAN A broadcast domain<br>
created by the main<br>IS-IS instance, to have each RBridge in VLAN A annou=
nce its directly<br>attached VLAN A endnodes<br>c) have some other protocol=
, simpler than IS-IS (because link state<br>information never needs to be f=
orwarded),
<br>that just sends out endnode information.</blockquote><div><br>
This may have been discussed before. Since the first packet will go
through the spanning tree due to multicast/broadcast/unknown, why not
the shim header contain both ingress and egress Rbridge and let the
egress Rbridge learn the original L2 source address to ingress Rbridge
mapping (the same as bridge learning today with aging timer)? Rbridges
on the path that are connected to the same VLAN can use the same
information.<br>
</div><br></div>Stephen.<br>

------=_Part_5220_26165615.1129067583611--

Content-class: urn:content-classes:message
Date: Tue, 11 Oct 2005 14:47:42 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4715

Joe,

Sorry, but I totally missed the fact that Spanning Tree Protocol is
being used within the RBridged network!  All I had seen were references
to routing protocols such as IS-IS.

Nevermind...

 - Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Touch
Sent: Tuesday, October 11, 2005 2:22 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

Larry Kreeger (kreeger) wrote:
> Joe,
> 
> As far as I know, all variations of STP guaranteed that bridged 
> networks never have temporary loops, so existing bridges never have
this problem.
> If they did, then I'd agree that it is no different. 

I'm confused. We are using STP for multicast/broadcast inside the
campus. Why then will that STP cause loops whereas current bridges do
not?

Joe

>  - Larry
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Joe Touch
> Sent: Tuesday, October 11, 2005 1:47 PM
> Subject: Re: [rbridge] loops in trill networks
> 
> Yes - but I think Radia pointed out that this is no different than how

> existing bridges would behave in that circumstance.
> 
> joe
> 
> 
> Larry Kreeger (kreeger) wrote:
> 
>>>Joe,
>>>
>>>The context was that during a topology change, there could be a 
>>>temporary loop.  While this temporary loop exists, 
>>>multicast/broadcasts would duplicate to edge ports each time they 
>>>came
> 
> 
>>>around - until the TTL reaches its limit.
>>>
>>> - Larry
>>>
>>>From: [email-masked] [mailto:[email-masked]]
>>>On Behalf Of Joe Touch
>>>Sent: Tuesday, October 11, 2005 1:02 PM
>>>Subject: Re: [rbridge] loops in trill networks
>>>
>>>
>>>
>>>Larry Kreeger (kreeger) wrote:
>>>
>>>
>>>>>OK, I can see how a TTL will stop loops, and would prevent 
>>>>>duplicate known unicasts from being delivered, but how does a TTL 
>>>>>stop broadcast/multicast/unknown unicast frames from being 
>>>>>duplicated to edge ports each time the frame comes round the loop?
>>>
>>>
>>>The multicast/broadcast packets are forwarded by one or more spanning

>>>trees. There should never be loops in those anyway as a result.
>>>
>>>Joe
>>>
>>>
>>>
>>>>>Or is this considered
>>>>>OK behavior in an RBridge network compared to an 802.1 bridged
>>>
>>>network?
>>>
>>>
>>>>>New to all this...  - Larry
>>>>>
>>>>>From: [email-masked] 
>>>>>[mailto:[email-masked]]
>>>>>On Behalf Of Joe Touch
>>>>>Sent: Tuesday, October 11, 2005 7:07 AM
>>>>>Subject: Re: [rbridge] loops in trill networks
>>>>>
>>>>>There is, and that's what it's there for.
>>>>>
>>>>>Joe
>>>>>
>>>>>Mike Hughes wrote:
>>>>>
>>>>>
>>>>>
>>>>>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>this might be an old discussion, but it is some time since it 
>>>>>>>look at
>>>
>>>
>>>>>>>it. What do we do in trill networks about transient loops, i.e. 
>>>>>>>if use
>>>>>
>>>>>
>>>>>>>link state protocols there is a possibility that we have 
>>>>>>>transient loops. With no TTL mechanisms those looping frames 
>>>>>>>could cause quite a
>>>>>
>>>>>
>>>>>>>bit of problem.
>>>>>>
>>>>>>
>>>>>>Unless I've missed something, or things have changed overnight, 
>>>>>>there is a TTL provided in the SHIM header.
>>>>>>
>>>>>>Mike
>>>>>
>>>>>[email-masked]
> [email-masked]
> [email-masked]
[email-masked]
[email-masked]
[email-masked]

Date: Tue, 11 Oct 2005 14:47:43 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1521

There was never a "guarantee" in STP that there not be loops. STP 
attempted to
avoid them by waiting before turning ports on. RSTP, instead of waiting 
before turning on ports,
attempts to avoid loops by using local information to turn some links on 
while turning others off.

Although it's certainly good to try to avoid temporary loops, it's never 
possible to *guarantee*
no temporary loops. These can be caused by misconfiguration (someone 
claiming a port will
only have endnodes, whereas it actually does get connected to a switch), 
by bringing up
a repeater, or having enough consecutive BPDUs lost for whatever reason 
(congestion on
the link causing packets to not reach a bridge, or the bridge not being 
able to keep up
with worst case wire speed).

The thing that got me interested in this again is finding out that 
bridge meltdowns (due to
temporary loops) do occur, and apparently with increasing frequency with 
new features that
have been added to bridges that involve configuration that can be 
disastrous if set incorrectly,
or with bridges deployed that can't keep up with wire speeds.

So the idea is that although it's certainly good to try to avoid 
temporary loops, we want to make
it not a disaster if they do occur.

Radia

Larry Kreeger (kreeger) wrote:

>Joe,
>
>As far as I know, all variations of STP guaranteed that bridged networks
>never have temporary loops, so existing bridges never have this problem.
>If they did, then I'd agree that it is no different. 
>
> - Larry
>
>
>  
>

Date: Tue, 11 Oct 2005 14:38:16 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1680

RBridges will not participate in BPDUs. They will drop them.

It is possible to have a bridge that "does not participate" (some bridges
allow you to "turn off the spanning tree"), but in that case, the bridge
would forward a BPDU without processing it.

Bridges that do "participate in BPDUs" don't simply forward them. 
Instead they absorb them, and generate
their own, on links for which they are Designated Bridge.

RBridges will neither forward BPDUs, nor generate their own BPDUs.

In contrast, a bridge will either have spanning tree turned off (in 
which case it will forward all BPDUs on
all ports without processing them) or turned on (in which case it will 
process the BPDUs in order to
determine its distance to the Root bridge, and in order to determine 
which links it should be DB on,
and for those links, to generate its own BPDU).

Radia

>
>  
>
>>Rbridges - like routers - do not forward BPDUs.
>>    
>>
>
>Let me propose a question. Let's say an rbridge campus looks like a
>single giant bridge (humor me).
>
>There are two cases:
>
>	- the bridge participates in BPDU
>
>	- the bridge does not participate in BPDU
>
>Is it possible in existing systems to have a bridge that does not
>participate in BPDU? Wouldn't this end up creating loops?
>
>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDTChhE5f5cImnZrsRAkAqAKCrkBhoqAYQsRB1/W1OlhWtuOlg0QCgyfj7
>+kCndWeVdgjyigTPYUF4U3Y=
>=wt7Z
>-----END PGP SIGNATURE-----
>[email-masked]

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 11 Oct 2005 17:25:53 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] loops in trill networks
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 576

> What I mean by "n spanning trees that do not see each other" is that the 
> RBridges don't glue the
> 802.1d spanning tree together into a single 802.1d spanning
> tree with one Root Bridge, etc.
> 
> They do, however, create a single broadcast domain, and ARPs go across
> the RBridges. So indeed an ARP is carried over a spanning tree, but it's 
> not THE spanning tree
> calculated by the 802.1d spanning tree algorithm.

Won't that create possible loops?

Joe

[Saikat] RBridges would broadcast over a spanning tree (of the graph
consisting of the RBridges), isn't it?

Date: Tue, 11 Oct 2005 14:22:01 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4115

Larry Kreeger (kreeger) wrote:
> Joe,
> 
> As far as I know, all variations of STP guaranteed that bridged networks
> never have temporary loops, so existing bridges never have this problem.
> If they did, then I'd agree that it is no different. 

I'm confused. We are using STP for multicast/broadcast inside the
campus. Why then will that STP cause loops whereas current bridges do not?

Joe

>  - Larry
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Joe Touch
> Sent: Tuesday, October 11, 2005 1:47 PM
> Subject: Re: [rbridge] loops in trill networks
> 
> Yes - but I think Radia pointed out that this is no different than how
> existing bridges would behave in that circumstance.
> 
> joe
> 
> 
> Larry Kreeger (kreeger) wrote:
> 
>>>Joe,
>>>
>>>The context was that during a topology change, there could be a 
>>>temporary loop.  While this temporary loop exists, 
>>>multicast/broadcasts would duplicate to edge ports each time they came
> 
> 
>>>around - until the TTL reaches its limit.
>>>
>>> - Larry
>>>
>>>From: [email-masked] [mailto:[email-masked]] 
>>>On Behalf Of Joe Touch
>>>Sent: Tuesday, October 11, 2005 1:02 PM
>>>Subject: Re: [rbridge] loops in trill networks
>>>
>>>
>>>
>>>Larry Kreeger (kreeger) wrote:
>>>
>>>
>>>>>OK, I can see how a TTL will stop loops, and would prevent duplicate 
>>>>>known unicasts from being delivered, but how does a TTL stop 
>>>>>broadcast/multicast/unknown unicast frames from being duplicated to 
>>>>>edge ports each time the frame comes round the loop?
>>>
>>>
>>>The multicast/broadcast packets are forwarded by one or more spanning 
>>>trees. There should never be loops in those anyway as a result.
>>>
>>>Joe
>>>
>>>
>>>
>>>>>Or is this considered
>>>>>OK behavior in an RBridge network compared to an 802.1 bridged
>>>
>>>network?
>>>
>>>
>>>>>New to all this...  - Larry
>>>>>
>>>>>From: [email-masked] [mailto:[email-masked]]
>>>>>On Behalf Of Joe Touch
>>>>>Sent: Tuesday, October 11, 2005 7:07 AM
>>>>>Subject: Re: [rbridge] loops in trill networks
>>>>>
>>>>>There is, and that's what it's there for.
>>>>>
>>>>>Joe
>>>>>
>>>>>Mike Hughes wrote:
>>>>>
>>>>>
>>>>>
>>>>>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>this might be an old discussion, but it is some time since it look 
>>>>>>>at
>>>
>>>
>>>>>>>it. What do we do in trill networks about transient loops, i.e. if 
>>>>>>>use
>>>>>
>>>>>
>>>>>>>link state protocols there is a possibility that we have transient 
>>>>>>>loops. With no TTL mechanisms those looping frames could cause 
>>>>>>>quite a
>>>>>
>>>>>
>>>>>>>bit of problem.
>>>>>>
>>>>>>
>>>>>>Unless I've missed something, or things have changed overnight, 
>>>>>>there is a TTL provided in the SHIM header.
>>>>>>
>>>>>>Mike
>>>>>
>>>>>[email-masked]
> [email-masked]
> [email-masked]
[email-masked]
[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 11 Oct 2005 14:13:01 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3571

Joe,

As far as I know, all variations of STP guaranteed that bridged networks
never have temporary loops, so existing bridges never have this problem.
If they did, then I'd agree that it is no different. 

 - Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Touch
Sent: Tuesday, October 11, 2005 1:47 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

Yes - but I think Radia pointed out that this is no different than how
existing bridges would behave in that circumstance.

joe

Larry Kreeger (kreeger) wrote:
> Joe,
> 
> The context was that during a topology change, there could be a 
> temporary loop.  While this temporary loop exists, 
> multicast/broadcasts would duplicate to edge ports each time they came

> around - until the TTL reaches its limit.
> 
>  - Larry
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Joe Touch
> Sent: Tuesday, October 11, 2005 1:02 PM
> Subject: Re: [rbridge] loops in trill networks
> 
> 
> 
> Larry Kreeger (kreeger) wrote:
> 
>>>OK, I can see how a TTL will stop loops, and would prevent duplicate 
>>>known unicasts from being delivered, but how does a TTL stop 
>>>broadcast/multicast/unknown unicast frames from being duplicated to 
>>>edge ports each time the frame comes round the loop?
> 
> 
> The multicast/broadcast packets are forwarded by one or more spanning 
> trees. There should never be loops in those anyway as a result.
> 
> Joe
> 
> 
>>>Or is this considered
>>>OK behavior in an RBridge network compared to an 802.1 bridged
> 
> network?
> 
>>>New to all this...  - Larry
>>>
>>>From: [email-masked] [mailto:[email-masked]]
>>>On Behalf Of Joe Touch
>>>Sent: Tuesday, October 11, 2005 7:07 AM
>>>Subject: Re: [rbridge] loops in trill networks
>>>
>>>There is, and that's what it's there for.
>>>
>>>Joe
>>>
>>>Mike Hughes wrote:
>>>
>>>
>>>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>this might be an old discussion, but it is some time since it look 
>>>>>at
> 
> 
>>>>>it. What do we do in trill networks about transient loops, i.e. if 
>>>>>use
>>>
>>>
>>>>>link state protocols there is a possibility that we have transient 
>>>>>loops. With no TTL mechanisms those looping frames could cause 
>>>>>quite a
>>>
>>>
>>>>>bit of problem.
>>>>
>>>>
>>>>Unless I've missed something, or things have changed overnight, 
>>>>there is a TTL provided in the SHIM header.
>>>>
>>>>Mike
>>>
>>>[email-masked]
[email-masked]
[email-masked]
[email-masked]

Date: Tue, 11 Oct 2005 14:10:16 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] steps towards the problem and architecture documents
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1494

Hi, all,

As promised, I've been working on the split of the existing rbridge
document into a set of more typical IETF-style documents:

	problem and applicability
	(this isn't even in the charter, butseems necessary IMO)
	(we can, if desired, merge it with the design/arch doc
	below to have a single doc if preferred)
		defining the problem
		describing the solution based on desired benefits
			(leaving architecture open)
		explaining cases where it is expected to be useful

	design (I would call this the architecture doc; is that OK?
	that matches more what we call it in the charter)
		defining terms
		defining the basic components of the proposed solution
		describing the operation based on functional behavior
			(leaving implementation particulars open)

	specification (some would call this a protocol doc;
	is that preferred?)
		describe the details of a particular instance of the
		architecture, including specific headers, fields, etc.
		and processing expected

		this document may also specify the routing protocol
		(setting CFT entries)
		or protocol used to exchange egress info (CTT entries)

Just so we know what belongs in which document before we all start.

Joe

Content-class: urn:content-classes:message
Date: Tue, 11 Oct 2005 14:07:47 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5625

Radia,

How about the case where the two ports connected to the same bridged
domain are on different RBridges?

Consider, the following topology where A,B,C are hosts.

A--RB1--Bridged-Domain--RB2--B
              |
              |
             RB3--C

In this case, would all RB's forward a L2 broadcast to their respective
edge ports?  I was assuming, yes.  If so, then RB1,RB2 and RB3 are all
designated RBs in order to have broadcast connectivity between A,B,C.

Now a new RB4 is added to the topology which connects RB1 and RB3,

A--RB1--Bridged-Domain--RB2--B
    |         |
    |         |
D--RB4-------RB3--C

Are you saying that RB1 and RB3 detect that they now have new
connectivity and battle to be a Designated RB to serve their side of the
network?  Assuming RB3 wins, all broadcasts must enter and leave the
Bridged-Domain via RB3 to get between hosts A,C,D and B.  RB2 must still
be the Designated RB for traffic to reach B.

I didn't think routers needed to deal with this since they don't forward
broadcasts.  Are you saying that routing protocols already deal with
these types of scenarios?

Thanks, Larry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Tuesday, October 11, 2005 12:46 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

The intention is that deployment not have to be careful. If two of an
RBridge's ports are connected to the same bridged broadcast domain
(i.e., there is a bridge-connected path between the two ports), then the
RBridge will think it has two ports connected to the same link. Which is
OK.
It won't forward any packets, including not BPDUs, between those ports. 
At most one of
its ports will become "designated" for sourcing/sinking unencapsulated
traffic to/from that link.

It would be just like a router having two ports connected to the same
link, which should work with no problem.

Radia

Gray, Eric wrote:

>Radia,
>
>	If I am understanding what you are saying correctly, there are
some 
>deployment issues with Rbridges into a 802.1 bridged environment.
>
>	The deployment issues arise when individual RBridges are
installed, if 
>this is not carefully planned in advance.
>If an Rbridge is installed on a link where it is connected to two or 
>more 802.1 bridges and there is another L2 path between those two 
>bridges, the RBridge will either have to forward BPDUs or - like a 
>router - recognize that multiple ports are connected to the same LAN.
>
>	Is there an intention that the latter would be the default case
until 
>and unless the installed RBridge is able to discover a connected 
>RBridge peer?
>
>--
>Eric Gray
>
>--> -----Original Message-----
>--> From: [email-masked]
>--> [mailto:[email-masked]]On
>--> Behalf Of Radia Perlman
>--> Sent: Tuesday, October 11, 2005 12:44 PM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] loops in trill networks
>--> 
>--> 
>--> There's nothing an RBridge can do about loops consisting of just 
>--> bridges.
>--> Which is why it's good to partition the spanning trees formed by 
>--> the bridges so that the remaining spanning trees are as small, and 
>--> therefore as stable, as possible.
>--> 
>--> RBridges are like routers. They sit at a layer above bridges. The 
>--> bridges form what looks like a single link to the RBridges. If 
>--> there are a bunch of bridges connecting a bunch of segments, all 
>--> the RBridges attached to that portion of the network see that 
>--> bridged segment as a single link.
>--> 
>--> Radia
>--> 
>--> Loa Andersson wrote:
>--> 
>--> >Oh, yes it is true ...
>--> >
>--> >but I thought that a trill network could consist of a mixed of 
>--> >rbridges and the type of bridges that exist today, if that is the 
>--> >case you can possibly form the loop over only non-rbridges
>--> >
>--> >but I'm not up to speed on this, there might be a way to handle 
>--> >this also
>--> >
>--> >/Loa
>--> >
>--> >Joe Touch wrote:
>--> >  
>--> >
>--> >>There is, and that's what it's there for.
>--> >>
>--> >>Joe
>--> >>
>--> >>Mike Hughes wrote:
>--> >>
>--> >>    
>--> >>
>--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]>
wrote:
>--> >>>
>--> >>>
>--> >>>
>--> >>>      
>--> >>>
>--> >>>>this might be an old discussion, but it is some time since it 
>--> >>>>look at it. What do we do in trill networks about transient 
>--> >>>>loops, i.e. if use link state protocols there is a possibility 
>--> >>>>that we have transient loops. With no TTL mechanisms
>--> those looping
>--> >>>>frames could cause quite a bit of problem.
>--> >>>>        
>--> >>>>
>--> >>>Unless I've missed something, or things have changed
>--> overnight, there is a
>--> >>>TTL provided in the SHIM header.
>--> >>>
>--> >>>Mike
>--> >>>
>--> >>>
>--> >>>---------------------------------------------------------
>--> ---------------
>--> >>>
>--> >>>_______________________________________________
>--> >>>rbridge mailing list
>--> >>>[email-masked]
>--> >>>http://www.postel.org/mailman/listinfo/rbridge
>--> >>>      
>--> >>>
>--> >
>--> >
>--> >  
>--> >
>--> 
>--> _______________________________________________
>--> rbridge mailing list
>--> [email-masked]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>[email-masked]

[email-masked]

Date: Tue, 11 Oct 2005 14:03:21 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 970

Radia Perlman wrote:
> Joe...you and I are not disagreeing about the technical intent...just 
> getting hung up on terminology I think.

Which is important - because that's where I am in the docs ;-)

> What I mean by "n spanning trees that do not see each other" is that the 
> RBridges don't glue the
> 802.1d spanning tree together into a single 802.1d spanning
> tree with one Root Bridge, etc.
> 
> They do, however, create a single broadcast domain, and ARPs go across
> the RBridges. So indeed an ARP is carried over a spanning tree, but it's 
> not THE spanning tree
> calculated by the 802.1d spanning tree algorithm.

Won't that create possible loops?

Joe

Date: Tue, 11 Oct 2005 14:02:25 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1161

Gray, Eric wrote:
> Larry,
> 
> 	You've got the sense of Radia's reply reversed.  It's the
> 802.1 bridges that look like a single link to the RBridges.
> 
> 	This is pretty much how I expected this to work.  A cloud
> of 802.1 bridges MUST be completely enclosed in either RBridges
> or routers. 

I was expecting that to say "or there will be little or no benefit from
the rbridges" - i.e., topology restrictions can't be enforced per se if
we're expecting plug-and-play.

> Rbridges - like routers - do not forward BPDUs.

Let me propose a question. Let's say an rbridge campus looks like a
single giant bridge (humor me).

There are two cases:

	- the bridge participates in BPDU

	- the bridge does not participate in BPDU

Is it possible in existing systems to have a bridge that does not
participate in BPDU? Wouldn't this end up creating loops?

Joe

Date: Tue, 11 Oct 2005 14:00:00 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4479

Joe...you and I are not disagreeing about the technical intent...just 
getting hung up on terminology I think.

What I mean by "n spanning trees that do not see each other" is that the 
RBridges don't glue the
802.1d spanning tree together into a single 802.1d spanning
tree with one Root Bridge, etc.

They do, however, create a single broadcast domain, and ARPs go across
the RBridges. So indeed an ARP is carried over a spanning tree, but it's 
not THE spanning tree
calculated by the 802.1d spanning tree algorithm.

As far as IP nodes go, they can't tell whether what I call a campus is 
connected via bridges,
RBridges, repeaters, or any combination. It's all just a single 
broadcast domain. All the IP
nodes connected into this campus view it as a single link, a single IP 
subnet, where all
IP nodes on that campus view each other as direct neighbors.

The only message that is special to RBridges, in terms of
layer 2 multicasts, is the BPDU. That is not forwarded by RBridges. But 
all other
layer 2 multicasts get forwarded across the broadcast domain.

The collection of RBridges, bridges, and links DO form a single 
broadcast domain, together
with a spanning tree, but it's not the spanning tree calculated by 
802.1d spanning tree. It's
instead a spanning tree (or set of trees) calculated from the link state 
database.

However, there might still be 802.1d spanning trees on what an RBridge 
would think of
as single links.

Radia

Joe Touch wrote:

>
>>If you had a big 802.1d broadcast domain, and
>>partitioned
>>it into n pieces, with the pieces connected with RBridges (and not with 
>>bridges),
>>you'd wind up with n spanning trees that did not see each other.
>>    
>>
>
>That seems to cause the problem above, though.
>
>Joe
>
>  
>
>>Radia
>>
>>
>>
>>Larry Kreeger (kreeger) wrote:
>>
>>
>>    
>>
>>>This brings up another question.
>>>
>>>What does the RBridge network look like to the 802.1 bridged network.
>>>Does the RBridge network pretend it is a giant 802.1D bridge -
>>>exchanging BPDUs at its edge ports with the 802.1 bridges and blocking
>>>edge ports if it detects a loop?  What happens to the BPDUs sent by
>>>802.1 bridges to the RBridges?
>>>
>>>- Larry 
>>>
>>>From: [email-masked] [mailto:[email-masked]] On
>>>Behalf Of Joe Touch
>>>Sent: Tuesday, October 11, 2005 8:26 AM
>>>Subject: Re: [rbridge] loops in trill networks
>>>
>>>      
>>>
>>Loa Andersson wrote:
>> 
>>
>>
>>    
>>
>>>Oh, yes it is true ...
>>>      
>>>
>>>but I thought that a trill network could consist of a mixed of 
>>>rbridges and the type of bridges that exist today, if that is the case
>>>      
>>>
>>
>> 
>>
>>
>>    
>>
>>>you can possibly form the loop over only non-rbridges
>>>      
>>>
>>
>>The conventional bridges have a spanning tree, which is what already
>>prevents such loops currently.
>>
>>Think of the path between two nodes (hosts, routers, etc. - anything
>>that sources/sinks L2 frames) as having three components (at most):
>>
>>node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node
>>
>>the ingress (bridgepath1) and egress (bridgepath2) conventional bridge
>>paths use spanning trees, so they can't have loops.
>>
>>The rbridge uses the TTL, so it can't have a loop at its layer. Even
>>when it tunnels over conventional bridges ('inside' the rbridge, in a
>>sense), those can't have loops because they're spanning-tree.
>>
>>The combination of spanning tree in all bridge paths and TTL in the
>>rbridge logical path prevents loops in the node-node path.
>>
>>Joe
>>    
>>
>[email-masked]
>[email-masked]
>>[email-masked]
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDTCHQE5f5cImnZrsRAn/bAJ9mD1R9reyuHG9vECvNNVelOTva6ACfVJLk
>50SX6s3uugIlvrf0O6DZnng=
>=720Z
>-----END PGP SIGNATURE-----
>[email-masked]

Date: Tue, 11 Oct 2005 13:46:50 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2963

Yes - but I think Radia pointed out that this is no different than how
existing bridges would behave in that circumstance.

joe

Larry Kreeger (kreeger) wrote:
> Joe,
> 
> The context was that during a topology change, there could be a
> temporary loop.  While this temporary loop exists, multicast/broadcasts
> would duplicate to edge ports each time they came around - until the TTL
> reaches its limit.
> 
>  - Larry
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Joe Touch
> Sent: Tuesday, October 11, 2005 1:02 PM
> Subject: Re: [rbridge] loops in trill networks
> 
> 
> 
> Larry Kreeger (kreeger) wrote:
> 
>>>OK, I can see how a TTL will stop loops, and would prevent duplicate 
>>>known unicasts from being delivered, but how does a TTL stop 
>>>broadcast/multicast/unknown unicast frames from being duplicated to 
>>>edge ports each time the frame comes round the loop?
> 
> 
> The multicast/broadcast packets are forwarded by one or more spanning
> trees. There should never be loops in those anyway as a result.
> 
> Joe
> 
> 
>>>Or is this considered
>>>OK behavior in an RBridge network compared to an 802.1 bridged
> 
> network?
> 
>>>New to all this...  - Larry
>>>
>>>From: [email-masked] [mailto:[email-masked]] 
>>>On Behalf Of Joe Touch
>>>Sent: Tuesday, October 11, 2005 7:07 AM
>>>Subject: Re: [rbridge] loops in trill networks
>>>
>>>There is, and that's what it's there for.
>>>
>>>Joe
>>>
>>>Mike Hughes wrote:
>>>
>>>
>>>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>this might be an old discussion, but it is some time since it look at
> 
> 
>>>>>it. What do we do in trill networks about transient loops, i.e. if 
>>>>>use
>>>
>>>
>>>>>link state protocols there is a possibility that we have transient 
>>>>>loops. With no TTL mechanisms those looping frames could cause quite 
>>>>>a
>>>
>>>
>>>>>bit of problem.
>>>>
>>>>
>>>>Unless I've missed something, or things have changed overnight, there 
>>>>is a TTL provided in the SHIM header.
>>>>
>>>>Mike
>>>
>>>[email-masked]
[email-masked]
[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 11 Oct 2005 13:45:05 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2522

Joe,

The context was that during a topology change, there could be a
temporary loop.  While this temporary loop exists, multicast/broadcasts
would duplicate to edge ports each time they came around - until the TTL
reaches its limit.

 - Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Touch
Sent: Tuesday, October 11, 2005 1:02 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

Larry Kreeger (kreeger) wrote:
> OK, I can see how a TTL will stop loops, and would prevent duplicate 
> known unicasts from being delivered, but how does a TTL stop 
> broadcast/multicast/unknown unicast frames from being duplicated to 
> edge ports each time the frame comes round the loop?

The multicast/broadcast packets are forwarded by one or more spanning
trees. There should never be loops in those anyway as a result.

Joe

> Or is this considered
> OK behavior in an RBridge network compared to an 802.1 bridged
network?
> 
> New to all this...  - Larry
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Joe Touch
> Sent: Tuesday, October 11, 2005 7:07 AM
> Subject: Re: [rbridge] loops in trill networks
> 
> There is, and that's what it's there for.
> 
> Joe
> 
> Mike Hughes wrote:
> 
>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>
>>
>>
>>>this might be an old discussion, but it is some time since it look at

>>>it. What do we do in trill networks about transient loops, i.e. if 
>>>use
> 
> 
>>>link state protocols there is a possibility that we have transient 
>>>loops. With no TTL mechanisms those looping frames could cause quite 
>>>a
> 
> 
>>>bit of problem.
>>
>>
>>Unless I've missed something, or things have changed overnight, there 
>>is a TTL provided in the SHIM header.
>>
>>Mike
> 
> [email-masked]
[email-masked]

Date: Tue, 11 Oct 2005 13:34:24 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3109

Radia Perlman wrote:
> RBridges do not participate in the 802.1d spanning tree. The neither 
> generate
> nor forward spanning tree messages.
> 
> They look to bridges
> like routers do today. 

Routers stop broadcasts; if rbridges do, then ARP won't work.

I was anticipating as Larry was - that a campus would act like a single
giant bridge.

> If you had a big 802.1d broadcast domain, and
> partitioned
> it into n pieces, with the pieces connected with RBridges (and not with 
> bridges),
> you'd wind up with n spanning trees that did not see each other.

That seems to cause the problem above, though.

Joe

> 
> Radia
> 
> 
> 
> Larry Kreeger (kreeger) wrote:
> 
> 
>>This brings up another question.
>>
>>What does the RBridge network look like to the 802.1 bridged network.
>>Does the RBridge network pretend it is a giant 802.1D bridge -
>>exchanging BPDUs at its edge ports with the 802.1 bridges and blocking
>>edge ports if it detects a loop?  What happens to the BPDUs sent by
>>802.1 bridges to the RBridges?
>>
>>- Larry 
>>
>>From: [email-masked] [mailto:[email-masked]] On
>>Behalf Of Joe Touch
>>Sent: Tuesday, October 11, 2005 8:26 AM
>>Subject: Re: [rbridge] loops in trill networks
>>
> 
> 
> Loa Andersson wrote:
>  
> 
> 
>>Oh, yes it is true ...
> 
>>but I thought that a trill network could consist of a mixed of 
>>rbridges and the type of bridges that exist today, if that is the case
> 
> 
> 
>  
> 
> 
>>you can possibly form the loop over only non-rbridges
> 
> 
> 
> The conventional bridges have a spanning tree, which is what already
> prevents such loops currently.
> 
> Think of the path between two nodes (hosts, routers, etc. - anything
> that sources/sinks L2 frames) as having three components (at most):
> 
> node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node
> 
> the ingress (bridgepath1) and egress (bridgepath2) conventional bridge
> paths use spanning trees, so they can't have loops.
> 
> The rbridge uses the TTL, so it can't have a loop at its layer. Even
> when it tunnels over conventional bridges ('inside' the rbridge, in a
> sense), those can't have loops because they're spanning-tree.
> 
> The combination of spanning tree in all bridge paths and TTL in the
> rbridge logical path prevents loops in the node-node path.
> 
> Joe
[email-masked]
[email-masked]

> [email-masked]

Date: Tue, 11 Oct 2005 13:34:13 -0700
From: Alia Atlas <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3455

------=_Part_28831_16808081.1129062853030
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/11/05, Harald Tveit Alvestrand <[email-masked]> wrote:
>
>
>
> --On tirsdag, oktober 11, 2005 11:17:48 -0700 Alia Atlas
> <[email-masked]> wrote:
>
> > All the IETF protocols, I believe, are designed to withstand some packe=
t
> > reordering (and should, in my opinion, any well designed protocol).
> >
> >
> >
> > Sure - anything on top of IP isn't an issue. My concern was other stuff=
.
>
>
> Reordering (anything that places a packet more than 3 places out of its
> proper position in the TCP stream) will trigger TCP duplicate acks, and
> therefore retransmissions.
>
> These play hell with performance.

Sure. But we live with these issues today on IP networks during a network
convergence event. Therefore, it seems reasonable that the IP traffic could
live with the same issues between RBridges during a convergence event there=
.

The other aspect of this is having acceptable load-balancing such that
micro-flows
don't get reordered - but we beat that to death a while ago.

Alia

No numbers......
> [email-masked]

------=_Part_28831_16808081.1129062853030
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div><span class=3D"gmail_quote">On 10/11/05, <b class=3D"gmail_sen=
dername">Harald Tveit Alvestrand</b> &lt;<a href=3D"mailto:harald@alvestran=
d.no">[email-masked]</a>&gt; wrote:</span><blockquote class=3D"gmail_=
quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt =
0pt 0.8ex; padding-left: 1ex;">
<br><br>--On tirsdag, oktober 11, 2005 11:17:48 -0700 Alia Atlas<br>&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br><br>&=
gt; All the IETF protocols, I believe, are designed to withstand some packe=
t
<br>&gt; reordering (and should, in my opinion, any well designed protocol)=
.<br>&gt;<br>&gt;<br>&gt;<br>&gt; Sure - anything on top of IP isn't an iss=
ue.&nbsp;&nbsp;My concern was other stuff.<br><br><br>Reordering (anything =
that places a packet more than 3 places out of its
<br>proper position in the TCP stream) will trigger TCP duplicate acks, and=
<br>therefore retransmissions.<br><br>These play hell with performance.</bl=
ockquote><div><br>
Sure.&nbsp; But we live with these issues today on IP networks during a net=
work <br>
convergence event.&nbsp; Therefore, it seems reasonable that the IP traffic=
 could<br>
live with the same issues between RBridges during a convergence event there=
.<br>
<br>
&nbsp;The other aspect of this is having acceptable load-balancing such tha=
t micro-flows<br>
don't get reordered - but we beat that to death a while ago.<br>
<br>
Alia<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">No numb=
ers......<br><br>_______________________________________________<br>rbridge=
 mailing list
<br><a href=3D"mailto:[email-masked]">[email-masked]</a><br><a href=
=3D"http://www.postel.org/mailman/listinfo/rbridge">http://www.postel.org/m=
ailman/listinfo/rbridge</a><br></blockquote></div><br>

------=_Part_28831_16808081.1129062853030--

Date: Tue, 11 Oct 2005 13:32:38 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1945

I don't think I'm disagreeing with what you're saying, Dino. Certainly 
if there is a layer 3 IGP
running on top of the RBridged link, then the RBridges (like any bridges 
contained in that
same IP subnet) would be forwarding the IGP messages, just like they'd 
be forwarding
anything they see as data packets traversing the "link".

As for providing glue to two broadcast domains in order to merge 
them...yes, an RBridged "campus"
could be used to tunnel packets from the two broadcast domains in order 
to merge them.

But in general an RBridge would not forward a native BPDU. It would 
recognize it as something
it shouldn't forward. Because RBridges intend to make the spanning trees 
smaller. But if someone
really wanted to glue the domains together, the BPDU could traverse the 
RBridges by being
tunneled and directed, as a data packet, to something on the other side.

Perhaps the right way to think of it is that a bunch of segments
connected with any mixture of RBridges and bridges would provide
the same functionality as today would be provided by those segments 
connected with bridges.
But it would just be safer, and more efficient (better paths, allow for 
path splitting).

Radia

Dino Farinacci wrote:

>>>or routers. Rbridges - like routers - do not forward BPDUs.
>>>      
>>>
>
>    For the same token, should two routers connected to an RBridge network
>    running IS-IS (at L3 for IP) not get their multicast frames to each other?
>
>    Again, RBridges may be acting like routers, but they provide a single
>    subnet to the edge nodes. So in this case and the BPDU case, the frames
>    should be forwarded through the RBridge network.
>
>    If this is not the case, then we are building solely a stub network.
>    Is this really what we want to do?
>
>Dino
>    
>[email-masked]

Date: Tue, 11 Oct 2005 13:24:50 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] terminology question for drafts
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3325

Radia Perlman wrote:
> I was actually talking with Joe about a good name for that table.

I was wondering if we might call it the Campus Transit Table (CTT), and
the other one the Campus Forwarding Table (CFT) - to distinguish it from
conventional IP router forwarding tables, or frame forwarding tables
inside conventional bridges using spanning trees.

Below is a cut of some proposed terminology, including the above.
Discussion encouraged; please limit discussion to the definitions here;
other topics will be raised in separate emails.

Joe

- ------------------------------------------------------------------------

Existing Terminology
[THIS IS TRYING TO ENCODE EXISTING TERMS; NOT NEW DEFINITIONS]

- - 802.1: IEEE Specification for Ethernet, i.e., including hubs (but
excluding bridges??)

- - 802.1D: IEEE Specification for switched Ethernet, i.e., including
bridges (??)

[WHAT?S THE DIFFERENCE BETWEEN 802.1, 802.1D, etc.? DOES IT MATTER?]

- - Bridge: an Ethernet (L2, 802.1D) forwarding device that participates
in the bridge spanning tree (BST).

- - Bridge spanning tree (BST): an Ethernet (L2, 802.1D) forwarding
protocol based on the topology of a spanning tree

- - Bridge spanning tree protocol (BSTP): an Ethernet (802.1D) protocol
for establishing and maintaining a single spanning tree among all the
bridges on a logical segment.

- - Frame: here refers to an Ethernet (L2) unit of transmission, including
the header, data, and trailer.

- - Frame forwarding table (FFT): forwarding table in existing bridges

- - Hub: an Ethernet (L2, 802.1)

- - Node: a device with an L2 address that sources and/or sinks L2
packets; nodes can occur outside the RBridge campus or be used as
transits within the campus.

- - Packet: here refers t- an IP (L3) unit of transmission, including
header and data.

- - Segment: an L2 link, either a single physical link or emulation
thereof (e.g., via hubs) or a logical link or emulation thereof (e.g.,
via bridges).

- - Router: an IP (L3) forwarding device; RBridges cannot span routers.

==========================================================================
RBridge Terminology

- - Campus: a set of RBridge devices inside the same L2 subnet, all of
which participate as a group to forward ingress L2 frames across the
campus via encapsulation.

- - Campus Forwarding Table (CFT): the per-hop forwarding table populated
by the rbridge IGP based on lookups of the CTH inside the outermost
received L2 header, rather than that L2 header.

- - Campus Transit Header (CTH): a ?shim? header that encapsulates the
ingress L2 frame and persists throughout the transit of a campus, which
is further encapsulated a hop-by-hop L2 header/trailer.

- - Campus Transit Table (CTT): a table that maps ingress L2 destinations
to egress RBridge addresses, used to encapsulate ingress frames for
transit of the campus.

- - RBridge: layer-2 devices that automatically aggregate into a virtual
device that emulates a single bridge on a conventional 802.1 Ethernet.

- --------

Date: Tue, 11 Oct 2005 13:12:50 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 546

>> or routers. Rbridges - like routers - do not forward BPDUs.

    For the same token, should two routers connected to an RBridge network
    running IS-IS (at L3 for IP) not get their multicast frames to each other?

    Again, RBridges may be acting like routers, but they provide a single
    subnet to the edge nodes. So in this case and the BPDU case, the frames
    should be forwarded through the RBridge network.

    If this is not the case, then we are building solely a stub network.
    Is this really what we want to do?

Dino

Date: Tue, 11 Oct 2005 13:09:43 -0700
From: Dino Farinacci <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 345

>> RBridges neither forward nor generate BPDUs.

    Radia this implies that two bridges cannot use an RBridges network as
    transit? This is not true in the case where the two bridges were connected
    to a multi-access ethernet with real hosts on them. 

    I think the model could be the same and think is desirable to be the same.

Dino

Date: Tue, 11 Oct 2005 13:04:50 -0700
From: Joe Touch <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] rbridge Digest, Vol 17, Issue 5
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1854

Stephen Suryaputra wrote:
> 
> On 10/8/05, [email-masked]
> <mailto:[email-masked]>* <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Joe Touch wrote:
> 
> [ deleted ]
> 
>     As to the above,, here's a clarified version:
> 
>     There are three kinds of L2 devices in an rbridge:
> 
>             hosts: anything that sources/sinks L2 packets
>                     e.g., RFC1122-style hosts, RFC1812-style routers
>                     (routers act like hosts to L2)
> 
>             bridges: transit conventional L2 packets and source/sink/transit
>                     spanning tree messages
> 
>             rbridges: encapsulate/decapsulate L2 packets with shim/L2 hdrs
>                     exchange routing via IS-IS,
>                     exchange egress tables via some protocol (TBD)

Hi, Stephen,

> I have been following the discussion on and off recently, and am still
> catching up. This is the first time I heard about egress table. Is it
> the L2 address to egress Rbridge mapping?

The L2 ingress address is mapped to rbridge egresses.

> If yes, why do we need another
> protocol to exchange those? I thought IS-IS was chosen because it is
> easy to advertise those L2 addresses using its link state packet?

Someone else can clarify; my understanding is that IS-IS will help with
distributing the hop-by-hop forwarding tables inside the rbridge nodes
(as an IGP), but doesn't have enough information to distribute egresses
(that would be more what an EGP would do).

Joe

Date: Tue, 11 Oct 2005 13:02:28 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1887

Larry Kreeger (kreeger) wrote:
> OK, I can see how a TTL will stop loops, and would prevent duplicate
> known unicasts from being delivered, but how does a TTL stop
> broadcast/multicast/unknown unicast frames from being duplicated to edge
> ports each time the frame comes round the loop? 

The multicast/broadcast packets are forwarded by one or more spanning
trees. There should never be loops in those anyway as a result.

Joe

> Or is this considered
> OK behavior in an RBridge network compared to an 802.1 bridged network?
> 
> New to all this...  - Larry  
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Joe Touch
> Sent: Tuesday, October 11, 2005 7:07 AM
> Subject: Re: [rbridge] loops in trill networks
> 
> There is, and that's what it's there for.
> 
> Joe
> 
> Mike Hughes wrote:
> 
>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>
>>
>>
>>>this might be an old discussion, but it is some time since it look at 
>>>it. What do we do in trill networks about transient loops, i.e. if use
> 
> 
>>>link state protocols there is a possibility that we have transient 
>>>loops. With no TTL mechanisms those looping frames could cause quite a
> 
> 
>>>bit of problem.
>>
>>
>>Unless I've missed something, or things have changed overnight, there 
>>is a TTL provided in the SHIM header.
>>
>>Mike
> 
> [email-masked]

Date: Tue, 11 Oct 2005 12:46:27 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4129

The intention is that deployment not have to be careful. If two of an 
RBridge's ports are connected
to the same bridged broadcast domain (i.e., there is a bridge-connected 
path between the two
ports), then the RBridge will think it has two ports connected to the 
same link. Which is OK.
It won't forward any packets, including not BPDUs, between those ports. 
At most one of
its ports will become "designated" for sourcing/sinking unencapsulated 
traffic to/from that link.

It would be just like a router having two ports connected to the same 
link, which should work
with no problem.

Radia

Gray, Eric wrote:

>Radia,
>
>	If I am understanding what you are saying correctly,
>there are some deployment issues with Rbridges into a 802.1
>bridged environment.
>
>	The deployment issues arise when individual RBridges
>are installed, if this is not carefully planned in advance.
>If an Rbridge is installed on a link where it is connected
>to two or more 802.1 bridges and there is another L2 path
>between those two bridges, the RBridge will either have to
>forward BPDUs or - like a router - recognize that multiple
>ports are connected to the same LAN.
>
>	Is there an intention that the latter would be the 
>default case until and unless the installed RBridge is able
>to discover a connected RBridge peer?
>
>--
>Eric Gray
>
>--> -----Original Message-----
>--> From: [email-masked] 
>--> [mailto:[email-masked]]On
>--> Behalf Of Radia Perlman
>--> Sent: Tuesday, October 11, 2005 12:44 PM
>--> To: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] loops in trill networks
>--> 
>--> 
>--> There's nothing an RBridge can do about loops consisting of 
>--> just bridges.
>--> Which is why it's good to partition the spanning trees formed by the
>--> bridges so that the remaining spanning trees are as small, 
>--> and therefore
>--> as stable, as possible.
>--> 
>--> RBridges are like routers. They sit at a layer above 
>--> bridges. The bridges
>--> form what looks like a single link to the RBridges. If 
>--> there are a bunch
>--> of bridges connecting a bunch of segments, all the RBridges 
>--> attached to
>--> that portion of the network see that bridged segment as a 
>--> single link.
>--> 
>--> Radia
>--> 
>--> Loa Andersson wrote:
>--> 
>--> >Oh, yes it is true ...
>--> >
>--> >but I thought that a trill network could consist of a mixed
>--> >of rbridges and the type of bridges that exist today, if that
>--> >is the case you can possibly form the loop over only non-rbridges
>--> >
>--> >but I'm not up to speed on this, there might be a way to handle
>--> >this also
>--> >
>--> >/Loa
>--> >
>--> >Joe Touch wrote:
>--> >  
>--> >
>--> >>There is, and that's what it's there for.
>--> >>
>--> >>Joe
>--> >>
>--> >>Mike Hughes wrote:
>--> >>
>--> >>    
>--> >>
>--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>--> >>>
>--> >>>
>--> >>>
>--> >>>      
>--> >>>
>--> >>>>this might be an old discussion, but it is some time since it
>--> >>>>look at it. What do we do in trill networks about transient
>--> >>>>loops, i.e. if use link state protocols there is a possibility
>--> >>>>that we have transient loops. With no TTL mechanisms 
>--> those looping
>--> >>>>frames could cause quite a bit of problem.
>--> >>>>        
>--> >>>>
>--> >>>Unless I've missed something, or things have changed 
>--> overnight, there is a
>--> >>>TTL provided in the SHIM header.
>--> >>>
>--> >>>Mike
>--> >>>
>--> >>>
>--> >>>---------------------------------------------------------
>--> ---------------
>--> >>>
>--> >>>_______________________________________________
>--> >>>rbridge mailing list
>--> >>>[email-masked]
>--> >>>http://www.postel.org/mailman/listinfo/rbridge
>--> >>>      
>--> >>>
>--> >
>--> >
>--> >  
>--> >
>--> 
>--> _______________________________________________
>--> rbridge mailing list
>--> [email-masked]
>--> http://www.postel.org/mailman/listinfo/rbridge
>--> 
>[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 11 Oct 2005 16:31:05 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3252

Radia,

	If I am understanding what you are saying correctly,
there are some deployment issues with Rbridges into a 802.1
bridged environment.

	The deployment issues arise when individual RBridges
are installed, if this is not carefully planned in advance.
If an Rbridge is installed on a link where it is connected
to two or more 802.1 bridges and there is another L2 path
between those two bridges, the RBridge will either have to
forward BPDUs or - like a router - recognize that multiple
ports are connected to the same LAN.

	Is there an intention that the latter would be the 
default case until and unless the installed RBridge is able
to discover a connected RBridge peer?

--
Eric Gray

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Radia Perlman
--> Sent: Tuesday, October 11, 2005 12:44 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> There's nothing an RBridge can do about loops consisting of 
--> just bridges.
--> Which is why it's good to partition the spanning trees formed by the
--> bridges so that the remaining spanning trees are as small, 
--> and therefore
--> as stable, as possible.
--> 
--> RBridges are like routers. They sit at a layer above 
--> bridges. The bridges
--> form what looks like a single link to the RBridges. If 
--> there are a bunch
--> of bridges connecting a bunch of segments, all the RBridges 
--> attached to
--> that portion of the network see that bridged segment as a 
--> single link.
--> 
--> Radia
--> 
--> Loa Andersson wrote:
--> 
--> >Oh, yes it is true ...
--> >
--> >but I thought that a trill network could consist of a mixed
--> >of rbridges and the type of bridges that exist today, if that
--> >is the case you can possibly form the loop over only non-rbridges
--> >
--> >but I'm not up to speed on this, there might be a way to handle
--> >this also
--> >
--> >/Loa
--> >
--> >Joe Touch wrote:
--> >  
--> >
--> >>There is, and that's what it's there for.
--> >>
--> >>Joe
--> >>
--> >>Mike Hughes wrote:
--> >>
--> >>    
--> >>
--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>>>this might be an old discussion, but it is some time since it
--> >>>>look at it. What do we do in trill networks about transient
--> >>>>loops, i.e. if use link state protocols there is a possibility
--> >>>>that we have transient loops. With no TTL mechanisms 
--> those looping
--> >>>>frames could cause quite a bit of problem.
--> >>>>        
--> >>>>
--> >>>Unless I've missed something, or things have changed 
--> overnight, there is a
--> >>>TTL provided in the SHIM header.
--> >>>
--> >>>Mike
--> >>>
--> >>>
--> >>>---------------------------------------------------------
--> ---------------
--> >>>
--> >>>_______________________________________________
--> >>>rbridge mailing list
--> >>>[email-masked]
--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >>>      
--> >>>
--> >
--> >
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 11 Oct 2005 16:21:19 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3963

Larry,

	You've got the sense of Radia's reply reversed.  It's the
802.1 bridges that look like a single link to the RBridges.

	This is pretty much how I expected this to work.  A cloud
of 802.1 bridges MUST be completely enclosed in either RBridges
or routers. Rbridges - like routers - do not forward BPDUs.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On
--> Behalf Of Larry Kreeger (kreeger)
--> Sent: Tuesday, October 11, 2005 3:01 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> OK, it looks like I asked my previous question prematurely.
--> 
--> If I understand this response correctly, since an RBridge 
--> looks like a
--> single link to the 802.1 bridges, this implies that an 
--> RBridge receiving
--> a BPDU will flood the BPDU to all edge ports.
--> 
--> Now back to the previous message I sent about loops and 
--> TTL.  I think
--> this means that during an RBridge topology change, these 
--> BPDUs could get
--> duplicated as they loop around (before TTL expires).
--> 
--> How kindly will 802.1 bridges react to receiving duplicate BPDUs?
--> 
-->  - Larry
--> 
--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]] On
--> Behalf Of Radia Perlman
--> Sent: Tuesday, October 11, 2005 9:44 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> There's nothing an RBridge can do about loops consisting of just
--> bridges.
--> Which is why it's good to partition the spanning trees formed by the
--> bridges so that the remaining spanning trees are as small, 
--> and therefore
--> as stable, as possible.
--> 
--> RBridges are like routers. They sit at a layer above bridges. The
--> bridges form what looks like a single link to the RBridges. 
--> If there are
--> a bunch of bridges connecting a bunch of segments, all the RBridges
--> attached to that portion of the network see that bridged 
--> segment as a
--> single link.
--> 
--> Radia
--> 
--> Loa Andersson wrote:
--> 
--> >Oh, yes it is true ...
--> >
--> >but I thought that a trill network could consist of a 
--> mixed of rbridges
--> 
--> >and the type of bridges that exist today, if that is the 
--> case you can 
--> >possibly form the loop over only non-rbridges
--> >
--> >but I'm not up to speed on this, there might be a way to 
--> handle this 
--> >also
--> >
--> >/Loa
--> >
--> >Joe Touch wrote:
--> >  
--> >
--> >>There is, and that's what it's there for.
--> >>
--> >>Joe
--> >>
--> >>Mike Hughes wrote:
--> >>
--> >>    
--> >>
--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>>>this might be an old discussion, but it is some time 
--> since it look 
--> >>>>at it. What do we do in trill networks about transient 
--> loops, i.e. 
--> >>>>if use link state protocols there is a possibility that we have 
--> >>>>transient loops. With no TTL mechanisms those looping 
--> frames could 
--> >>>>cause quite a bit of problem.
--> >>>>        
--> >>>>
--> >>>Unless I've missed something, or things have changed 
--> overnight, there
--> 
--> >>>is a TTL provided in the SHIM header.
--> >>>
--> >>>Mike
--> >>>
--> >>>
--> >>>---------------------------------------------------------
--> ------------
--> >>>---
--> >>>
--> >>>_______________________________________________
--> >>>rbridge mailing list
--> >>>[email-masked]
--> >>>http://www.postel.org/mailman/listinfo/rbridge
--> >>>      
--> >>>
--> >
--> >
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> _______________________________________________
--> rbridge mailing list
--> [email-masked]
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Date: Tue, 11 Oct 2005 12:17:00 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3393

No. I think I managed to confuse you (Larry Kreeger). Sorry about that. 
RBridges see a whole bridge-connected
set of links as a single link. Bridges do not see RBridges that way. 
Bridges see RBridges as
just endnodes.

RBridges neither forward nor generate BPDUs.

Radia

Larry Kreeger (kreeger) wrote:

>OK, it looks like I asked my previous question prematurely.
>
>If I understand this response correctly, since an RBridge looks like a
>single link to the 802.1 bridges, this implies that an RBridge receiving
>a BPDU will flood the BPDU to all edge ports.
>
>Now back to the previous message I sent about loops and TTL.  I think
>this means that during an RBridge topology change, these BPDUs could get
>duplicated as they loop around (before TTL expires).
>
>How kindly will 802.1 bridges react to receiving duplicate BPDUs?
>
> - Larry
>
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Radia Perlman
>Sent: Tuesday, October 11, 2005 9:44 AM
>Subject: Re: [rbridge] loops in trill networks
>
>There's nothing an RBridge can do about loops consisting of just
>bridges.
>Which is why it's good to partition the spanning trees formed by the
>bridges so that the remaining spanning trees are as small, and therefore
>as stable, as possible.
>
>RBridges are like routers. They sit at a layer above bridges. The
>bridges form what looks like a single link to the RBridges. If there are
>a bunch of bridges connecting a bunch of segments, all the RBridges
>attached to that portion of the network see that bridged segment as a
>single link.
>
>Radia
>
>Loa Andersson wrote:
>
>  
>
>>Oh, yes it is true ...
>>
>>but I thought that a trill network could consist of a mixed of rbridges
>>    
>>
>
>  
>
>>and the type of bridges that exist today, if that is the case you can 
>>possibly form the loop over only non-rbridges
>>
>>but I'm not up to speed on this, there might be a way to handle this 
>>also
>>
>>/Loa
>>
>>Joe Touch wrote:
>> 
>>
>>    
>>
>>>There is, and that's what it's there for.
>>>
>>>Joe
>>>
>>>Mike Hughes wrote:
>>>
>>>   
>>>
>>>      
>>>
>>>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>>>
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>>>this might be an old discussion, but it is some time since it look 
>>>>>at it. What do we do in trill networks about transient loops, i.e. 
>>>>>if use link state protocols there is a possibility that we have 
>>>>>transient loops. With no TTL mechanisms those looping frames could 
>>>>>cause quite a bit of problem.
>>>>>       
>>>>>
>>>>>          
>>>>>
>>>>Unless I've missed something, or things have changed overnight, there
>>>>        
>>>>
>
>  
>
>>>>is a TTL provided in the SHIM header.
>>>>
>>>>Mike
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>---
>>>>
>>>>[email-masked]
>[email-masked]
>[email-masked]

Date: Tue, 11 Oct 2005 12:11:18 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2684

RBridges do not participate in the 802.1d spanning tree. The neither 
generate
nor forward spanning tree messages.

They look to bridges
like routers do today. If you had a big 802.1d broadcast domain, and 
partitioned
it into n pieces, with the pieces connected with RBridges (and not with 
bridges),
you'd wind up with n spanning trees that did not see each other.

Radia

Larry Kreeger (kreeger) wrote:

>This brings up another question.
>
>What does the RBridge network look like to the 802.1 bridged network.
>Does the RBridge network pretend it is a giant 802.1D bridge -
>exchanging BPDUs at its edge ports with the 802.1 bridges and blocking
>edge ports if it detects a loop?  What happens to the BPDUs sent by
>802.1 bridges to the RBridges?
>
> - Larry 
>
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Joe Touch
>Sent: Tuesday, October 11, 2005 8:26 AM
>Subject: Re: [rbridge] loops in trill networks
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Loa Andersson wrote:
>  
>
>>Oh, yes it is true ...
>>
>>but I thought that a trill network could consist of a mixed of 
>>rbridges and the type of bridges that exist today, if that is the case
>>    
>>
>
>  
>
>>you can possibly form the loop over only non-rbridges
>>    
>>
>
>The conventional bridges have a spanning tree, which is what already
>prevents such loops currently.
>
>Think of the path between two nodes (hosts, routers, etc. - anything
>that sources/sinks L2 frames) as having three components (at most):
>
>node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node
>
>the ingress (bridgepath1) and egress (bridgepath2) conventional bridge
>paths use spanning trees, so they can't have loops.
>
>The rbridge uses the TTL, so it can't have a loop at its layer. Even
>when it tunnels over conventional bridges ('inside' the rbridge, in a
>sense), those can't have loops because they're spanning-tree.
>
>The combination of spanning tree in all bridge paths and TTL in the
>rbridge logical path prevents loops in the node-node path.
>
>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDS9mbE5f5cImnZrsRAktMAJ9MjJKSh87vJbfpJ4K0i+VDGJVRAQCdEbOH
>krcExxOH/y9ZuHOYMynTEIA=
>=3VVZ
>-----END PGP SIGNATURE-----
>[email-masked]
>[email-masked]

Date: Tue, 11 Oct 2005 21:09:54 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 544

--On tirsdag, oktober 11, 2005 11:17:48 -0700 Alia Atlas 
<[email-masked]> wrote:

> All the IETF protocols, I believe, are designed to withstand some packet
> reordering (and should, in my opinion, any well designed protocol).
>
>
>
> Sure - anything on top of IP isn't an issue.  My concern was other stuff.

Reordering (anything that places a packet more than 3 places out of its 
proper position in the TCP stream) will trigger TCP duplicate acks, and 
therefore retransmissions.

These play hell with performance.

No numbers......

Date: Tue, 11 Oct 2005 12:08:28 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4658

Just like current bridges, if there were a temporary loop, would 
duplicate packets, RBridges
would also, but more safely because of the hop count.

Radia

Michael Smith (michsmit) wrote:

>How about packet duplication ?  With unknown unicasts packets following
>the spanning tree, there is the potential for unicast packets to be
>duplicated and multiple copies received by the destination with or
>without TTL.   I don't believe current routing introduces packet
>duplication for unicast packets.  I'm not sure how non-IP protocols
>would behave in this case.
>
>Michael
>
>  
>
>>From: [email-masked] 
>>
>>I'm not sure what protocols there are that need absolute 
>>ordering guarantees.
>>RSTP can reorder sometimes after a topology change, so 
>>apparently occasional reordering is not considered a problem.
>>All the IETF protocols, I believe, are designed to withstand 
>>some packet reordering (and should, in my opinion, any well 
>>designed protocol).
>>
>>Radia
>>
>>Alia Atlas wrote:
>>
>>    
>>
>>>What about potential frame reordering
>>>during the routing convergence?  Is this a concern?
>>>
>>>Alia
>>>
>>>On 10/11/05, *Radia Perlman* <[email-masked] 
>>><mailto:[email-masked]>> wrote:
>>>
>>>    There's nothing an RBridge can do about loops consisting of just
>>>    bridges.
>>>    Which is why it's good to partition the spanning trees 
>>>      
>>>
>>formed by the
>>    
>>
>>>    bridges so that the remaining spanning trees are as small, and
>>>    therefore
>>>    as stable, as possible.
>>>
>>>    RBridges are like routers. They sit at a layer above 
>>>      
>>>
>>bridges. The
>>    
>>
>>>    bridges
>>>    form what looks like a single link to the RBridges. If 
>>>      
>>>
>>there are a
>>    
>>
>>>    bunch
>>>    of bridges connecting a bunch of segments, all the RBridges
>>>    attached to
>>>    that portion of the network see that bridged segment as 
>>>      
>>>
>>a single link.
>>    
>>
>>>    Radia
>>>
>>>    Loa Andersson wrote:
>>>
>>>    >Oh, yes it is true ...
>>>    >
>>>    >but I thought that a trill network could consist of a mixed
>>>    >of rbridges and the type of bridges that exist today, if that
>>>    >is the case you can possibly form the loop over only 
>>>      
>>>
>>non-rbridges
>>    
>>
>>>    >
>>>    >but I'm not up to speed on this, there might be a way to handle
>>>    >this also
>>>    >
>>>    >/Loa
>>>    >
>>>    >Joe Touch wrote:
>>>    >
>>>    >
>>>    >>There is, and that's what it's there for.
>>>    >>
>>>    >>Joe
>>>    >>
>>>    >>Mike Hughes wrote:
>>>    >>
>>>    >>
>>>    >>
>>>    >>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]
>>>    <mailto:[email-masked]>> wrote:
>>>    >>>
>>>    >>>
>>>    >>>
>>>    >>>
>>>    >>>
>>>    >>>>this might be an old discussion, but it is some 
>>>      
>>>
>>time since it
>>    
>>
>>>    >>>>look at it. What do we do in trill networks about transient
>>>    >>>>loops, i.e. if use link state protocols there is a 
>>>      
>>>
>>possibility
>>    
>>
>>>    >>>>that we have transient loops. With no TTL 
>>>      
>>>
>>mechanisms those looping
>>    
>>
>>>    >>>>frames could cause quite a bit of problem.
>>>    >>>>
>>>    >>>>
>>>    >>>Unless I've missed something, or things have changed 
>>>      
>>>
>>overnight,
>>    
>>
>>>    there is a
>>>    >>>TTL provided in the SHIM header.
>>>    >>>
>>>    >>>Mike
>>>    >>>
>>>    >>>
>>>    
>>>      
>>>
>>>>>-----------------------------------------------------------
>>>>>          
>>>>>
>>-------------
>>    
>>
>>>    >>>
>>>    >>>[email-masked] <mailto:[email-masked]>
>>>    [email-masked] <mailto:[email-masked]>
>>>-------------------------------------------------------------
>>>      
>>>
>>----------
>>    
>>
>>>-
>>>
>>>[email-masked]
>>[email-masked]
>[email-masked]

Date: Tue, 11 Oct 2005 12:05:08 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1626

If there is a loop, then packets whether they are unicast or multicast, 
will be delivered multiple
times, within the limit of the TTL.

Radia

Larry Kreeger (kreeger) wrote:

>OK, I can see how a TTL will stop loops, and would prevent duplicate
>known unicasts from being delivered, but how does a TTL stop
>broadcast/multicast/unknown unicast frames from being duplicated to edge
>ports each time the frame comes round the loop?  Or is this considered
>OK behavior in an RBridge network compared to an 802.1 bridged network?
>
>New to all this...  - Larry  
>
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Joe Touch
>Sent: Tuesday, October 11, 2005 7:07 AM
>Subject: Re: [rbridge] loops in trill networks
>
>There is, and that's what it's there for.
>
>Joe
>
>Mike Hughes wrote:
>  
>
>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>
>>
>>    
>>
>>>this might be an old discussion, but it is some time since it look at 
>>>it. What do we do in trill networks about transient loops, i.e. if use
>>>      
>>>
>
>  
>
>>>link state protocols there is a possibility that we have transient 
>>>loops. With no TTL mechanisms those looping frames could cause quite a
>>>      
>>>
>
>  
>
>>>bit of problem.
>>>      
>>>
>>Unless I've missed something, or things have changed overnight, there 
>>is a TTL provided in the SHIM header.
>>
>>Mike
>>    
>>
>[email-masked]

From: "Gray, Eric" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Tue, 11 Oct 2005 16:02:40 -0300
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 9792

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5CE96.5A5318FE
Content-Type: text/plain;
	charset="iso-8859-1"

Alia/Radia,
 
    Frame (re)ordering was a critical consideration back in the days of
specifying LAN Emulation over ATM.  There were - at that time - a few
protocols, used for example in synchronizing sales or accounting data,
that assumed in-order frame delivery. I'm not sure, but I think NetBios
may have been one of those protocols.
 
    I do not know similar protocols no longer exist and, short of under-
taking a major research project to verify that no such protocols do exist,
I believe we should assume that in-order frame delivery may still be a
requirement.
 
    In terms of critiqueing protocols in general for their (in)ability to
deal
with (re)ordering, there is an inefficiency inherent in assuming that all
protocols at all levels can handle re-ordering.  Many protocols designed
to run over an essentially wire-like media assume things can't jump over
each other on the wire.
 
    However, it's probably reasonable - at this point in technology usage -
to define protocols that are optimized for _somewhat_ order independent
frame delivery, relying on the fact that a majority of higher level
protocols
currently in use can deal with some frame re-ordering.
 
    BTW, I believe it's reasonably well-known that IP doesn't deal perfectly
with re-ordering either because there's a cost associated with having to
do so and IP - itself - is optimized for the assumption of in-order
delivery.
 
--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Alia Atlas
Sent: Tuesday, October 11, 2005 2:18 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

On 10/11/05, Radia Perlman < [email-masked]
<mailto:[email-masked]> > wrote: 

I'm not sure what protocols there are that need absolute ordering
guarantees.

Likewise, but I thought that Ethernet had that constraint. 

RSTP can reorder sometimes after a topology change, so apparently
occasional reordering is not considered a problem. 

It might be useful to have a small amount of text about that.

All the IETF protocols, I believe, are designed to withstand some packet
reordering (and should, in my opinion, any well designed protocol). 

Sure - anything on top of IP isn't an issue.  My concern was other stuff.

Alia 

Radia

Alia Atlas wrote:

> What about potential frame reordering
> during the routing convergence?  Is this a concern?
>
> Alia

------_=_NextPart_001_01C5CE96.5A5318FE
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 6.00.2800.1515" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2>Alia/Radia,</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=513592818-11102005>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>Frame (re)ordering was a critical consideration back in the 
days of</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2>specifying LAN Emulation over ATM.&nbsp; There were - at that time - a 
few</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2>protocols, used for example in synchronizing sales or accounting 
data,</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>that 
assumed in-order frame delivery. I'm not sure, but I think 
NetBios</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>may 
have been one of those protocols.</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=513592818-11102005>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>I do not know&nbsp;similar protocols&nbsp;no longer 
exist&nbsp;and,&nbsp;short of under-</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>taking 
</FONT></SPAN><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2>a major research project to verify that no such protocols do 
exist,</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>I 
believe we should assume that in-order frame delivery may still be 
a</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2>requirement.</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=513592818-11102005>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>In terms of critiqueing protocols in general for their 
(in)ability to deal</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>with 
(re)ordering, there is an inefficiency inherent in assuming that 
all</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2>protocols at all levels can handle re-ordering.&nbsp; Many protocols 
designed</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>to run 
over an essentially wire-like media assume things can't jump 
over</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>each 
other on the wire.</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=513592818-11102005>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>However, it's probably&nbsp;reasonable - at this point in 
technology usage -</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>to 
define protocols that are optimized for _somewhat_ order 
independent</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>frame 
delivery, relying on the fact that&nbsp;a majority of higher level 
protocols</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2>currently in use can deal with some frame 
re-ordering.</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=513592818-11102005>&nbsp;&nbsp;&nbsp; <FONT face=Arial 
color=#0000ff size=2>BTW, I believe it's reasonably well-known that IP doesn't 
deal perfectly</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>with 
re-ordering either because there's a cost associated with having 
to</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff size=2>do so 
and IP - itself - is optimized for the assumption of in-order 
delivery.</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2>--</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2>Eric</FONT></SPAN></DIV>
<DIV><SPAN class=513592818-11102005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [email-masked] 
  [mailto:[email-masked]]<B>On Behalf Of </B>Alia 
  Atlas<BR><B>Sent:</B> Tuesday, October 11, 2005 2:18 PM<BR><B>To:</B> 
  Developing a hybrid router/bridge.<BR><B>Subject:</B> Re: [rbridge] loops in 
  trill networks<BR><BR></FONT></DIV>On 10/11/05, <B 
  class=gmail_sendername>Radia Perlman</B> &lt;<A 
  href="mailto:[email-masked]">[email-masked]</A>&gt; wrote:
  <DIV><SPAN class=gmail_quote></SPAN>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">I'm 
    not sure what protocols there are that need absolute 
  ordering<BR>guarantees.</BLOCKQUOTE>
  <DIV><BR>Likewise, but I thought that Ethernet had that constraint. 
  <BR></DIV><BR>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">RSTP 
    can reorder sometimes after a topology change, so apparently<BR>occasional 
    reordering is not considered a problem. </BLOCKQUOTE>
  <DIV><BR>It might be useful to have a small amount of text about 
  that.<BR></DIV><BR>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">All 
    the IETF protocols, I believe, are designed to withstand some 
    packet<BR>reordering (and should, in my opinion, any well designed 
    protocol). </BLOCKQUOTE>
  <DIV><BR>Sure - anything on top of IP isn't an issue.&nbsp; My concern was 
  other stuff.<BR><BR>Alia <BR></DIV><BR>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Radia<BR><BR>Alia 
    Atlas wrote:<BR><BR>&gt; What about potential frame reordering<BR>&gt; 
    during the routing convergence?&nbsp;&nbsp;Is this a 
    concern?<BR>&gt;<BR>&gt; Alia</BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C5CE96.5A5318FE--

Date: Tue, 11 Oct 2005 12:02:37 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] rbridge Digest, Vol 17, Issue 5
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2953

I was actually talking with Joe about a good name for that table.
There is the forwarding table, which maps egress RBridge to next hop.
There is the link state database, which talks about connectivity between 
RBridges.
Then there's what I'd call the endnode table (and Joe is calling the 
egress table), which
maps endnode membership to egress RBridge.

It would be nice to have an agreed-upon name for it that everyone will 
know what is
being referred to. I don't care about names.

But back to your question...why can't IS-IS advertise those addresses in 
link state packets?
Yes, it is the obvious choice in the absence of VLANs, because in that 
case, all the RBridges
would need to know about all the endnodes.

If there are lots of VLANs, then if an RBridge is not attached to VLAN A 
(none of its ports source
or sink packets for VLAN A, though they can be used as transit links for 
VLAN A packets), it does
not need to know where the VLAN A endnodes are located. Only the ingress 
RBridge (which would
be connected to a port on VLAN A) would look up the mapping from endnode 
to egress RBridge,
and stick the egress RBridge in the shim header.

So...how should VLAN A endnode membership be passed around? There are 
various choices:
a) in one instance of IS-IS, along with the RBridge topology information
b) have an instance of IS-IS per VLAN, just for passing around the 
endnode information for that VLAN.
This would be a fairly trivial subset of IS-IS, because there is no 
forwarding of link state information.
The VLAN A instance of IS-IS would use the VLAN A broadcast domain 
created by the main
IS-IS instance, to have each RBridge in VLAN A announce its directly 
attached VLAN A endnodes
c) have some other protocol, simpler than IS-IS (because link state 
information never needs to be forwarded),
that just sends out endnode information.

I believe the IS-IS people preferred multiple instances of IS-IS, one 
per VLAN.

The advantage of not putting this information into the main instance is 
that if R is not attached to VLAN A,
it will not need to store this information. In either case, R would not 
need to look at it, but if it's
one instance, R needs to store it for the reliable link state flooding. 
If it's a VLAN A instance layered
over, then R will be forwarding this endnode reachability information, 
but just as datagrams.

This was discussed a couple of months ago. I'm not sure anyone had 
strong opinions about it, but hopefully
people understand the issue. And hopefully somewhere in there I answered 
your question.

Radia

> I have been following the discussion on and off recently, and am still 
> catching up. This is the first time I heard about egress table. Is it 
> the L2 address to egress Rbridge mapping? If yes, why do we need 
> another protocol to exchange those? I thought IS-IS was chosen because 
> it is easy to advertise those L2 addresses using its link state packet?
>
> Thanks.
>
>  
>

Content-class: urn:content-classes:message
Date: Tue, 11 Oct 2005 12:00:59 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2717

OK, it looks like I asked my previous question prematurely.

If I understand this response correctly, since an RBridge looks like a
single link to the 802.1 bridges, this implies that an RBridge receiving
a BPDU will flood the BPDU to all edge ports.

Now back to the previous message I sent about loops and TTL.  I think
this means that during an RBridge topology change, these BPDUs could get
duplicated as they loop around (before TTL expires).

How kindly will 802.1 bridges react to receiving duplicate BPDUs?

 - Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Tuesday, October 11, 2005 9:44 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

There's nothing an RBridge can do about loops consisting of just
bridges.
Which is why it's good to partition the spanning trees formed by the
bridges so that the remaining spanning trees are as small, and therefore
as stable, as possible.

RBridges are like routers. They sit at a layer above bridges. The
bridges form what looks like a single link to the RBridges. If there are
a bunch of bridges connecting a bunch of segments, all the RBridges
attached to that portion of the network see that bridged segment as a
single link.

Radia

Loa Andersson wrote:

>Oh, yes it is true ...
>
>but I thought that a trill network could consist of a mixed of rbridges

>and the type of bridges that exist today, if that is the case you can 
>possibly form the loop over only non-rbridges
>
>but I'm not up to speed on this, there might be a way to handle this 
>also
>
>/Loa
>
>Joe Touch wrote:
>  
>
>>There is, and that's what it's there for.
>>
>>Joe
>>
>>Mike Hughes wrote:
>>
>>    
>>
>>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>this might be an old discussion, but it is some time since it look 
>>>>at it. What do we do in trill networks about transient loops, i.e. 
>>>>if use link state protocols there is a possibility that we have 
>>>>transient loops. With no TTL mechanisms those looping frames could 
>>>>cause quite a bit of problem.
>>>>        
>>>>
>>>Unless I've missed something, or things have changed overnight, there

>>>is a TTL provided in the SHIM header.
>>>
>>>Mike
>>>
>>>
>>>---------------------------------------------------------------------
>>>---
>>>
>>>[email-masked]

[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 11 Oct 2005 11:52:25 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2041

This brings up another question.

What does the RBridge network look like to the 802.1 bridged network.
Does the RBridge network pretend it is a giant 802.1D bridge -
exchanging BPDUs at its edge ports with the 802.1 bridges and blocking
edge ports if it detects a loop?  What happens to the BPDUs sent by
802.1 bridges to the RBridges?

 - Larry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Touch
Sent: Tuesday, October 11, 2005 8:26 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

Loa Andersson wrote:
> Oh, yes it is true ...
> 
> but I thought that a trill network could consist of a mixed of 
> rbridges and the type of bridges that exist today, if that is the case

> you can possibly form the loop over only non-rbridges

The conventional bridges have a spanning tree, which is what already
prevents such loops currently.

Think of the path between two nodes (hosts, routers, etc. - anything
that sources/sinks L2 frames) as having three components (at most):

node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node

the ingress (bridgepath1) and egress (bridgepath2) conventional bridge
paths use spanning trees, so they can't have loops.

The rbridge uses the TTL, so it can't have a loop at its layer. Even
when it tunnels over conventional bridges ('inside' the rbridge, in a
sense), those can't have loops because they're spanning-tree.

The combination of spanning tree in all bridge paths and TTL in the
rbridge logical path prevents loops in the node-node path.

Joe
[email-masked]

Content-class: urn:content-classes:message
Date: Tue, 11 Oct 2005 11:49:19 -0700
From: "Larry Kreeger \(kreeger\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1203

OK, I can see how a TTL will stop loops, and would prevent duplicate
known unicasts from being delivered, but how does a TTL stop
broadcast/multicast/unknown unicast frames from being duplicated to edge
ports each time the frame comes round the loop?  Or is this considered
OK behavior in an RBridge network compared to an 802.1 bridged network?

New to all this...  - Larry  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Touch
Sent: Tuesday, October 11, 2005 7:07 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

There is, and that's what it's there for.

Joe

Mike Hughes wrote:
> --On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
> 
> 
>>this might be an old discussion, but it is some time since it look at 
>>it. What do we do in trill networks about transient loops, i.e. if use

>>link state protocols there is a possibility that we have transient 
>>loops. With no TTL mechanisms those looping frames could cause quite a

>>bit of problem.
> 
> 
> Unless I've missed something, or things have changed overnight, there 
> is a TTL provided in the SHIM header.
> 
> Mike

Content-class: urn:content-classes:message
Date: Tue, 11 Oct 2005 11:48:43 -0700
From: "Michael Smith \(michsmit\)" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4073

How about packet duplication ?  With unknown unicasts packets following
the spanning tree, there is the potential for unicast packets to be
duplicated and multiple copies received by the destination with or
without TTL.   I don't believe current routing introduces packet
duplication for unicast packets.  I'm not sure how non-IP protocols
would behave in this case.

Michael

> From: [email-masked] 
> 
> I'm not sure what protocols there are that need absolute 
> ordering guarantees.
> RSTP can reorder sometimes after a topology change, so 
> apparently occasional reordering is not considered a problem.
> All the IETF protocols, I believe, are designed to withstand 
> some packet reordering (and should, in my opinion, any well 
> designed protocol).
> 
> Radia
> 
> Alia Atlas wrote:
> 
> > What about potential frame reordering
> > during the routing convergence?  Is this a concern?
> >
> > Alia
> >
> > On 10/11/05, *Radia Perlman* <[email-masked] 
> > <mailto:[email-masked]>> wrote:
> >
> >     There's nothing an RBridge can do about loops consisting of just
> >     bridges.
> >     Which is why it's good to partition the spanning trees 
> formed by the
> >     bridges so that the remaining spanning trees are as small, and
> >     therefore
> >     as stable, as possible.
> >
> >     RBridges are like routers. They sit at a layer above 
> bridges. The
> >     bridges
> >     form what looks like a single link to the RBridges. If 
> there are a
> >     bunch
> >     of bridges connecting a bunch of segments, all the RBridges
> >     attached to
> >     that portion of the network see that bridged segment as 
> a single link.
> >
> >     Radia
> >
> >     Loa Andersson wrote:
> >
> >     >Oh, yes it is true ...
> >     >
> >     >but I thought that a trill network could consist of a mixed
> >     >of rbridges and the type of bridges that exist today, if that
> >     >is the case you can possibly form the loop over only 
> non-rbridges
> >     >
> >     >but I'm not up to speed on this, there might be a way to handle
> >     >this also
> >     >
> >     >/Loa
> >     >
> >     >Joe Touch wrote:
> >     >
> >     >
> >     >>There is, and that's what it's there for.
> >     >>
> >     >>Joe
> >     >>
> >     >>Mike Hughes wrote:
> >     >>
> >     >>
> >     >>
> >     >>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]
> >     <mailto:[email-masked]>> wrote:
> >     >>>
> >     >>>
> >     >>>
> >     >>>
> >     >>>
> >     >>>>this might be an old discussion, but it is some 
> time since it
> >     >>>>look at it. What do we do in trill networks about transient
> >     >>>>loops, i.e. if use link state protocols there is a 
> possibility
> >     >>>>that we have transient loops. With no TTL 
> mechanisms those looping
> >     >>>>frames could cause quite a bit of problem.
> >     >>>>
> >     >>>>
> >     >>>Unless I've missed something, or things have changed 
> overnight,
> >     there is a
> >     >>>TTL provided in the SHIM header.
> >     >>>
> >     >>>Mike
> >     >>>
> >     >>>
> >     
> >>>-----------------------------------------------------------
> -------------
> >     >>>
> >     >>>[email-masked] <mailto:[email-masked]>
> >     [email-masked] <mailto:[email-masked]>
> >-------------------------------------------------------------
> ----------
> >-
> >
> >[email-masked]
> [email-masked]

Date: Tue, 11 Oct 2005 14:35:26 -0400
From: Stephen Suryaputra <[email-masked]>
To: [email-masked]
Subject: Re: [rbridge] rbridge Digest, Vol 17, Issue 5
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3455

------=_Part_2383_28051594.1129055726256
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/8/05, [email-masked] <[email-masked]> wrote:
> Joe Touch wrote:

[ deleted ]

As to the above,, here's a clarified version:
>
> There are three kinds of L2 devices in an rbridge:
>
> hosts: anything that sources/sinks L2 packets
> e.g., RFC1122-style hosts, RFC1812-style routers
> (routers act like hosts to L2)
>
> bridges: transit conventional L2 packets and source/sink/transit
> spanning tree messages
>
> rbridges: encapsulate/decapsulate L2 packets with shim/L2 hdrs
> exchange routing via IS-IS,
> exchange egress tables via some protocol (TBD)

I have been following the discussion on and off recently, and am still
catching up. This is the first time I heard about egress table. Is it the L=
2
address to egress Rbridge mapping? If yes, why do we need another protocol
to exchange those? I thought IS-IS was chosen because it is easy to
advertise those L2 addresses using its link state packet?

Thanks.

------=_Part_2383_28051594.1129055726256
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><div><span class=3D"gmail_quote">On 10/8/05, <b class=3D"gmail_senderna=
me"><a href=3D"mailto:[email-masked]">[email-masked]=
g</a></b> &lt;<a href=3D"mailto:[email-masked]">rbridge-request=
@postel.org
</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-lef=
t: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1=
ex;">Joe Touch wrote:</blockquote><div><br>
[ deleted ] <br>
</div><br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As to the above,,=
 here's a clarified version:<br><br>There are three kinds of L2 devices in =
an rbridge:
<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;hosts: anything tha=
t sources/sinks L2 packets<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e.g.,
RFC1122-style hosts, RFC1812-style routers<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(routers=
 act like hosts to L2)<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;bridges: transit conventional L2 packets and source/sink/transit<br>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;spanning tree messages<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rbridges: encapsulate/decap=
sulate L2 packets with shim/L2 hdrs<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;exchange routin=
g via IS-IS,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;exchange
egress tables via some protocol (TBD)</blockquote><br></div>I have been
following the discussion on and off recently, and am still catching up.
This is the first time I heard about egress table. Is it the L2 address
to egress Rbridge mapping? If yes, why do we need another protocol to
exchange those? I thought IS-IS was chosen because it is easy to
advertise those L2 addresses using its link state packet?<br>
<br>
Thanks.<br>
<br>

------=_Part_2383_28051594.1129055726256--

Date: Tue, 11 Oct 2005 11:17:48 -0700
From: Alia Atlas <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2729

------=_Part_27477_4853447.1129054668756
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/11/05, Radia Perlman <[email-masked]> wrote:
>
> I'm not sure what protocols there are that need absolute ordering
> guarantees.

Likewise, but I thought that Ethernet had that constraint.

RSTP can reorder sometimes after a topology change, so apparently
> occasional reordering is not considered a problem.

It might be useful to have a small amount of text about that.

All the IETF protocols, I believe, are designed to withstand some packet
> reordering (and should, in my opinion, any well designed protocol).

Sure - anything on top of IP isn't an issue. My concern was other stuff.

Alia

Radia
>
> Alia Atlas wrote:
>
> > What about potential frame reordering
> > during the routing convergence? Is this a concern?
> >
> > Alia

------=_Part_27477_4853447.1129054668756
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/11/05, <b class=3D"gmail_sendername">Radia Perlman</b> &lt;<a href=3D=
"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<div><sp=
an class=3D"gmail_quote"></span><blockquote class=3D"gmail_quote" style=3D"=
border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddi=
ng-left: 1ex;">
I'm not sure what protocols there are that need absolute ordering<br>guaran=
tees.</blockquote><div><br>
Likewise, but I thought that Ethernet had that constraint. <br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">RSTP ca=
n reorder sometimes after a topology change, so apparently<br>occasional re=
ordering is not considered a problem.
</blockquote><div><br>
It might be useful to have a small amount of text about that.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">All the=
 IETF protocols, I believe, are designed to withstand some packet<br>reorde=
ring (and should, in my opinion, any well designed protocol).
</blockquote><div><br>
Sure - anything on top of IP isn't an issue.&nbsp; My concern was other stu=
ff.<br>
<br>
Alia <br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Radia<b=
r><br>Alia Atlas wrote:<br><br>&gt; What about potential frame reordering<b=
r>
&gt; during the routing convergence?&nbsp;&nbsp;Is this a concern?<br>&gt;<=
br>&gt; Alia</blockquote></div><br>

------=_Part_27477_4853447.1129054668756--

Date: Tue, 11 Oct 2005 11:03:01 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3219

I'm not sure what protocols there are that need absolute ordering 
guarantees.
RSTP can reorder sometimes after a topology change, so apparently
occasional reordering is not considered a problem.
All the IETF protocols, I believe, are designed to withstand some packet
reordering (and should, in my opinion, any well designed protocol).

Radia

Alia Atlas wrote:

> What about potential frame reordering
> during the routing convergence?  Is this a concern?
>
> Alia
>
> On 10/11/05, *Radia Perlman* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     There's nothing an RBridge can do about loops consisting of just
>     bridges.
>     Which is why it's good to partition the spanning trees formed by the
>     bridges so that the remaining spanning trees are as small, and
>     therefore
>     as stable, as possible.
>
>     RBridges are like routers. They sit at a layer above bridges. The
>     bridges
>     form what looks like a single link to the RBridges. If there are a
>     bunch
>     of bridges connecting a bunch of segments, all the RBridges
>     attached to
>     that portion of the network see that bridged segment as a single link.
>
>     Radia
>
>     Loa Andersson wrote:
>
>     >Oh, yes it is true ...
>     >
>     >but I thought that a trill network could consist of a mixed
>     >of rbridges and the type of bridges that exist today, if that
>     >is the case you can possibly form the loop over only non-rbridges
>     >
>     >but I'm not up to speed on this, there might be a way to handle
>     >this also
>     >
>     >/Loa
>     >
>     >Joe Touch wrote:
>     >
>     >
>     >>There is, and that's what it's there for.
>     >>
>     >>Joe
>     >>
>     >>Mike Hughes wrote:
>     >>
>     >>
>     >>
>     >>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>>this might be an old discussion, but it is some time since it
>     >>>>look at it. What do we do in trill networks about transient
>     >>>>loops, i.e. if use link state protocols there is a possibility
>     >>>>that we have transient loops. With no TTL mechanisms those looping
>     >>>>frames could cause quite a bit of problem.
>     >>>>
>     >>>>
>     >>>Unless I've missed something, or things have changed overnight,
>     there is a
>     >>>TTL provided in the SHIM header.
>     >>>
>     >>>Mike
>     >>>
>     >>>
>     >>>------------------------------------------------------------------------
>     >>>
>     >>>[email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>------------------------------------------------------------------------
>
>[email-masked]

Date: Tue, 11 Oct 2005 10:41:29 -0700
From: Alia Atlas <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5838

------=_Part_27101_23145533.1129052489164
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

What about potential frame reordering
during the routing convergence? Is this a concern?

Alia

On 10/11/05, Radia Perlman <[email-masked]> wrote:
>
> There's nothing an RBridge can do about loops consisting of just bridges.
> Which is why it's good to partition the spanning trees formed by the
> bridges so that the remaining spanning trees are as small, and therefore
> as stable, as possible.
>
> RBridges are like routers. They sit at a layer above bridges. The bridges
> form what looks like a single link to the RBridges. If there are a bunch
> of bridges connecting a bunch of segments, all the RBridges attached to
> that portion of the network see that bridged segment as a single link.
>
> Radia
>
> Loa Andersson wrote:
>
> >Oh, yes it is true ...
> >
> >but I thought that a trill network could consist of a mixed
> >of rbridges and the type of bridges that exist today, if that
> >is the case you can possibly form the loop over only non-rbridges
> >
> >but I'm not up to speed on this, there might be a way to handle
> >this also
> >
> >/Loa
> >
> >Joe Touch wrote:
> >
> >
> >>There is, and that's what it's there for.
> >>
> >>Joe
> >>
> >>Mike Hughes wrote:
> >>
> >>
> >>
> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>this might be an old discussion, but it is some time since it
> >>>>look at it. What do we do in trill networks about transient
> >>>>loops, i.e. if use link state protocols there is a possibility
> >>>>that we have transient loops. With no TTL mechanisms those looping
> >>>>frames could cause quite a bit of problem.
> >>>>
> >>>>
> >>>Unless I've missed something, or things have changed overnight, there
> is a
> >>>TTL provided in the SHIM header.
> >>>
> >>>Mike
> >>>
> >>>
>
> >>>----------------------------------------------------------------------=
--
> >>>[email-masked]
> [email-masked]

------=_Part_27101_23145533.1129052489164
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

What about potential frame reordering<br>
during the routing convergence?&nbsp; Is this a concern?<br>
<br>
Alia<br><br><div><span class=3D"gmail_quote">On 10/11/05, <b class=3D"gmail=
_sendername">Radia Perlman</b> &lt;<a href=3D"mailto:[email-masked]"=
>[email-masked]</a>&gt; wrote:</span><blockquote class=3D"gmail_quot=
e" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt =
0.8ex; padding-left: 1ex;">
There's nothing an RBridge can do about loops consisting of just bridges.<b=
r>Which is why it's good to partition the spanning trees formed by the<br>b=
ridges so that the remaining spanning trees are as small, and therefore
<br>as stable, as possible.<br><br>RBridges are like routers. They sit at a=
 layer above bridges. The bridges<br>form what looks like a single link to =
the RBridges. If there are a bunch<br>of bridges connecting a bunch of segm=
ents, all the RBridges attached to
<br>that portion of the network see that bridged segment as a single link.<=
br><br>Radia<br><br>Loa Andersson wrote:<br><br>&gt;Oh, yes it is true ...<=
br>&gt;<br>&gt;but I thought that a trill network could consist of a mixed
<br>&gt;of rbridges and the type of bridges that exist today, if that<br>&g=
t;is the case you can possibly form the loop over only non-rbridges<br>&gt;=
<br>&gt;but I'm not up to speed on this, there might be a way to handle
<br>&gt;this also<br>&gt;<br>&gt;/Loa<br>&gt;<br>&gt;Joe Touch wrote:<br>&g=
t;<br>&gt;<br>&gt;&gt;There is, and that's what it's there for.<br>&gt;&gt;=
<br>&gt;&gt;Joe<br>&gt;&gt;<br>&gt;&gt;Mike Hughes wrote:<br>&gt;&gt;<br>
&gt;&gt;<br>&gt;&gt;<br>&gt;&gt;&gt;--On 11 October 2005 15:23 +0200 Loa An=
dersson &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>&gt;&g=
t;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;this might be an old discussion, but it is some time since =
it<br>&gt;&gt;&gt;&gt;look at it. What do we do in trill networks about tra=
nsient<br>&gt;&gt;&gt;&gt;loops, i.e. if use link state protocols there is =
a possibility
<br>&gt;&gt;&gt;&gt;that we have transient loops. With no TTL mechanisms th=
ose looping<br>&gt;&gt;&gt;&gt;frames could cause quite a bit of problem.<b=
r>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;Unless I've missed so=
mething, or things have changed overnight, there is a
<br>&gt;&gt;&gt;TTL provided in the SHIM header.<br>&gt;&gt;&gt;<br>&gt;&gt=
;&gt;Mike<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;------------------=
------------------------------------------------------<br>&gt;&gt;&gt;<br>
&gt;&gt;&gt;_______________________________________________<br>&gt;&gt;&gt;=
rbridge mailing list<br>&gt;&gt;&gt;<a href=3D"mailto:[email-masked]">r=
[email-masked]</a><br>&gt;&gt;&gt;<a href=3D"http://www.postel.org/mailm=
an/listinfo/rbridge">
http://www.postel.org/mailman/listinfo/rbridge</a><br>&gt;&gt;&gt;<br>&gt;&=
gt;&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br><br>____________________________=
___________________<br>rbridge mailing list<br><a href=3D"mailto:rbridge@po=
stel.org">
[email-masked]</a><br><a href=3D"http://www.postel.org/mailman/listinfo=
/rbridge">http://www.postel.org/mailman/listinfo/rbridge</a><br></blockquot=
e></div><br>

------=_Part_27101_23145533.1129052489164--

Date: Tue, 11 Oct 2005 09:44:05 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1794

There's nothing an RBridge can do about loops consisting of just bridges.
Which is why it's good to partition the spanning trees formed by the
bridges so that the remaining spanning trees are as small, and therefore
as stable, as possible.

RBridges are like routers. They sit at a layer above bridges. The bridges
form what looks like a single link to the RBridges. If there are a bunch
of bridges connecting a bunch of segments, all the RBridges attached to
that portion of the network see that bridged segment as a single link.

Radia

Loa Andersson wrote:

>Oh, yes it is true ...
>
>but I thought that a trill network could consist of a mixed
>of rbridges and the type of bridges that exist today, if that
>is the case you can possibly form the loop over only non-rbridges
>
>but I'm not up to speed on this, there might be a way to handle
>this also
>
>/Loa
>
>Joe Touch wrote:
>  
>
>>There is, and that's what it's there for.
>>
>>Joe
>>
>>Mike Hughes wrote:
>>
>>    
>>
>>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>this might be an old discussion, but it is some time since it
>>>>look at it. What do we do in trill networks about transient
>>>>loops, i.e. if use link state protocols there is a possibility
>>>>that we have transient loops. With no TTL mechanisms those looping
>>>>frames could cause quite a bit of problem.
>>>>        
>>>>
>>>Unless I've missed something, or things have changed overnight, there is a
>>>TTL provided in the SHIM header.
>>>
>>>Mike
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>[email-masked]

Date: Tue, 11 Oct 2005 08:26:19 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1309

Loa Andersson wrote:
> Oh, yes it is true ...
> 
> but I thought that a trill network could consist of a mixed
> of rbridges and the type of bridges that exist today, if that
> is the case you can possibly form the loop over only non-rbridges

The conventional bridges have a spanning tree, which is what already
prevents such loops currently.

Think of the path between two nodes (hosts, routers, etc. - anything
that sources/sinks L2 frames) as having three components (at most):

node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node

the ingress (bridgepath1) and egress (bridgepath2) conventional bridge
paths use spanning trees, so they can't have loops.

The rbridge uses the TTL, so it can't have a loop at its layer. Even
when it tunnels over conventional bridges ('inside' the rbridge, in a
sense), those can't have loops because they're spanning-tree.

The combination of spanning tree in all bridge paths and TTL in the
rbridge logical path prevents loops in the node-node path.

Joe

Date: Tue, 11 Oct 2005 16:22:41 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1424

Oh, yes it is true ...

but I thought that a trill network could consist of a mixed
of rbridges and the type of bridges that exist today, if that
is the case you can possibly form the loop over only non-rbridges

but I'm not up to speed on this, there might be a way to handle
this also

/Loa

Joe Touch wrote:
> There is, and that's what it's there for.
> 
> Joe
> 
> Mike Hughes wrote:
> 
>>--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
>>
>>
>>
>>>this might be an old discussion, but it is some time since it
>>>look at it. What do we do in trill networks about transient
>>>loops, i.e. if use link state protocols there is a possibility
>>>that we have transient loops. With no TTL mechanisms those looping
>>>frames could cause quite a bit of problem.
>>
>>
>>Unless I've missed something, or things have changed overnight, there is a
>>TTL provided in the SHIM header.
>>
>>Mike
>>
>>
>>------------------------------------------------------------------------
>>
>>[email-masked]

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Date: Tue, 11 Oct 2005 07:07:07 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1266

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBD47B57C67923AF3281D7201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

There is, and that's what it's there for.

Joe

Mike Hughes wrote:
> --On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:
> 
> 
>>this might be an old discussion, but it is some time since it
>>look at it. What do we do in trill networks about transient
>>loops, i.e. if use link state protocols there is a possibility
>>that we have transient loops. With no TTL mechanisms those looping
>>frames could cause quite a bit of problem.
> 
> 
> Unless I've missed something, or things have changed overnight, there is a
> TTL provided in the SHIM header.
> 
> Mike

--------------enigBD47B57C67923AF3281D7201
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigBD47B57C67923AF3281D7201--

Date: Tue, 11 Oct 2005 14:30:44 +0100
From: Mike Hughes <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 656

--On 11 October 2005 15:23 +0200 Loa Andersson <[email-masked]> wrote:

> this might be an old discussion, but it is some time since it
> look at it. What do we do in trill networks about transient
> loops, i.e. if use link state protocols there is a possibility
> that we have transient loops. With no TTL mechanisms those looping
> frames could cause quite a bit of problem.

Unless I've missed something, or things have changed overnight, there is a
TTL provided in the SHIM header.

Mike
-- 
Mike Hughes     Chief Technical Officer  London Internet Exchange
[email-masked]   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"

Date: Tue, 11 Oct 2005 15:23:09 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] loops in trill networks
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 597

All,

this might be an old discussion, but it is some time since it
look at it. What do we do in trill networks about transient
loops, i.e. if use link state protocols there is a possibility
that we have transient loops. With no TTL mechanisms those looping
frames could cause quite a bit of problem.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Date: Mon, 10 Oct 2005 14:20:48 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Call for agenda items
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1148

Erik Nordmark wrote:
> Joe Touch wrote:
> 
> 
>>Yes. The general plan we discussed at the last meeting started with
>>factoring out the current document into three:
>>
>>	1. problem statement
>>	2. architecture
>>	3. protocol
>>
>>The current doc encompasses most of #1 and #2, but only a little of #3.
>>
>>I expect we will have drafts of the first two by the cutoff (where
>>preliminary versions will be ready for help from contributors in a few
>>days).
>>
>>Question: should these be individual submissions at this time, or issued
>>as WG docs (since they're not listed in the charter, it's hard to see
>>which way to go, though either should be fine).
> 
> 
> It makes sense to keep them as individual and then we can ask the WG for 
> each one of them whether the WG wants to adopt them as the basis for the 
> WG deliverables.

AOK.

Joe

Date: Sun, 09 Oct 2005 15:30:59 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Call for agenda items
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1228

Joe Touch wrote:

> Yes. The general plan we discussed at the last meeting started with
> factoring out the current document into three:
> 
> 	1. problem statement
> 	2. architecture
> 	3. protocol
> 
> The current doc encompasses most of #1 and #2, but only a little of #3.
> 
> I expect we will have drafts of the first two by the cutoff (where
> preliminary versions will be ready for help from contributors in a few
> days).
> 
> Question: should these be individual submissions at this time, or issued
> as WG docs (since they're not listed in the charter, it's hard to see
> which way to go, though either should be fine).

It makes sense to keep them as individual and then we can ask the WG for 
each one of them whether the WG wants to adopt them as the basis for the 
WG deliverables.

To answer Harald's question: there is also a "trill requirements on 
routing protocols" draft in the works.

But if there is additional things of interest (for instance, if the 
IS-IS extensions to support trill like things show up as an I-D), then 
it would be good to know since we should at least have such a thing as a 
FYI on the agenda (even though it would be the ISIS WG that would deal 
with any such extensions.)

   Erik

Date: Fri, 07 Oct 2005 16:44:46 -0700
From: Joe Touch <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Call for agenda items
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1641

Harald Tveit Alvestrand wrote:
> Erik, Joe:
> 
> from one of Joe's messages I get the impression that there is a
> short-term plan for what documents will be written and when they will be
> published.

Yes. The general plan we discussed at the last meeting started with
factoring out the current document into three:

	1. problem statement
	2. architecture
	3. protocol

The current doc encompasses most of #1 and #2, but only a little of #3.

I expect we will have drafts of the first two by the cutoff (where
preliminary versions will be ready for help from contributors in a few
days).

Question: should these be individual submissions at this time, or issued
as WG docs (since they're not listed in the charter, it's hard to see
which way to go, though either should be fine).

Joe

> 
> I assume that you as chair know what they're doing, Erik.
> 
> Perhaps you could keep us updated on that plan, so that you can instead
> call for "any OTHER items"?
> 
>                   Harald
> 
> --On mandag, oktober 03, 2005 07:03:52 -0700 Erik Nordmark
> <[email-masked]> wrote:
> 
>>
>> What drafts and other issues will there be to discuss at Vancouver?
>>
>>    Erik
>>
>> [email-masked]

Date: Fri, 07 Oct 2005 16:43:55 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3465

RBridges are not intended to replace routers. If an organization is 
willing to do the configuration
necessary to partition their intranet into IP subnets, partitioned with 
routers, then they can/should
continue doing so. TRILL is really for more efficient/robust 
interconnection of links within an IP subnet.

Radia

Guillermo Ib??ez wrote:

>Besides the reasons provided by Radia, there is the issue of a single 
>and common IP subnet for the rbridge campus. If several campuses are 
>connected by Rbridges instead of routers, all campuses will share the 
>same IP subnet. This  does not seem a recommendable scenario, specially 
>if different authorities own/manage the different campuses networks. I 
>am not sure we use the term campus with the same meaning as Joe.
>Guillermo
>
>Radia Perlman wrote:
>
>  
>
>>No. I think the wording is correct as is. There aren't explicitly 
>>"internal" and "external" RBridges. What you
>>are proposing would involve telling an RBridge which of its ports are 
>>"external" and which are "internal". At
>>any rate, it's not necessary. In a campus, there might happen to be a 
>>link which is a leaf, but if one were
>>to connect another RBridge to that link, you could grow the campus from 
>>that link.
>>
>>So maybe we aren't disagreeing, since there certainly might be leaf 
>>links. But one could imagine a topology
>>in which there were no leaf links...every link has multiple RBridges and 
>>is used for transit, in addition to
>>possibly having endnodes on it. So trying to think of which links are 
>>termination links would just be confusing.
>>
>>So RBridges do not terminate the campus. A router does, though, since 
>>the RBridges do not see anything
>>happening on the other side of the router.
>>
>>Radia
>>
>>
>>
>>
>>
>>Joe Touch wrote:
>>
>> 
>>
>>    
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>
>>>
>>>Saikat Ray wrote:
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>I am not sure how Joe is defining "campus". The page 3 of the draft says "A
>>>>campus refers to a set of links connected by either RBridges or bridges. In
>>>>other words, the campus is terminated by traditional IP routers." 
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>Yeah - that seems like a bug. It seems like an rbridge campus is a set
>>>of links connecting either bridges or rbridges, terminated by rbridges.
>>>
>>>i.e.,
>>>	rbridges connected to internal bridges or rbridges
>>>	internal bridges connected to internal bridges or rbridges
>>>	all external links connected to rbridges only
>>>		(declare these 'edge' rbridges')
>>>	all nodes (hosts) connected via the external links
>>>
>>>But there don't need to be IP routers per se.
>>>
>>>Joe
>>>-----BEGIN PGP SIGNATURE-----
>>>Version: GnuPG v1.2.4 (MingW32)
>>>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>>
>>>iD8DBQFDRsC1E5f5cImnZrsRAsVhAJ4hMRmZZ1pC4q6uVKfbat4y4dWObgCeIedm
>>>c7AvMwnmVQu4jfUc6hv6nlo=
>>>=wdXB
>>>-----END PGP SIGNATURE-----
>>>[email-masked]
>>[email-masked]
>[email-masked]

Date: Fri, 07 Oct 2005 16:31:04 -0700
From: Joe Touch <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2044

Joe Touch wrote:
> 
> 
> Saikat Ray wrote:
> 
>>>I am not sure how Joe is defining "campus". The page 3 of the draft says "A
>>>campus refers to a set of links connected by either RBridges or bridges. In
>>>other words, the campus is terminated by traditional IP routers." 
> 
> 
> Yeah - that seems like a bug. It seems like an rbridge campus is a set
> of links connecting either bridges or rbridges, terminated by rbridges.
> 
> i.e.,
> 	rbridges connected to internal bridges or rbridges
> 	internal bridges connected to internal bridges or rbridges
> 	all external links connected to rbridges only
> 		(declare these 'edge' rbridges')
> 	all nodes (hosts) connected via the external links
> 
> But there don't need to be IP routers per se.
> 
> Joe

FWIW, I did clarify this with Radia off-line. Rbridges campuses are
terminated at the rbridge, largely because of an IP router or host, but
it is at the rbridge that the termination exists.

As to the above,, here's a clarified version:

There are three kinds of L2 devices in an rbridge:

	hosts: anything that sources/sinks L2 packets
		e.g., RFC1122-style hosts, RFC1812-style routers
		(routers act like hosts to L2)

	bridges: transit conventional L2 packets and source/sink/transit
		spanning tree messages

	rbridges: encapsulate/decapsulate L2 packets with shim/L2 hdrs
		exchange routing via IS-IS,
		exchange egress tables via some protocol (TBD)

host-host and host-rbridge traffic
	may transit bridges
	is conventional L2

	this is known as EXTERNAL TRAFFIC

rbridge-rbridge traffic
	may transit bridges (since it looks like L2 on the outside)
	is shim/L2 encapsulated

	this is known as INTERNAL TRAFFIC

I hope this helps; it's a preview of the architecture doc ;-)

Joe

Date: Fri, 07 Oct 2005 22:38:13 +0200
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2819

Besides the reasons provided by Radia, there is the issue of a single 
and common IP subnet for the rbridge campus. If several campuses are 
connected by Rbridges instead of routers, all campuses will share the 
same IP subnet. This  does not seem a recommendable scenario, specially 
if different authorities own/manage the different campuses networks. I 
am not sure we use the term campus with the same meaning as Joe.
Guillermo

Radia Perlman wrote:

>No. I think the wording is correct as is. There aren't explicitly 
>"internal" and "external" RBridges. What you
>are proposing would involve telling an RBridge which of its ports are 
>"external" and which are "internal". At
>any rate, it's not necessary. In a campus, there might happen to be a 
>link which is a leaf, but if one were
>to connect another RBridge to that link, you could grow the campus from 
>that link.
>
>So maybe we aren't disagreeing, since there certainly might be leaf 
>links. But one could imagine a topology
>in which there were no leaf links...every link has multiple RBridges and 
>is used for transit, in addition to
>possibly having endnodes on it. So trying to think of which links are 
>termination links would just be confusing.
>
>So RBridges do not terminate the campus. A router does, though, since 
>the RBridges do not see anything
>happening on the other side of the router.
>
>Radia
>
>
>
>
>
>Joe Touch wrote:
>
>  
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>
>>
>>Saikat Ray wrote:
>> 
>>
>>    
>>
>>>I am not sure how Joe is defining "campus". The page 3 of the draft says "A
>>>campus refers to a set of links connected by either RBridges or bridges. In
>>>other words, the campus is terminated by traditional IP routers." 
>>>   
>>>
>>>      
>>>
>>Yeah - that seems like a bug. It seems like an rbridge campus is a set
>>of links connecting either bridges or rbridges, terminated by rbridges.
>>
>>i.e.,
>>	rbridges connected to internal bridges or rbridges
>>	internal bridges connected to internal bridges or rbridges
>>	all external links connected to rbridges only
>>		(declare these 'edge' rbridges')
>>	all nodes (hosts) connected via the external links
>>
>>But there don't need to be IP routers per se.
>>
>>Joe
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.2.4 (MingW32)
>>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>>iD8DBQFDRsC1E5f5cImnZrsRAsVhAJ4hMRmZZ1pC4q6uVKfbat4y4dWObgCeIedm
>>c7AvMwnmVQu4jfUc6hv6nlo=
>>=wdXB
>>-----END PGP SIGNATURE-----
>>[email-masked]
>[email-masked]

Date: Fri, 07 Oct 2005 13:06:47 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2113

No. I think the wording is correct as is. There aren't explicitly 
"internal" and "external" RBridges. What you
are proposing would involve telling an RBridge which of its ports are 
"external" and which are "internal". At
any rate, it's not necessary. In a campus, there might happen to be a 
link which is a leaf, but if one were
to connect another RBridge to that link, you could grow the campus from 
that link.

So maybe we aren't disagreeing, since there certainly might be leaf 
links. But one could imagine a topology
in which there were no leaf links...every link has multiple RBridges and 
is used for transit, in addition to
possibly having endnodes on it. So trying to think of which links are 
termination links would just be confusing.

So RBridges do not terminate the campus. A router does, though, since 
the RBridges do not see anything
happening on the other side of the router.

Radia

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Saikat Ray wrote:
>  
>
>>I am not sure how Joe is defining "campus". The page 3 of the draft says "A
>>campus refers to a set of links connected by either RBridges or bridges. In
>>other words, the campus is terminated by traditional IP routers." 
>>    
>>
>
>Yeah - that seems like a bug. It seems like an rbridge campus is a set
>of links connecting either bridges or rbridges, terminated by rbridges.
>
>i.e.,
>	rbridges connected to internal bridges or rbridges
>	internal bridges connected to internal bridges or rbridges
>	all external links connected to rbridges only
>		(declare these 'edge' rbridges')
>	all nodes (hosts) connected via the external links
>
>But there don't need to be IP routers per se.
>
>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDRsC1E5f5cImnZrsRAsVhAJ4hMRmZZ1pC4q6uVKfbat4y4dWObgCeIedm
>c7AvMwnmVQu4jfUc6hv6nlo=
>=wdXB
>-----END PGP SIGNATURE-----
>[email-masked]

Date: Fri, 07 Oct 2005 11:49:10 -0700
From: Radia Perlman <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] FW: Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1712

Saikat Ray wrote:

>
>[Saikat] Okay. Is this "RBridge election" process similar to the "designated
>bridge election" process of the standard Ethernet? Of course the designation
>can also be done after RBridges collect all the LSPs.
>
It is the same as the IS-IS "Designated Router" election on a link. 
IS-IS already has an election to determine
exactly one router to be what it calls "Designated Router". The IS-IS DR 
is the one that names the link,
advertises membership of the link, etc. This is exactly the same thing 
happening when IS-IS is running
with RBridges. One RBridge on the link will be elected.

It is not the same as the "designated bridge election" in the spanning 
tree. That's based on which bridge
is closest to the Root bridge, with ID of bridge breaking ties. And 
that's for a different purpose than IS-IS
Designated Router election. The IS-IS thing is totally local to a link, 
i.e., factors outside the link will
not determine who is elected...it is only a function of IDs and 
priorities of the routers on the link. In contrast,
the DB thing depends on outside things...if the location of the Root 
bridge changes, a different bridge will
become DB.

>
>
>W is the only RBridge on that link that listens to unencapsulated 
>packets, and the only one that decapsulates
>packets when forwarding onto that link.
>
>
>[Saikat] $X$ will however use the "link" for connectivity reasons (sending
>encapsulated packets), right?
>

Correct. X will still use the link for forwarding encapsulated packets.

So I think we understand each other now (assuming I was coherent in the 
explanation of  how "Designated
Bridge" selection differs from "Designated Router" election in IS-IS).

Radia

Date: Fri, 07 Oct 2005 11:38:45 -0700
From: Joe Touch <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 995

Saikat Ray wrote:
> I am not sure how Joe is defining "campus". The page 3 of the draft says "A
> campus refers to a set of links connected by either RBridges or bridges. In
> other words, the campus is terminated by traditional IP routers." 

Yeah - that seems like a bug. It seems like an rbridge campus is a set
of links connecting either bridges or rbridges, terminated by rbridges.

i.e.,
	rbridges connected to internal bridges or rbridges
	internal bridges connected to internal bridges or rbridges
	all external links connected to rbridges only
		(declare these 'edge' rbridges')
	all nodes (hosts) connected via the external links

But there don't need to be IP routers per se.

Joe

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 7 Oct 2005 14:07:19 -0400
Organization: University of Pennsylvania
Subject: [rbridge] FW: Discovering endnodes directly connected to an RBridge
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4517

Previously sent to the wrong address: courtesy outlook :(

-----Original Message-----
From: Saikat Ray [mailto:[email-masked]] 
Sent: Friday, October 07, 2005 2:04 PM
To: 'Radia Perlman'
Subject: RE: [rbridge] Discovering endnodes directly connected to an RBridge

I think I need a picture, but I think the question is what happens if 
there are two RBridges, W and X,
connected to the same link.

[Saikat] Yes, that was precisely the question.

If that's the question, then the answer is that only one of them gets 
elected "Designated RBridge", say W. Then W
is the only one that learns endnode information (from listening to 
unencapsulated packets, whether they
be data packets or ARP/ND replies). W announces the endnodes on that 
link in W's link state information.

[Saikat] Okay. Is this "RBridge election" process similar to the "designated
bridge election" process of the standard Ethernet? Of course the designation
can also be done after RBridges collect all the LSPs.

W is the only RBridge on that link that listens to unencapsulated 
packets, and the only one that decapsulates
packets when forwarding onto that link.

[Saikat] $X$ will however use the "link" for connectivity reasons (sending
encapsulated packets), right?

I'm confused about the "separate campuses" comment. If you connect 
RBridges, they'll all form one campus.
The only way to make it separate campuses is to partition them and only 
connect them through routers.

[Saikat] I also do not quite follow how Joe defines a "campus".

Radia

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Saikat Ray wrote:
>  
>
>>>>>Thanks for your answers. You have properly understood the question.
>>>>>However, I still have some doubts. Suppose a legacy bridge is connected
>>>>>to (perhaps through a LAN segment) two RBridges. To use my example: the
>>>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
>>>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
>>>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to
the
>>>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
>>>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
>>>>>and $X$ receives this packet. Then isn't it the case that both $W$ and
>>>>>$X$ will think that the new endnode $A$ is "directly" connected to
>>>>>itself?
>>>>>          
>>>>>
>>>>Yes. Which is why both will forward packets addressed to $A$ they
>>>>receive via other ports to the port they each have that attaches to the
>>>>legacy bridge $Z$, which ought to push that traffic - regardless of how
>>>>received - directly toward endnode $A$.
>>>>
>>>>I don't see the problem yet.
>>>>        
>>>>
>>>Two questions come to my mind:
>>>
>>>- Which node ends up in the routing tables of the other RBridges?
>>>      
>>>
>>All external nodes potentially end up in the edge encapsulation tables.
>>Only the egress nodes within a particular rbridge campus will end up in
>>the edge and interior IS-IS routing tables, however, since only
>>encapsulated packets need be forwarded.
>>
>>
>>[Saikat] $X$ and $W$ are individual RBridge Devices. I think the question
>>was that in this example both $X$ and $W$ will advertise "direct
>>connectivity" to endnode $A$ to the rest of the RBridges. Then if some
other
>>RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$)
will
>>it send the packet to?
>>
>>Could you also kindly answer the next question assuming that $X$ and $W$
are
>>individual RBridge Devices?
>>    
>>
>
>I did:
>
>	if they're in different campuses, there's no conflict
>
>	if they're in the same campus, the external bridge $A$ is
>	effectively connected twice to the same rbridge campus;
>	this is out of spec.
>
>I'm not sure how existing bridges handle this; I would expect that the
>spanning tree ought to pick only one of those ports, i.e., there would
>never be a case where any traffic would flow from $A$ to one of $X$ or
>$Y$, at which point only one of ($X$,$Y$) would advertize any node
>connected to $A$ anyway.
>
>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDRqi+E5f5cImnZrsRAm3jAKDoHTx2dj/hyUTh1VcBPMXkLScYgwCglOqC
>+NhyO76PXRZqIXW6x6P9q7U=
>=tG3e
>-----END PGP SIGNATURE-----
>[email-masked]

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 7 Oct 2005 13:54:12 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5292

I am not sure how Joe is defining "campus". The page 3 of the draft says "A
campus refers to a set of links connected by either RBridges or bridges. In
other words, the campus is terminated by traditional IP routers." The way I
interpret it: if a connected set of links is "campus A" and another set of
connected links (disjoint from the previous set) is "campus B", then the
only way from sending packets from an endnode in "campus A" to an endnode in
"campus B" is through an IP router. Am I misunderstanding something? If my
interpretation is correct, then I do not understand what is meant by "a
campus behaves like a single bridge"...

By the way, in my example, $A$ was an endnode, not an Rbridge or a Bridge.

Radia Perlman wrote:
> I think I need a picture, but I think the question is what happens if 
> there are two RBridges, W and X,
> connected to the same link.
> 
> If that's the question, then the answer is that only one of them gets 
> elected "Designated RBridge", say W. 

I.e., the rbridge campus connects to A via only one link, as per
spanning tree rules (on the outside, a campus behaves like a single bridge).

> Then W
> is the only one that learns endnode information (from listening to 
> unencapsulated packets, whether they
> be data packets or ARP/ND replies). W announces the endnodes on that 
> link in W's link state information.
> 
> W is the only RBridge on that link that listens to unencapsulated 
> packets, and the only one that decapsulates
> packets when forwarding onto that link.
> 
> I'm confused about the "separate campuses" comment. If you connect 
> RBridges, they'll all form one campus.
> The only way to make it separate campuses is to partition them and only 
> connect them through routers.

I am presuming that rbridges know which campus they belong to. Which
means we can deploy two sets of rbridges in separate campuses that are
either directly connected or connected via bridges.

We don't need a router to connect them. Or shouldn't, IMO. Is there some
reason that's a desirable property?

Joe

> 
> Radia
> 
> Joe Touch wrote:
> 
> 
> 
> 
> Saikat Ray wrote:
>  
> 
> 
>>>>>Thanks for your answers. You have properly understood the question.
>>>>>However, I still have some doubts. Suppose a legacy bridge is connected
>>>>>to (perhaps through a LAN segment) two RBridges. To use my example: the
>>>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
>>>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
>>>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to
the
>>>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
>>>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
>>>>>and $X$ receives this packet. Then isn't it the case that both $W$ and
>>>>>$X$ will think that the new endnode $A$ is "directly" connected to
>>>>>itself?
>>>>>         
>>>>>
>>>>
>>>>Yes. Which is why both will forward packets addressed to $A$ they
>>>>receive via other ports to the port they each have that attaches to the
>>>>legacy bridge $Z$, which ought to push that traffic - regardless of how
>>>>received - directly toward endnode $A$.
>>>>
>>>>I don't see the problem yet.
>>>>       
>>>>
> 
>>>Two questions come to my mind:
> 
>>>- Which node ends up in the routing tables of the other RBridges?
>>>     
> 
> 
>>All external nodes potentially end up in the edge encapsulation tables.
>>Only the egress nodes within a particular rbridge campus will end up in
>>the edge and interior IS-IS routing tables, however, since only
>>encapsulated packets need be forwarded.
> 
> 
>>[Saikat] $X$ and $W$ are individual RBridge Devices. I think the question
>>was that in this example both $X$ and $W$ will advertise "direct
>>connectivity" to endnode $A$ to the rest of the RBridges. Then if some
other
>>RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$)
will
>>it send the packet to?
> 
>>Could you also kindly answer the next question assuming that $X$ and $W$
are
>>individual RBridge Devices?
> 
> 
> 
> I did:
> 
> 	if they're in different campuses, there's no conflict
> 
> 	if they're in the same campus, the external bridge $A$ is
> 	effectively connected twice to the same rbridge campus;
> 	this is out of spec.
> 
> I'm not sure how existing bridges handle this; I would expect that the
> spanning tree ought to pick only one of those ports, i.e., there would
> never be a case where any traffic would flow from $A$ to one of $X$ or
> $Y$, at which point only one of ($X$,$Y$) would advertize any node
> connected to $A$ anyway.
> 
> Joe
[email-masked]

> [email-masked]
[email-masked]

Date: Fri, 07 Oct 2005 10:30:48 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4488

Radia Perlman wrote:
> I think I need a picture, but I think the question is what happens if 
> there are two RBridges, W and X,
> connected to the same link.
> 
> If that's the question, then the answer is that only one of them gets 
> elected "Designated RBridge", say W. 

I.e., the rbridge campus connects to A via only one link, as per
spanning tree rules (on the outside, a campus behaves like a single bridge).

> Then W
> is the only one that learns endnode information (from listening to 
> unencapsulated packets, whether they
> be data packets or ARP/ND replies). W announces the endnodes on that 
> link in W's link state information.
> 
> W is the only RBridge on that link that listens to unencapsulated 
> packets, and the only one that decapsulates
> packets when forwarding onto that link.
> 
> I'm confused about the "separate campuses" comment. If you connect 
> RBridges, they'll all form one campus.
> The only way to make it separate campuses is to partition them and only 
> connect them through routers.

I am presuming that rbridges know which campus they belong to. Which
means we can deploy two sets of rbridges in separate campuses that are
either directly connected or connected via bridges.

We don't need a router to connect them. Or shouldn't, IMO. Is there some
reason that's a desirable property?

Joe

> 
> Radia
> 
> Joe Touch wrote:
> 
> 
> 
> 
> Saikat Ray wrote:
>  
> 
> 
>>>>>Thanks for your answers. You have properly understood the question.
>>>>>However, I still have some doubts. Suppose a legacy bridge is connected
>>>>>to (perhaps through a LAN segment) two RBridges. To use my example: the
>>>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
>>>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
>>>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the
>>>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
>>>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
>>>>>and $X$ receives this packet. Then isn't it the case that both $W$ and
>>>>>$X$ will think that the new endnode $A$ is "directly" connected to
>>>>>itself?
>>>>>         
>>>>>
>>>>
>>>>Yes. Which is why both will forward packets addressed to $A$ they
>>>>receive via other ports to the port they each have that attaches to the
>>>>legacy bridge $Z$, which ought to push that traffic - regardless of how
>>>>received - directly toward endnode $A$.
>>>>
>>>>I don't see the problem yet.
>>>>       
>>>>
> 
>>>Two questions come to my mind:
> 
>>>- Which node ends up in the routing tables of the other RBridges?
>>>     
> 
> 
>>All external nodes potentially end up in the edge encapsulation tables.
>>Only the egress nodes within a particular rbridge campus will end up in
>>the edge and interior IS-IS routing tables, however, since only
>>encapsulated packets need be forwarded.
> 
> 
>>[Saikat] $X$ and $W$ are individual RBridge Devices. I think the question
>>was that in this example both $X$ and $W$ will advertise "direct
>>connectivity" to endnode $A$ to the rest of the RBridges. Then if some other
>>RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$) will
>>it send the packet to?
> 
>>Could you also kindly answer the next question assuming that $X$ and $W$ are
>>individual RBridge Devices?
> 
> 
> 
> I did:
> 
> 	if they're in different campuses, there's no conflict
> 
> 	if they're in the same campus, the external bridge $A$ is
> 	effectively connected twice to the same rbridge campus;
> 	this is out of spec.
> 
> I'm not sure how existing bridges handle this; I would expect that the
> spanning tree ought to pick only one of those ports, i.e., there would
> never be a case where any traffic would flow from $A$ to one of $X$ or
> $Y$, at which point only one of ($X$,$Y$) would advertize any node
> connected to $A$ anyway.
> 
> Joe
[email-masked]

> [email-masked]

Date: Fri, 07 Oct 2005 10:16:57 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3811

I think I need a picture, but I think the question is what happens if 
there are two RBridges, W and X,
connected to the same link.

If that's the question, then the answer is that only one of them gets 
elected "Designated RBridge", say W. Then W
is the only one that learns endnode information (from listening to 
unencapsulated packets, whether they
be data packets or ARP/ND replies). W announces the endnodes on that 
link in W's link state information.

W is the only RBridge on that link that listens to unencapsulated 
packets, and the only one that decapsulates
packets when forwarding onto that link.

I'm confused about the "separate campuses" comment. If you connect 
RBridges, they'll all form one campus.
The only way to make it separate campuses is to partition them and only 
connect them through routers.

Radia

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Saikat Ray wrote:
>  
>
>>>>>Thanks for your answers. You have properly understood the question.
>>>>>However, I still have some doubts. Suppose a legacy bridge is connected
>>>>>to (perhaps through a LAN segment) two RBridges. To use my example: the
>>>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
>>>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
>>>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the
>>>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
>>>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
>>>>>and $X$ receives this packet. Then isn't it the case that both $W$ and
>>>>>$X$ will think that the new endnode $A$ is "directly" connected to
>>>>>itself?
>>>>>          
>>>>>
>>>>Yes. Which is why both will forward packets addressed to $A$ they
>>>>receive via other ports to the port they each have that attaches to the
>>>>legacy bridge $Z$, which ought to push that traffic - regardless of how
>>>>received - directly toward endnode $A$.
>>>>
>>>>I don't see the problem yet.
>>>>        
>>>>
>>>Two questions come to my mind:
>>>
>>>- Which node ends up in the routing tables of the other RBridges?
>>>      
>>>
>>All external nodes potentially end up in the edge encapsulation tables.
>>Only the egress nodes within a particular rbridge campus will end up in
>>the edge and interior IS-IS routing tables, however, since only
>>encapsulated packets need be forwarded.
>>
>>
>>[Saikat] $X$ and $W$ are individual RBridge Devices. I think the question
>>was that in this example both $X$ and $W$ will advertise "direct
>>connectivity" to endnode $A$ to the rest of the RBridges. Then if some other
>>RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$) will
>>it send the packet to?
>>
>>Could you also kindly answer the next question assuming that $X$ and $W$ are
>>individual RBridge Devices?
>>    
>>
>
>I did:
>
>	if they're in different campuses, there's no conflict
>
>	if they're in the same campus, the external bridge $A$ is
>	effectively connected twice to the same rbridge campus;
>	this is out of spec.
>
>I'm not sure how existing bridges handle this; I would expect that the
>spanning tree ought to pick only one of those ports, i.e., there would
>never be a case where any traffic would flow from $A$ to one of $X$ or
>$Y$, at which point only one of ($X$,$Y$) would advertize any node
>connected to $A$ anyway.
>
>Joe
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDRqi+E5f5cImnZrsRAm3jAKDoHTx2dj/hyUTh1VcBPMXkLScYgwCglOqC
>+NhyO76PXRZqIXW6x6P9q7U=
>=tG3e
>-----END PGP SIGNATURE-----
>[email-masked]

Date: Fri, 07 Oct 2005 09:56:31 -0700
From: Joe Touch <[email-masked]>
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2713

Saikat Ray wrote:
>>>>Thanks for your answers. You have properly understood the question.
>>>>However, I still have some doubts. Suppose a legacy bridge is connected
>>>>to (perhaps through a LAN segment) two RBridges. To use my example: the
>>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
>>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
>>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the
>>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
>>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
>>>>and $X$ receives this packet. Then isn't it the case that both $W$ and
>>>>$X$ will think that the new endnode $A$ is "directly" connected to
>>>>itself?
>>>
>>>Yes. Which is why both will forward packets addressed to $A$ they
>>>receive via other ports to the port they each have that attaches to the
>>>legacy bridge $Z$, which ought to push that traffic - regardless of how
>>>received - directly toward endnode $A$.
>>>
>>>I don't see the problem yet.
>>
>>
>>Two questions come to my mind:
>>
>>- Which node ends up in the routing tables of the other RBridges?
> 
> 
> All external nodes potentially end up in the edge encapsulation tables.
> Only the egress nodes within a particular rbridge campus will end up in
> the edge and interior IS-IS routing tables, however, since only
> encapsulated packets need be forwarded.
> 
> 
> [Saikat] $X$ and $W$ are individual RBridge Devices. I think the question
> was that in this example both $X$ and $W$ will advertise "direct
> connectivity" to endnode $A$ to the rest of the RBridges. Then if some other
> RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$) will
> it send the packet to?
> 
> Could you also kindly answer the next question assuming that $X$ and $W$ are
> individual RBridge Devices?

I did:

	if they're in different campuses, there's no conflict

	if they're in the same campus, the external bridge $A$ is
	effectively connected twice to the same rbridge campus;
	this is out of spec.

I'm not sure how existing bridges handle this; I would expect that the
spanning tree ought to pick only one of those ports, i.e., there would
never be a case where any traffic would flow from $A$ to one of $X$ or
$Y$, at which point only one of ($X$,$Y$) would advertize any node
connected to $A$ anyway.

Joe

From: "Saikat Ray" <[email-masked]>
To: "'Developing a hybrid router/bridge.'" <[email-masked]>
Date: Fri, 7 Oct 2005 12:35:48 -0400
Organization: University of Pennsylvania
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3015

>>>Thanks for your answers. You have properly understood the question.
>>>However, I still have some doubts. Suppose a legacy bridge is connected
>>>to (perhaps through a LAN segment) two RBridges. To use my example: the
>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the
>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
>>>and $X$ receives this packet. Then isn't it the case that both $W$ and
>>>$X$ will think that the new endnode $A$ is "directly" connected to
>>>itself?
>>
>>Yes. Which is why both will forward packets addressed to $A$ they
>>receive via other ports to the port they each have that attaches to the
>>legacy bridge $Z$, which ought to push that traffic - regardless of how
>>received - directly toward endnode $A$.
>>
>>I don't see the problem yet.
> 
> 
> Two questions come to my mind:
> 
> - Which node ends up in the routing tables of the other RBridges?

All external nodes potentially end up in the edge encapsulation tables.
Only the egress nodes within a particular rbridge campus will end up in
the edge and interior IS-IS routing tables, however, since only
encapsulated packets need be forwarded.

[Saikat] $X$ and $W$ are individual RBridge Devices. I think the question
was that in this example both $X$ and $W$ will advertise "direct
connectivity" to endnode $A$ to the rest of the RBridges. Then if some other
RBridge wants to send a packet to node $A$, which RBridge ($X$ or $W$) will
it send the packet to?

Could you also kindly answer the next question assuming that $X$ and $W$ are
individual RBridge Devices?

> - Once the route is announced, will $X$ and $W$ believe the route or their

> directly acquired knowledge? And for how long?

I'm not sure whether $X$ and $W$ represent individual rbridge devices or
rbridge campuses. Up to this point in the thread, I had assumed
campuses, or devices on different campuses.

If they're on the same campus, what you have is what amounts to a loop
(remember - an rbridge campus acts like a single bridge to the outside
world). In that case, you have a misconfigured ethernet, since you're
connecting two bridges with two links.

Joe

> (the first may be totally obvious to people who understand IS-IS....)
> 
> 
> 
> 
> 
> [email-masked]
[email-masked]

Date: Fri, 07 Oct 2005 09:16:13 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2629

Harald Tveit Alvestrand wrote:
> 
> --On torsdag, oktober 06, 2005 20:23:18 -0700 Joe Touch <[email-masked]> 
> wrote:
> 
> 
>>>Thanks for your answers. You have properly understood the question.
>>>However, I still have some doubts. Suppose a legacy bridge is connected
>>>to (perhaps through a LAN segment) two RBridges. To use my example: the
>>>legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
>>>that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
>>>Now suppose a new endnode, $A$, joins a LAN segment connected only to the
>>>legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
>>>bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
>>>and $X$ receives this packet. Then isn't it the case that both $W$ and
>>>$X$ will think that the new endnode $A$ is "directly" connected to
>>>itself?
>>
>>Yes. Which is why both will forward packets addressed to $A$ they
>>receive via other ports to the port they each have that attaches to the
>>legacy bridge $Z$, which ought to push that traffic - regardless of how
>>received - directly toward endnode $A$.
>>
>>I don't see the problem yet.
> 
> 
> Two questions come to my mind:
> 
> - Which node ends up in the routing tables of the other RBridges?

All external nodes potentially end up in the edge encapsulation tables.
Only the egress nodes within a particular rbridge campus will end up in
the edge and interior IS-IS routing tables, however, since only
encapsulated packets need be forwarded.

> - Once the route is announced, will $X$ and $W$ believe the route or their 
> directly acquired knowledge? And for how long?

I'm not sure whether $X$ and $W$ represent individual rbridge devices or
rbridge campuses. Up to this point in the thread, I had assumed
campuses, or devices on different campuses.

If they're on the same campus, what you have is what amounts to a loop
(remember - an rbridge campus acts like a single bridge to the outside
world). In that case, you have a misconfigured ethernet, since you're
connecting two bridges with two links.

Joe

> (the first may be totally obvious to people who understand IS-IS....)
> 
> 
> 
> 
> 
> [email-masked]

Date: Fri, 07 Oct 2005 11:02:36 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1424

--On torsdag, oktober 06, 2005 20:23:18 -0700 Joe Touch <[email-masked]> 
wrote:

>> Thanks for your answers. You have properly understood the question.
>> However, I still have some doubts. Suppose a legacy bridge is connected
>> to (perhaps through a LAN segment) two RBridges. To use my example: the
>> legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
>> that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
>> Now suppose a new endnode, $A$, joins a LAN segment connected only to the
>> legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
>> bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
>> and $X$ receives this packet. Then isn't it the case that both $W$ and
>> $X$ will think that the new endnode $A$ is "directly" connected to
>> itself?
>
> Yes. Which is why both will forward packets addressed to $A$ they
> receive via other ports to the port they each have that attaches to the
> legacy bridge $Z$, which ought to push that traffic - regardless of how
> received - directly toward endnode $A$.
>
> I don't see the problem yet.

Two questions come to my mind:

- Which node ends up in the routing tables of the other RBridges?
- Once the route is announced, will $X$ and $W$ believe the route or their 
directly acquired knowledge? And for how long?

(the first may be totally obvious to people who understand IS-IS....)

Date: Fri, 07 Oct 2005 10:55:40 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Call for agenda items
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 677

Erik, Joe:

from one of Joe's messages I get the impression that there is a short-term 
plan for what documents will be written and when they will be published.

I assume that you as chair know what they're doing, Erik.

Perhaps you could keep us updated on that plan, so that you can instead 
call for "any OTHER items"?

                   Harald

--On mandag, oktober 03, 2005 07:03:52 -0700 Erik Nordmark 
<[email-masked]> wrote:

>
> What drafts and other issues will there be to discuss at Vancouver?
>
>    Erik
>
> [email-masked]

Date: Thu, 06 Oct 2005 20:23:18 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 4269

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7FBA0523FB498A3A0197C848
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Saikat Ray wrote:
> (I am hoping that this post will go into the proper thread. I apologize
> in advance if it starts a new thread.)
> 
> Thanks for your answers. You have properly understood the question.
> However, I still have some doubts. Suppose a legacy bridge is connected to
> (perhaps through a LAN segment) two RBridges. To use my example: the
> legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
> that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
> Now suppose a new endnode, $A$, joins a LAN segment connected only to the
> legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
> bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
> and $X$ receives this packet. Then isn't it the case that both $W$ and $X$
> will think that the new endnode $A$ is "directly" connected to itself?

Yes. Which is why both will forward packets addressed to $A$ they
receive via other ports to the port they each have that attaches to the
legacy bridge $Z$, which ought to push that traffic - regardless of how
received - directly toward endnode $A$.

I don't see the problem yet.

Joe

> 
> 
> On Thu, 6 Oct 2005, Radia Perlman wrote:
> 
> 
>>A legacy bridge would not remove the encapsulation header.
>>
>>If there are two RBridges, only one is allowed to encapsulate from, and
>>decapsulate onto, that link.
>>
>>So therefore if an RBridge sees a packet without an encapsulation
>>header, and that RBridge is the
>>Designated RBridge, then it knows the packet came from an endnode.
>>
>>If the packet came from an endnode but was forwarded by a legacy bridge
>>before reaching the first RBridge,
>>that's OK. It's the same as coming directly from the endnode. A "link"
>>to an RBridge is a bunch of
>>Ethernet segments connected by legacy bridges.
>>
>>Hopefully I understood your question. If not, please re-ask.
>>
>>Radia
>>
>>
>>
>>Saikat Ray wrote:
>>
>>
>>>Hi All,
>>>
>>>I am confused over a basic (probably a trivial) problem described below. I
>>>would much appreciate if someone can answer.
>>>
>>>Thanks in advance.
>>>
>>>Saikat
>>>
>>>%%%%%%%%%%%%%%%%%%%
>>>
>>>In the RBridge draft, page 4, it is written that "Once an RBridge learns
>>>the location of a directly attached endnode, it informs the other RBridges
>>>in its link state information." But how does an RBridge learn which
>>>endnodes are directly connected to it using only promiscuous listening?
>>>Suppose there is a LAN segment $Y$, such as a hub, connected to port $p$
>>>of an RBridge $X$. Also assume that there is one another legacy bridge,
>>>$Z$, connected to the LAN segment $Y$. The port of the legacy bridge $Z$
>>>that connects it to the LAN segment $Y$ is in forwarding state, hence the
>>>bridge $Z$ sends packets onto the LAN segment $Y$. Thus, the RBridge $X$
>>>receives two types of packets on port $p$: (i) packets that are sent by
>>>the endnodes that are directly connected to the LAN segment $Y$, and (ii)
>>>packets that are forwarded by bridge $Z$ on LAN segment $Y$. Then how does
>>>the RBridge $X$ distinguish between these two types of packets?
>>>[email-masked]
>>[email-masked]
> [email-masked]

--------------enig7FBA0523FB498A3A0197C848
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7FBA0523FB498A3A0197C848--

Date: Thu, 6 Oct 2005 20:51:16 -0400 (EDT)
From: Saikat Ray <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3073

(I am hoping that this post will go into the proper thread. I apologize
in advance if it starts a new thread.)

Thanks for your answers. You have properly understood the question.
However, I still have some doubts. Suppose a legacy bridge is connected to
(perhaps through a LAN segment) two RBridges. To use my example: the
legacy bridge $Z$ is connected to RBridges $X$ and $W$. Both the ports
that connect $Z$ to $X$ and $W$, respectively, are in forwarding state.
Now suppose a new endnode, $A$, joins a LAN segment connected only to the
legacy bridge $Z$, and the endnode sends out an ARP query. The legacy
bridge $Z$ forwards this query to both its ports. Thus both RBridge $W$
and $X$ receives this packet. Then isn't it the case that both $W$ and $X$
will think that the new endnode $A$ is "directly" connected to itself?

On Thu, 6 Oct 2005, Radia Perlman wrote:

> A legacy bridge would not remove the encapsulation header.
>
> If there are two RBridges, only one is allowed to encapsulate from, and
> decapsulate onto, that link.
>
> So therefore if an RBridge sees a packet without an encapsulation
> header, and that RBridge is the
> Designated RBridge, then it knows the packet came from an endnode.
>
> If the packet came from an endnode but was forwarded by a legacy bridge
> before reaching the first RBridge,
> that's OK. It's the same as coming directly from the endnode. A "link"
> to an RBridge is a bunch of
> Ethernet segments connected by legacy bridges.
>
> Hopefully I understood your question. If not, please re-ask.
>
> Radia
>
>
>
> Saikat Ray wrote:
>
> >Hi All,
> >
> >I am confused over a basic (probably a trivial) problem described below. I
> >would much appreciate if someone can answer.
> >
> >Thanks in advance.
> >
> >Saikat
> >
> >%%%%%%%%%%%%%%%%%%%
> >
> >In the RBridge draft, page 4, it is written that "Once an RBridge learns
> >the location of a directly attached endnode, it informs the other RBridges
> >in its link state information." But how does an RBridge learn which
> >endnodes are directly connected to it using only promiscuous listening?
> >Suppose there is a LAN segment $Y$, such as a hub, connected to port $p$
> >of an RBridge $X$. Also assume that there is one another legacy bridge,
> >$Z$, connected to the LAN segment $Y$. The port of the legacy bridge $Z$
> >that connects it to the LAN segment $Y$ is in forwarding state, hence the
> >bridge $Z$ sends packets onto the LAN segment $Y$. Thus, the RBridge $X$
> >receives two types of packets on port $p$: (i) packets that are sent by
> >the endnodes that are directly connected to the LAN segment $Y$, and (ii)
> >packets that are forwarded by bridge $Z$ on LAN segment $Y$. Then how does
> >the RBridge $X$ distinguish between these two types of packets?
> >[email-masked]
> [email-masked]

Date: Thu, 06 Oct 2005 17:15:16 -0700
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1963

A legacy bridge would not remove the encapsulation header.

If there are two RBridges, only one is allowed to encapsulate from, and 
decapsulate onto, that link.

So therefore if an RBridge sees a packet without an encapsulation 
header, and that RBridge is the
Designated RBridge, then it knows the packet came from an endnode.

If the packet came from an endnode but was forwarded by a legacy bridge 
before reaching the first RBridge,
that's OK. It's the same as coming directly from the endnode. A "link" 
to an RBridge is a bunch of
Ethernet segments connected by legacy bridges.

Hopefully I understood your question. If not, please re-ask.

Radia

Saikat Ray wrote:

>Hi All,
>
>I am confused over a basic (probably a trivial) problem described below. I
>would much appreciate if someone can answer.
>
>Thanks in advance.
>
>Saikat
>
>%%%%%%%%%%%%%%%%%%%
>
>In the RBridge draft, page 4, it is written that "Once an RBridge learns
>the location of a directly attached endnode, it informs the other RBridges
>in its link state information." But how does an RBridge learn which
>endnodes are directly connected to it using only promiscuous listening?
>Suppose there is a LAN segment $Y$, such as a hub, connected to port $p$
>of an RBridge $X$. Also assume that there is one another legacy bridge,
>$Z$, connected to the LAN segment $Y$. The port of the legacy bridge $Z$
>that connects it to the LAN segment $Y$ is in forwarding state, hence the
>bridge $Z$ sends packets onto the LAN segment $Y$. Thus, the RBridge $X$
>receives two types of packets on port $p$: (i) packets that are sent by
>the endnodes that are directly connected to the LAN segment $Y$, and (ii)
>packets that are forwarded by bridge $Z$ on LAN segment $Y$. Then how does
>the RBridge $X$ distinguish between these two types of packets?
>[email-masked]

Date: Thu, 06 Oct 2005 16:47:29 -0700
From: Joe Touch <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2290

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig34681233A25003A6B9F78DCE
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Saikat Ray wrote:
> Hi All,
> 
> I am confused over a basic (probably a trivial) problem described below. I
> would much appreciate if someone can answer.
> 
> Thanks in advance.
> 
> Saikat
> 
> %%%%%%%%%%%%%%%%%%%
> 
> In the RBridge draft, page 4, it is written that "Once an RBridge learns
> the location of a directly attached endnode, it informs the other RBridges
> in its link state information." But how does an RBridge learn which
> endnodes are directly connected to it using only promiscuous listening?

Looking for source addresses it has not seen yet, e.g, via broadcast ARP
requests.

> Suppose there is a LAN segment $Y$, such as a hub, connected to port $p$
> of an RBridge $X$. Also assume that there is one another legacy bridge,
> $Z$, connected to the LAN segment $Y$. The port of the legacy bridge $Z$
> that connects it to the LAN segment $Y$ is in forwarding state, hence the
> bridge $Z$ sends packets onto the LAN segment $Y$. Thus, the RBridge $X$
> receives two types of packets on port $p$: (i) packets that are sent by
> the endnodes that are directly connected to the LAN segment $Y$, and (ii)
> packets that are forwarded by bridge $Z$ on LAN segment $Y$. Then how does
> the RBridge $X$ distinguish between these two types of packets?

It doesn't care; both are effectively accessible off that egress of the
rbrige campus.

The term 'directly connected' above should probably be replaced with
'connected', since there's no way to distinguish. This will be addressed
in the new version of the doc which is split into separate problem
statement and arch docs.

Joe

--------------enig34681233A25003A6B9F78DCE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig34681233A25003A6B9F78DCE--

Date: Thu, 6 Oct 2005 19:38:17 -0400 (EDT)
From: Saikat Ray <[email-masked]>
To: [email-masked]
Subject: [rbridge] Discovering endnodes directly connected to an RBridge
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1117

Hi All,

I am confused over a basic (probably a trivial) problem described below. I
would much appreciate if someone can answer.

Thanks in advance.

Saikat

%%%%%%%%%%%%%%%%%%%

In the RBridge draft, page 4, it is written that "Once an RBridge learns
the location of a directly attached endnode, it informs the other RBridges
in its link state information." But how does an RBridge learn which
endnodes are directly connected to it using only promiscuous listening?
Suppose there is a LAN segment $Y$, such as a hub, connected to port $p$
of an RBridge $X$. Also assume that there is one another legacy bridge,
$Z$, connected to the LAN segment $Y$. The port of the legacy bridge $Z$
that connects it to the LAN segment $Y$ is in forwarding state, hence the
bridge $Z$ sends packets onto the LAN segment $Y$. Thus, the RBridge $X$
receives two types of packets on port $p$: (i) packets that are sent by
the endnodes that are directly connected to the LAN segment $Y$, and (ii)
packets that are forwarded by bridge $Z$ on LAN segment $Y$. Then how does
the RBridge $X$ distinguish between these two types of packets?

Date: Mon, 03 Oct 2005 07:03:52 -0700
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Call for agenda items
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 79

What drafts and other issues will there be to discuss at Vancouver?

   Erik