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

From: Alex Zinin <[email-masked]>
Date: Thu, 16 Jun 2005 19:00:25 -0700

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===========

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Jun 2005 15:03:22 -0400

Eric: 

So I need more explanation - because your statement does not match with
my experience. 

A multiple company alliance (Wi-Mesh alliance)  I'm working with
proposed a

hybrid link-state and hybrid On-demand/DV (ADOV hybrid) for IEEE 802.11s
for wireless Mesh.

I guess I don't understand your last comment.  The hybrid protocols (one
link state, one on-demand/proactive 

(a variant of ADOV)) are passing MAC addresses and dealing with Wireless
Mesh Points. 

802.1 inter-working is defined for these protocols that will map
link-state 802.11 to bridge functions (802.3 or 

Multiple 802.11 networks).   This inter-working can connect to the
Layer-2 spanning tree that Layer 3 may run over. 

I don't find the contributors to 802.1 to lack the ability to suggest
novel solutions or 

Link state solutions for networks supported by 802.11 or 802.1.     I've
proposed FRAME TRILL solutions to

IEEE for a sub-group.  So, what I see is that I must submit solutions to
both IEEE and IETF over the same work area. 

Am I confused?  How are we advancing the work of running code? 

Sue

  _____  

From: Eric W Gray [mailto:[email-masked]] 
Sent: Monday, June 20, 2005 1:53 PM
To: Susan Hares
Cc: Alex Zinin; [email-masked]; [email-masked];
[email-masked]
Subject: Re: WG Review: Transparent Interconnection of Lots of Links
(trill)

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

[email-masked] wrote: 

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.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Jun 2005 11:57:51 -0400

I believe the expertise for link-state protocols is in the routing area.

Sue Hares

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Margaret
Wasserman
Sent: Tuesday, June 21, 2005 8:55 AM
To: Tony Li; Alex Zinin; [email-masked]; [email-masked];
[email-masked]; Susan Hares
Subject: Fwd: Re: WG Review: Transparent Interconnection of Lots of
Links (trill)

Hi All,

Erik forwarded this message to me, so that I could reply.  I used to 
be on routing-discussion (at least I thought I was), but I don't seem 
to be now, so please include me in any responses.

At 14:44:54 AM -0400 6/20/05, Eric W Gray wrote:
>Tony,
>
>     No disagreement from me.  Perhaps the next obvious question is -
has
>anyone taken this to the
>IEEE?

We have talked to the IEEE about this, and they are very aware of 
this work.  There were several e-mail exchanges with IEEE 802 leaders 
in response to the first charter that was circulated for external 
review last November.  This lead to an e-mail discussion between IEEE 
leadership and the IESG/IAB.  We then had a conference call between 
the interested IESG folks, Bernard Aboba (IEEE liaison manager for 
the IETF) and the IEEE 802 leadership.  An rbridge (AKA TRILL) 
tutorial was also held at an IEEE 802 plenary.

The IEEE is developing a solution for shortest-path bridging, an 
(R)STP approach being developed in IEEE 802.1.  We were quite 
concerned about the potential for conflict between the TRILL work and 
the IEEE 802.1 work, and that was discussed via e-mail and on the 
call.  In the end, we concluded that a link-state-based approach will 
have different applicability than an (R)STP-based approach, and there 
has even some interest in a link-state-based approach from other 
parts of IEEE 802.

We also discussed where this work would best be housed -- in the 
IETF, in the iEEE or as a joint activity.  We don't have any 
mechanism for joint activities with the IEEE, and that option was 
quickly dismissed.  We understand that this is close to the line 
between the two organizations, but the conclusion of our discussions 
was that the development of a link-state-based Ethernet routing 
mechanism is better done in the IETF than in the IEEE.  The IEEE 
leadership did not object to the IETF pursuing this work.

The IEEE 802.1 technical leaders (Mick Seaman and Norm Finn) 
suggested that this work should be review by IEEE 802.1 for 
compliance with the Ethernet service model, and the charter includes 
a request for a formal liaison relationship with IEEE 802.1 for this 
purpose.  It has been pointed out that the purpose of the liaison 
relationship is not clear enough in the current charter, and we will 
be modifying the charter to add explicit IEEE 802.1 review milestones 
for both the architecture document and the specification.

Please let me know if you have any further questions.  The IESG will 
be making a decision on this charter at our telechat this Thursday 
(June 23rd), so if you have an opinion about whether or not we should 
charter this WG in the IETF, please send your comments to the IESG at 
[email-masked].  We are interested in hearing from folks who do want 
this work charted (especially from folks who are willing to invest 
time to make this happen), as well as from folks who have objections 
to chartering the group.

Thanks,
Margaret

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Jun 2005 12:01:58 -0400

Brian:

Please substitute "rule of thumb" for "rule" in my previous message.
Also - IMHO: Quick decisions = good. 

Sue

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian E
Carpenter
Sent: Wednesday, June 22, 2005 6:59 AM
To: Susan Hares
Cc: Alex Zinin; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of
Links (trill)

I can't speak to past events, but in this case there has been
substantial discusssion with IEEE and I don't think there is any
disturbance to the addressing "rule" that you cite. But the
skill set for this particular work is in the IETF. Nobody
denies that it's in the grey area where the question of scope
can be discussed endlessly, but the intention is now to decide
quickly, since the proponents have been more than patient.

    Brian

Susan Hares wrote:
> Margaret:
> 
> The key point is we want to ship product with standardization.
> (A good thing for all of us (IMHO).)
> 
> The rules used to be clear:
> 
> MAC address = IEEE
> IP address/Label = IETF.
> 
> If we are changing the rules, we need to be clear that we are changing
> the rules clearly.  Tony notes where the change in the rules didn't
> match.
> 
> You worked hard to make sure we had IETF consistency.  It would be
> helpful to make sure we have the same for IEEE/IETF consistency.
> 
> Many thanks,
> 
> Sue Hares
> 
> From: Tony Li [mailto:[email-masked]] 
> Sent: Tuesday, June 21, 2005 1:16 PM
> To: Margaret Wasserman
> Cc: Alex Zinin; [email-masked]; [email-masked];
> [email-masked]; Susan Hares; [email-masked]
> Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots
of
> Links (trill)
> 
> 
> Margaret,
> 
> Thanks for your response.  IESG cc'ed per your request.
> 
> 
> be
>>making a decision on this charter at our telechat this Thursday (June
>>23rd), so if you have an opinion about whether or not we should
> 
> charter
> 
>>this WG in the IETF, please send your comments to the IESG at
> this
>>work charted (especially from folks who are willing to invest time to
>>make this happen), as well as from folks who have objections to
>>chartering the group.
> 
> 
> While I have no objection to chartering this group, I'm left
scratching
> my head in wonder, trying to find the consistency between accepting
this
> work and the previous decision to reject the IS-IS work on jumbo
frames.
>  You may recall that the opinion at the time was that the work would
> step on IEEE toes and therefore the work was halted.  The IEEE chooses
> not to endorse jumbo frames, so in some sense there is no
> 'standardization' to be done.  Vendors, however, continue to ship
> running code for jumbo frames.  And there is no agreement for IS-IS
> operation in such situations.
> 
> IMHO, the IETF needs to re-examine its goals and operations in this
> regard.  What used to be an organization that was about standardizing
> de-facto standards is now engaged in politicking at the expense of
> technology.  We claim to eschew kings and voting, but we seem to be
> engaged in SDO diplomacy at the expense of code, users, and the
> Internet.  Does that seem right to you?
> 
> Regards,
> Tony Li
> 
> 
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Jun 2005 12:11:28 -0400

Radia:

That is a very valid point. The Layer2/Layer3 linking is important and
outside of the scope of Layer-2.  Layer 3 expertise is key to that one. 

Just like ISIS jumbo grams - with cross-over between the two. 

Sue

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Monday, June 20, 2005 4:12 PM
To: Radia Perlman
Cc: Alex Zinin; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Susan Hares
Subject: Re: WG Review: Transparent Interconnection of Lots of Links
(trill)

Oh and one other thing...things like proxy ND and passing around (layer 
3, layer 2) pairs to
facilitate it, are something else that are not specific to any 
particular layer 2 technology.

Radia

Radia Perlman wrote:

> Yes. This has been discussed with IEEE. I even gave a tutorial there 
> on TRILL at the
> last IEEE, both at a general tutorial slot and at the mesh group 
> (invited by the chair
> of that group, Don Eastlake). It got a very friendly reception, by the

> way.
>
> There are some people in the wireless mesh group who
> have since mentioned to me that they are interested
> in proposing a solution like this within the mesh group.
> And that would be good. But this technology is not specific to any 
> particular
> layer 2 technology, and certainly not limited to wireless. So it 
> should be standardized in something
> that is layer 2 agnostic. It could also be used in other places, of 
> course, and if multiple WGs are
> working on similar things, it is good if they cooperate and liase (is 
> that a word?) so that technology
> works well together, and even better yet, if it converges towards the 
> same design. I believe
> the intention of all concerned is that all the WGs that might be 
> interested and might
> be helpful have liason relationships.
>
> Radia
>
>
>
> Susan Hares wrote:
>
>> Eric and Tony:
>>
>> See my comments about Wireless Mesh proposal an Wi-Mesh alliance I'm 
>> a part of submitted 6/15/05 to the 802.11s.
>>
>> Radia or others may know more about 802.1 since they have more 
>> history with IEEE.
>>
>> Sue
>>
>>
------------------------------------------------------------------------
>>
>> *From:* Eric W Gray [mailto:[email-masked]]
>> *Sent:* Monday, June 20, 2005 2:45 PM
>> *To:* Tony Li
>> *Cc:* Susan Hares; Alex Zinin; [email-masked]; 
>> *Subject:* Re: WG Review: Transparent Interconnection of Lots of 
>> Links (trill)
>>
>> Tony,
>>
>> No disagreement from me. Perhaps the next obvious question is - has 
>> anyone taken this to the
>> IEEE?
>>
>> -- 
>> Eric
>>
>> Tony Li wrote:
>>
>>
>>
>> In other instances, when proposals were IEEE'ish, we were directed to
>>
>> take them to the IEEE.
>>
>>
>>
>> Tony
>>
>>
>>
>>
>>
>> Eric W Gray wrote:
>>
>>  
>>
>>> Sue,
>>>
>>>
>>>
>>> assume you mean to ask "why is it not IEEE" - rather than "why is it

>>> not
>>> [email-masked] <mailto:[email-masked]> wrote:
>>>
>>>
>>>
>>>   
>>>
<mailto:[email-masked]>
>>>>
>>>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked]

>>>> <mailto:[email-masked]>
>>>>
>>>> [email-masked] <mailto:[email-masked]>.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     
>>>
>>>
------------------------------------------------------------------------

>>> [email-masked] <mailto:[email-masked]>
>>>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 22 Jun 2005 14:01:35 -0400

Margaret: 

Routing creates forwarding.  The difficulty is in the timing of the
updates and not the actual forwarding.  Creating encapsulations that
scale and can perform well has been in the routing area (MPLS is an
example).   Updating from the control plane to the forwarding plane is
also in the Routing area (FORCES) due to the timing issues.   

Even if you use existing protocols, you may have timing constraints or
protocol issues.  An example of this is the MANET OSPF work.  (Please
refer to the MANET page for this.)  Reduced flooding has been discussed
and experimented with in MANET.  Reduced flooding is key to reducing
overload on some IEEE substrates (wireless mesh).  Security of the
Bridge protocol should be a concern.  Again, the discussions in the
RP-SEC group have long discussed good and bad algorithms. 

In 802.1 you are talking about inter-working between multiple LAN areas.
This most resembles ISIS/OSPF inter-areas.  Auto-configuration of
inter-area nodes has experience in routing or the operations.   My
understanding is that you are not assigning MAC address (aka DHCP like
functions) but creating forwarding state. 

So I guess my summary comment is: "I do not agree with you".  The
critical component of this work is the link-state, routing
auto-configuration and security knobs known to the routing area. 

If we are trying to get this protocol out quickly, let's build on the
expertise in the routing area. 

Sue Hares

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Wednesday, June 22, 2005 1:16 PM
To: Susan Hares; Adrian Farrel; Brian E Carpenter
Cc: Tony Li; Alex Zinin; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of
Links (trill)

Hi Sue,

The TRILL WG would not be chartered to develop a link-state routing 
protocol.  They would be chartered to make use of an existing 
link-state routing protocol, and any extensions or modifications to 
that protocol would be referred to the appropriate routing area WG.

The TRILL WG would  determine the mechanisms for encapsulating and 
forwarding Ethernet frames and for auto-configuring the rbridges.  I 
am not sure that in-depth expertise in link-state routing protocols 
is needed for that.  Instead, you need expertise in encapsulation, 
forwarding and configuration, which are all Internet area topics.

Margaret

At 12:27 PM -0400 6/22/05, Susan Hares wrote:
>Margaret:
>
>I suggest that the expertise in the link state is in the Routing area
of
>the IETF.  If it belongs in the IETF due to expertise, it belongs in
the
>Routing.
>
>Critical early review has been determined to be key to a quickly
>deployed specification.
>
>Sue
>
>From: Margaret Wasserman [mailto:[email-masked]]
>Sent: Wednesday, June 22, 2005 8:57 AM
>To: Adrian Farrel; Brian E Carpenter
>Cc: Tony Li; Alex Zinin; [email-masked]; [email-masked];
>Hi Adrian,
>At 1:22 PM +0100 6/22/05, Adrian Farrel wrote:
>>I think the skill-set to which Brian refers is link state routing.
>(Care
>>to confirm, Brian?)
>
>Yes, expertise in link-state routing is certainly one reason why this
>work could be seen as more in-scope for the IETF than for the IEEE.
>Also, frankly, there is interest in the IETF in doing this work (a
>link-state-based Ethernet routing solution), while the IEEE is
>continuing to pursue (R)STP-based approaches.
>
>>If so, why is this WG targeted at the Internet Area not the Routing
>area?
>
>This questions has been discussed in the IESG, as well, and we did
>not have 100% agreement regarding the area in which this work belongs.
>
>Personally, I think that TRILL is a better fit for the Internet area,
>and I will explain why...
>
>Traditionally, the division between the Internet area and the Routing
>area has been that the Routing area deals with protocols that
>distribute routing information (routes/labels) and the Internet area
>has been responsible for the forwarding behaviour and encapsulation
>mechanisms that make use of that information.
>
>The TRILL charter maintains that split -- any work on the routing
>protocols themselves would be done in the routing area, while the
>encapsulation/forwarding mechanism would be developed in the Internet
>area.
>
>Perhaps you have a different model of the division between the
>Routing and Internet areas that makes you think otherwise?
>
>The IESG discussed this issue several months ago.  We agreed that
>this work is close to the line between Internet and Routing, but we
>reached an agreement that it would best be placed in the Internet
>area, with the understanding that we would appoint a technical
>advisor and a WG co-chair with routing expertise.  BIll Fenner
>volunteered to be the Technical Advisor, and Bill and Alex took an
>action item to return with a list of potential co-chairs.
>
>Ultimately, I am not sure that it matters all that much which area
>this work is done in, since it will require expertise and involvement
>from both areas in order to succeed.
>
>Margaret

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 23 Jun 2005 11:47:07 -0400

Margaret: 

Does IETF have a formal relationship with IEEE?  The paragraphs from
your earlier mails have me a bit confused.  

> Your paragraph seems to assume that the IETF and the IEEE both wanted 
> to do this work, and we somehow _won_ the right to do it through some 
> negotiation.  This isn't the case at all.  There are some people in 
> the IETF who wanted to do this work. The IEEE is not interested in 
> doing this work, preferring to continue their work on (R)STP-based 
> solutions.  We (the IESG) initiated a discussion with the IEEE 802 
> leadership about this topic, and the IEEE leadership did not object 
> to this work being done in the IETF.

[....] 

> We have been (and continue to be) a bit concerned about whether there 
> are sufficient quantities of the right expertise in the IETF to do 
> this work well.  However, responses to technical discussions on the 
> TRILL list have been quite good, and there does seem to be a core 
> group of well-qualified people committed to this work.

1st - I'm happy to contribute to this work in what ever forum it exists
in.

2nd - I would like to have this discussion end today (after IESG), but
it 	would be "way cool" and necessary to document who, what, when
and 	where in a document that you can post online about the IEEE/IETF
discussions.

3rd - It would be "way cool"/useful to summarize this discussion in a
document that is associated with the working group pages.

Shalom, 

Sue Hares

(Still inspired by folks like you to make the IETF consistent!)