Subject: WG Review: Ransparent Interconnection of Lots of Links (trill)

From: The IESG <[email-masked]>
Date: Fri, 11 Feb 2005 10:15:39 -0500

A new IETF working group has been proposed in the Internet Area. The IESG has not 
made any determination as yet.  The following description was submitted, 
and is provided for informational purposes only. Please send your comments 
to the IESG mailing list ([email-masked]) by February 16th.

+++

Ransparent Interconnection of Lots of Links (trill)
===================================================

Current Status: Proposed Working Group 

Description of Working Group:

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.

The TRILL WG will coordinate with the L2VPN WG, as appropriate, to
make sure that issues common to both groups (such as ND and ARP
forwarding) are solved in a coordinated way.

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 

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce