Subject: RE: WG Review: Transparent Interconnection of Lots of Links (trill)

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Jun 2005 09:53:26 -0400

Why are we doing this?  Is it IP or is it Frames?
If it is Frames, why is it not 802.1 - etc? 

Sue Hares

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]] 
Sent: Thursday, June 16, 2005 10:00 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links
(trill)

Since the second BOF on this topic was inconclusive regarding community
support, the IESG is reevaluating the community consensus on whether a
WG
should be formed or not.

If you have input on this, positive or negative, please send it to
[email-masked].

-- 
Alex
http://www.psg.com/~zinin

This is a forwarded message
From: The IESG <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wednesday, June 15, 2005, 11:52:27 AM
Subject: WG Review: Transparent Interconnection of Lots of Links (trill)

===8<==============Original message text===============
A new IETF working group has been proposed in the Internet Area. The
IESG has 
not made any determination as yet. The following draft charter was
submitted, 
and is provided for informational purposes only. Please send your
comments to 
the IESG mailing list ([email-masked]) by June 22nd.

+++

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

Current Status: Proposed Working Group

Chair(s):
TBD

Internet Area Director(s):
Mark Townsley <[email-masked]>
Margaret Wasserman <[email-masked]>

Internet Area Advisor:
Mark Townsley <[email-masked]>

Technical Advisor:
Bill Fenner <[email-masked]>

Secretary(ies):
TBD

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: http://www.postel.org/mailman/listinfo/rbridge
Archive: http://www.postel.org/pipermail/rbridge

Description of Working Group:

The TRILL WG will design a solution for shortest-path frame routing in
multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies,
using the link-state routing protocol technology.

This work will initially be based on draft-perlman-rbridge-03.txt.

The design should have the following properties:

- Minimal or no configuration required
- Load-splitting among multiple paths
- Routing loop mitigation (possibly through a TTL field)
- Support of multiple points of attachment
- Support for broadcast and multicast
- No significant service delay after attachment
- No less secure than existing bridged solutions

Any changes introduced to the Ethernet service model should be
analyzed and clearly documented. To ensure compatibility with IEEE
VLANs and the Ethernet service model, the WG will request an IEEE
liaison relationship with IEEE 802.1.

It is not an explicit requirement that the solution should be able to
run on existing IP routers or IEEE 802 switches as a software upgrade.
However, the working group should take deployment considerations into
account, to ensure that the solution can interwork with bridges in a
flexible manner (e.g., to allow incremental deployment into LANs that
currently use 802.1D bridges).

The TRILL working will work with the L2VPN WG and IEEE 802.1 to
develop interworking between TRILL and 802.1D bridges at the edge, such
that a bridged sub-cloud could be attached to TRILL devices in more than
one place for redundancy.

The solution must not interfere with the end-to-end transparency of
the Internet architecture or with end-to-end congestion control and
QOS mechanisms.

The WG will work on the following items:

(1) Develop a problem statement and architecture document that
describes the high-level TRILL architecture, discusses the
scalability of that architecture, describe the threat model
and security impacts of the TRILL solution, and describes the
expected impacts (if any) of the TRILL solution on the Ethernet
service model.

(2) Define the requirements for a TRILL-capable routing protocol, and
select one or more existing routing protocols that could meet
those requirements.

(3) Work with the appropriate Routing area working group to extend an
existing routing protocol to meet the TRILL working group
requirements.

Note: The TRILL working group is not chartered to develop a new
routing protocol or to make substantial modifications to an
existing routing protocol. If, during the requirements definition
and selection phase, the TRILL working group discovers that no
existing routing protocol will meet their needs, we will need to
re-assess the TRILL WG charter to determine how/if this work
should proceed.

(4) Produce a (set of) TRILL specification(s) for standards track
publication that defines what information must be carried in an
encapsulation header for data packets, and determine how to map
that information to various link types (only IEEE 802 links
initially)

The TRILL working group is chartered to undertake all of the above
tasks and may begin work on more than one of these tasks in parallel.
However, the problem statement and architecture document should be
completed before the details of the base protocol are finalized, while
there is still time to consider changes to the architecture without
major impacts on established specifications.

Goals and Milestones:

Aug 05 Accept Problem statement and architecture document as a WG
work item
Aug 05 Accept base protocol specification as a WG document
Oct 05 Accept routing protocol requirements as a WG work item
Dec 05 Submit problem statement and architecture document to the IESG
for publication as an Informational RFC
Mar 06 Submit routing protocol requirements to the IESG for
publication as an Informational RFC
Mar 06 Choose routing protocol(s) that can meet the requirements.
Apr 06 Start work with routing area WG(s) to undertake TRILL extensions.
Sep 06 Base protocol specification submitted to the IESG for
publication as a Proposed Standard RFC
Dec 06 Re-charter or shut down the WG

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

===8<===========End of original message text===========

---

From: Eric W Gray <[email-masked]>
Date: Mon, 20 Jun 2005 13:52:32 -0400

Sue,

    The trouble with obvious questions is that everybody assumes they've 
been  asked already.
Now this question has been asked at least once, for sure.  :-)

    From the charter attached in Alex's previous message, the purpose is 
to "route" Ethernet
Frames. Quote:

Since it is clear that at least some people are not satisfied with the 
802.1 approach (perhaps
because of the relative inefficiency associated with completely unused 
high capacity links), I
assume you mean to ask "why is it not IEEE" - rather than "why is it not 
802.1".

    I believe that is a very good question.  I know of no very good 
reason why the IEEE might
not specify how to use an OSPF-like routing protocol to fulfill the role 
previously handled by
Spanning Tree Protocol. Perhaps the only reason why it is being 
discussed here is that it might
be better - for implementers - if the protocol used was more than 
"OSPF-like."

--
Eric

---

From: Tony Li <[email-masked]>
Date: Mon, 20 Jun 2005 11:20:39 -0700

In other instances, when proposals were IEEE'ish, we were directed to
take them to the IEEE.

Tony

Eric W Gray wrote:
> ------------------------------------------------------------------------
> 
> routing-discussion mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Eric W Gray <[email-masked]>
Date: Mon, 20 Jun 2005 14:44:54 -0400

Tony,

    No disagreement from me.  Perhaps the next obvious question is - has 
anyone taken this to the
IEEE?

--
Eric