[From nobody Mon Jun 16 11:13:04 2008
Return-Path: <wwwrun@core3.amsl.com>
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64])
	by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m5GI8HHH013130
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <touch@boreas.isi.edu>; Mon, 16 Jun 2008 11:08:18 -0700 (PDT)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])
	by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m5GI85OV024703
	for <touch@isi.edu>; Mon, 16 Jun 2008 11:08:06 -0700 (PDT)
Received: by core3.amsl.com (Postfix, from userid 30)
	id CCED13A69D3; Mon, 16 Jun 2008 11:07:19 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: touch@ISI.EDU
Cc: Radia.Perlman@sun.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <20080616180719.CCED13A69D3@core3.amsl.com>
Date: Mon, 16 Jun 2008 11:07:19 -0700 (PDT)
X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
Subject: New Version Notification for draft-ietf-trill-prob-03
X-MailScanner-From: wwwrun@core3.amsl.com


A new version of I-D, draft-ietf-trill-prob-03.txt has been successfuly submitted by Joseph Touch and posted to the IETF repository.

Filename:	 draft-ietf-trill-prob
Revision:	 03
Title:		 Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement
Creation_date:	 2008-06-16
WG ID:		 trill
Number_of_pages: 18

Abstract:
Current Ethernet (802.1) link layers use custom routing protocols 
that have a number of challenges. These routing protocols need to 
strictly avoid loops, even temporary loops during route propagation, 
 
 
 because of the lack of header loop detection support. Routing tends 
not to take full advantage of alternate paths, or even non-
overlapping pairwise paths (in the case of spanning trees). The 
convergence of these routing protocols and stability under link 
changes and failures is also of concern. This document addresses 
these concerns and suggests that they are related to the need to be 
able to apply modern network layer routing protocols at the link 
layer. This document assumes that solutions would not address issues 
of scalability beyond that of existing bridged (802.1) links, but 
that a solution would be backward compatible with 802.1, including 
hubs, bridges, and their existing plug-and-play capabilities. 

This document is a work in progress; we invite you to participate on 
the mailing list at http://www.postel.org/rbridge
                                                                                  


The IETF Secretariat.

]