[rbridge] Updated charter

erik.nordmark at sun.com (Erik Nordmark) Thu, 27 January 2005 17:52 UTC

From: "erik.nordmark at sun.com"
Date: Thu, 27 Jan 2005 17:52:37 +0000
Subject: [rbridge] Updated charter
Message-ID: <41F99A4C.1020701@sun.com>
X-Date: Thu Jan 27 17:52:37 2005

Based on the feedback from the BoF in August and some preliminary 
feedback from IESG/IAB members, I've edited the charter.

There are additions about supporting clouds which contain different L2 
technologies (something folks asked about at the BoF, but we didn't talk 
about) and we can have technical discussions about that on the list.

There is also some more flushing out of details.

And editorial changes to make the description more positive.

Hopefully this can be used to get a BoF and start the WG chartering 
discussion.

    Erik


-------------- next part --------------
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
 - ARP and Neighbor Discovery packets should be optimized and not necessarily
   be flooded everywhere
 - 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)

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.

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 should support both IPv4 and IPv6

The working group will not work any layer 3 aspects except to provide
 - Optimizations so that ARP and ND packets are not always
   flooded everywhere
 - Being able to carry IP multicast packets using flooding (which will
   presumably fall out by being able to flood L2 multicast packets, so there
   might not be any specific work needed here).
 - Defining the L3 operations needed to interconnect different L2 technologies

The work consists of several, separable pieces:
 - Defining what information should be carried in routing protocols in order
   to support this concept. The encoding of this information within the
   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.
 - 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

---