[rbridge] updated BOF website

[touch at ISI.EDU (Joe Touch)]

Hi, all,

The Rbridge / IPVLX BOF website has been updated with the current
proposed charter (1/27/2005).

www.postel.org/rbridge

Joe
From touch at ISI.EDU  Thu Feb  3 09:25:58 2005
From: touch at ISI.EDU (Joe Touch)
Date: Thu Feb  3 09:25:57 2005
Subject: [rbridge] Updated charter
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Posted to www.postel.org/rbridge

Once we lock on a name, I'll add that to the website...

Joe
- --


Erik Nordmark wrote:
|
| I generated an update because Margaret asked for one. As part of doing
| that I've tried to capture something about what has been discussed on
| the list.
|
| Next step is to figure out an agenda for Minneapolis.
|
|    Erik
|
|
| [Note: name change from IPVLX to TRILL]
|
| TRansparent Interconnection of Lots of Links (TRILL)
|
|
| While IEEE 802 bridges are attractive due to not needing explicit
| configuration and allowing hosts to move within the bridged topology,
| they are more limited than IP routers since bridges
| only support IEEE 802 technologies, and the most common layer 2
| interconnection method (dynamically created spanning tree
| formation using bridges) is not as flexible and robust as layer 3 routing.
|
| The WG will design a hybrid solution that combines the simplicity of
| configuration while taking full advantage of complex topologies.
|
| The design should have the following properties:
|  - zero configuration of the hybrid devices
|  - ability for hosts to move without changing their IP address
|  - it should be possible to forward packets using pair-wise shortest
paths,
|    and exploit the redundant paths through the network for increased
|    aggregate bandwidth
|  - possible optimizations for ARP and Neighbor Discovery packets
| (potentially
|    avoid flooding all the time)
|  - support Secure Neighbor Discovery
|  - the packet header should have a hop count for robustness in the
presence
|    of temporary routing loops
|  - nodes should be able to have multiple attachments to the network
|  - no delay when a new node is attached to the network
|  - multicast should work (and after a re-charter it might make sense to
|    look at optimizations for IP multicast)
|  - be no less secure than existing bridges (and explore whether the
| protocol
|    can make "L2 address theft" harder or easier to detect)
|
| A required piece of the solution is an IP routing protocol which is
| extended
| to carry L2 address reachability, handle broadcast, and is friendly to
| zero-configuration. Likely candidate are the link-state routing protocols
| since they can easily be extended to provide for broadcast, which is
| believed
| to be difficult for distance vector protocols.
| This working group will define the requirements on such routing
| protocol(s),
| and select the routing protocol(s) to be used.  The intent is that the
| actual
| extensions to the routing protocol(s) be performed in the WGs with
| expertise
| in the routing protocol(s).
|
| The working group will look into solutions that can interconnect different
| layer 2 technologies, and also look at providing support for non-IP
| protocols,
| even though one can not combine those two features together; the
| interconnection of different layer 2 technologies (with different layer 2
| address formats) will most likely only work for the IP family of
protocols.
| Whether the same or different address formats are used, there might be a
| need
| to handle different MTUs.
|
| The WG will design a protocol that combines the benefits of bridges
| and routers in a way that will co-exist with existing hosts, IP routers
| and bridges. The design must support both IPv4 and IPv6
|
| The working group will not work any layer 3 aspects except to provide
|  - Possible optimizations for ARP and ND packets (not always
|    flooded everywhere)
|  - Being able to carry IP broadcast and multicast packets (which might
just
|    fall out from supporting L2 multicast)
|  - Defining the L3 operations needed to interconnect different L2
| technologies
|
|
| The work consists of several, separable pieces:
|  - Defining the requirement on the routing protocol(s), and select one or
|    more routing protocols. The detailed specification of the extensions to
|    a particular routing protocol will be left as an action item for the
|    specific routing protocol WG.
|  - Defining what information must be carried in an encapsulation
header for
|    data packets, and how to map that information to various link types
| (e.g.,
|    IEEE LAN, Fibrechannel, MPLS)
|  - Defining how address resolution (ARP and Neighbor Discovery) is
| performed,
|    taking into account the desire to be compatible with Secure Neighbor
|    Discovery.
|  - Defining how the solution extends to the case when multiple layer 2
|    technologies, that have different address format/length, are
| interconnected.
|
| Deliverables
|  - A short draft on the problem statement and goals
|  - A document defining what information needs to be carried in routing
|    protocols to support the rbridge concept, and other requirements on
|    the routing protocols.
|  - Encapsulation draft specifying what needs to be carried in general
|    and the specific format to use on IEEE LANs
|  - ARP and ND draft
|  - Draft on interconnecting different types of layer 2 technologies
|  - Threat analysis document
|
| Goals and Milestones
|
| Jun 05  Problem statement and Goals submitted to IESG for Informational
| Sep 05  Routing protocol support requirements to IESG for Informational
| Dec 05  Encapsulation document to IESG for Proposed Standard
| Sep 05  ARP & ND to IESG for Proposed Standard
| Mar 06  Interconnecting Layer 2 Technologies document to IESG for
|         Proposed Standard
| Dec 05  Threat analysis to IESG for Informational
|
| ---
|
| _______________________________________________
| rbridge mailing list
| [e-mail]
| http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCAl6mE5f5cImnZrsRAktPAKD988gLmW4jP0EY+Qc8SOCJBHlV/QCg9BqH
F28k49z2KZrv7B7Gg9i3pgY=
=FRcU
-----END PGP SIGNATURE-----
From michsmit at cisco.com  Thu Feb  3 14:32:12 2005
From: michsmit at cisco.com (Michael Smith)
Date: Thu Feb  3 14:32:53 2005
Subject: [rbridge] Agenda items?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>

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: [e-mail] 
> [mailto:[e-mail]] 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
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
From alper.yegin at samsung.com  Thu Feb  3 15:01:47 2005
From: alper.yegin at samsung.com (Alper Yegin)
Date: Thu Feb  3 15:03:06 2005
Subject: [rbridge] Agenda items?
In-Reply-To: <[e-mail]>
Message-ID: <072501c50a44$57ba7ae0$[e-mail]>


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?

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

Thank you.

Alper





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