[rbridge] Updated charter

[Joe Touch]

-----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
| rbridge at postel.org
| 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-----