[rbridge] Agenda items?

[Radia Perlman]

RBridges wouldn't reorder either, except after a topology change, unless 
people wanted
to path split across multiple paths on an ongoing basis. That would be 
problematic (because
of reordering) even for applications that can tolerate reordering 
because of issues like
a) TCP trying to discover the round-trip delay
b) TCP having to buffer out-of-order messages

However, using multiple paths is still possible if, (as is common with 
today's routers)
care is taken to send all packets for a given flow on the same choice, 
for instance
by doing a hash of addresses and ports to make a selection among 
equivalent paths to D.

Is there some way other than path splitting that you see the RBridge 
proposal reordering
packets within a network with a stable topology?

Radia



Michael Smith wrote:

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