[rbridge] Updated charter

[Erik Nordmark]

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

---