[rbridge] Agenda items?

[Michael Smith]

> From: Alper Yegin [mailto:alper.yegin at samsung.com] 
> 
> I have some clarification questions...
> 
> > I think an important issue to discuss is packet reordering.  The
> current
> > rbridge proposal introduces a significant possibility of L2 packet 
> > reordering within a network with a stable topology.
> 
> What aspect of rbridge would cause this?

Someone please correct me if I'm mistaken.  My understanding of the proposal
is that packets sent to an unknown L2 destination will be treated as
broadcast and sent along the single spanning tree.  Once the destination is
known, packets will follow the shortest path which may or may not be the
same as the spanning tree path.  Packets in transit via the spanning tree
may quite easily be passed by subsequent packets following the shortest
path, hence the reordering.

> 
> > IEEE bridges do not
> > reorder packets except in some corner cases with the new rapid
> spanning
> > tree
> > protocol and even then, it is only during a network topology change.
> The
> > traditional spanning tree protocol (non-rapid spanning 
> tree) provides
> no
> > packet reordering even during topology change.  Since rbridges are 
> > targeted to support non-IP protocols, this issue should be 
> addressed.
> 
> Is this increased reordering probability going to break 
> anything? Or, are you just identifying something that may 
> impact IP+ layer performance?

If I recall correctly, SNA has serious problems with reordering.  I did some
quick googling and apparently so do Netware, and DecNet.

For example, check the last couple of paragraphs in the following article:
http://www.telecommagazine.com/default.asp?journalid=3&func=departments&page
=0409t05&year=2004&month=9

Michael

> 
> Thank you.
> 
> Alper
> 
> 
> 
> 
> 
> > 
> > Michael
> > 
> > > -----Original Message-----
> > > From: rbridge-bounces at postel.org
> > > [mailto:rbridge-bounces at postel.org] On Behalf Of Erik Nordmark
> > > Sent: Wednesday, February 02, 2005 6:19 PM
> > > To: Developing a hybrid router/bridge.
> > > Subject: [rbridge] Agenda items?
> > >
> > >
> > > It is time to start thinking about the agenda for the 
> BoF/WG meeting 
> > > in Minneapolis.
> > >
> > > Presumably we should go over the charter, but I'd like to 
> also spend 
> > > time on technical discussions, which is the subject of this email.
> > >
> > > I think there are several technical items that makes sense to 
> > > discuss, and I've tried to capture things from memory here.
> > > If you had additional items let me know we can add them (but you 
> > > might get volunteered :-).
> > > If you need stimulation it might make sense to re-read 
> > > draft-perlman-rbridge, and see if there are issues that come to
> mind.
> > >
> > > What I'd like for each of these items is to have a volunteer who 
> > > will present the topic with the issues and the tradeoffs (but no 
> > > "solutions"), so that we all can try to understand the different 
> > > issues, and how they might interact.
> > >
> > > I'd like to see each topic be presented in advance (so that folks 
> > > can read about it) either as a concise email to the list 
> (which we 
> > > can reference using URLs to the archive) or in the form 
> of a short 
> > > internet draft.
> > >
> > > Here are the topics I have so far:
> > > 1. What is the desired semantics of the cloud of hybrids?
> > > Just "strict IEEE
> > >     802 bridge equivalence", "IP works", or something in between?
> > >
> > >     I'll volunteer myself to lead the discussion on this topic.
> > >
> > > 2. Threats and security considerations
> > >     What should the goal be? What can we do better?
> > >
> > >     Does anybody who brought this up on the list want to 
> volunteer?
> > >
> > > 3. Requirements on routing protocols
> > >      For zero configuration
> > >      Carrying MAC addresses
> > >      Broadcast
> > >      IS-IS vs. OSPF vs. something else
> > >
> > >     Volunteer? I can dig out the discussion I had with 
> Bob Hinden if
> > >     that would stimulate someone to want to discuss this.
> > >
> > > 4. Connecting different L2 types (with different L2 
> address formats)
> > >
> > >     I think I've convinced Radia to lead this one
> > >
> > > 5. Choices for ARP/ND
> > >
> > >     We had some discussion on the list about this and how 
> it relates 
> > > to
> > >     intentionally duplicate L2 addresses, mobility, etc.
> > >
> > >     Any volunteers?
> > >
> > > 6. Choices for broadcast/multicast
> > >
> > >     Any volunteers?
> > >
> > > What am I missing?
> > >
> > >
> > >     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