Subject: [rbridge] RBridge/bridge interaction

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 20 Oct 2005 18:07:43 -0300

Radia,

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

--
Eric

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