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

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

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

-----Original Message-----
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];
[email-masked]; [email-masked]; Susan Hares
Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of
Links (trill)

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

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

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 Jun 2005 13:16:28 -0400

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jun 2005 14:18:26 -0700

Margaret Wasserman wrote:

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

In addition to the above, there is also a need to work out the details 
how TRILL devices interact with IEEE 802.1D bridges at the edge. This is 
an issue where the L2VPN WG has some experience, and working with L2VPN 
and IEEE 802.1 is key. So being in the same area (INT) as L2VPN might be 
helpful.

    Erik

---

From: Eric W Gray <[email-masked]>
Date: Thu, 23 Jun 2005 08:41:12 -0400

Margaret,

    The interesting thing here is that any changes in the encapsulation 
of Ethernet
frames would have drastic implications on all Ethernet equipment - 
including NIC
cards in Ethernet end stations. If this is not the case, then we are 
talking about an
encapsulation of a transport segment, rather than encapsulation 
end-to-end. If that
is what we are talking about, how does this "encapsulation" differ from 
Martini?

    Because of these considerations, I had assumed that what we would be 
doing
in the alleged TRILL working group is specifying how Ethernet (MAC) address
reachability would be advertised in an OSPF-like routing protocol. For 
the sake
of simplifying the discussion, let's assume that it would be OSPF 
instead of an off
the cuff spinout of a generic link state routing protocol.

    If the intent is to specify the use of the OSPF routing protocol to 
advertise MAC
reachability - as it certainly seems to be - then the same argument you 
make for this
work in the IETF applies to doing it in the Routing Area as well. That 
is where the
specific expertise lies.

    On the other hand, if the intent is to specify yet another L2 
encapsulation - which
could be used as an argument for doing this in the Internet Area - then 
the alleged
expertise (for yet another L2 encapsulation) is no more specific to the 
IETF than to
any other organization you might care to name.

    My general impression from the discussion is that we may have been 
successful
in playing word games with IEEE on this score where we have not been 
anywhere
near as successful in a similar context previously. If that is the case, 
then those who
have been successful in this should be congratulated for their ability 
to bandy words
- if not necessarily for their intentions in doing so.

    It also looks to me like some people want to do this work and - 
because they
have to go to the IETF anyway - they want to do it in the IETF. Frankly, 
I think
we might be able to make an argument for doing this work in the IETF - 
but only
if we simultaneously acknowledge that it should be doen in the Routing Area.

    One of the things that doing it this way might help to do is 
eliminate some of the
energy being poured into this effort that is apparently based - at least 
in part - on
some agenda(s) not shared with the IETF as a whole.

    Just to be crystal clear, I think it is obvious that some of the 
IETF leadership
wants to do this work. I also think it is clear that a lot of people 
want this work to
be done somewhere. And it should also be clear that not everyone in the 
IETF is
convinced that the IETF is the place to do it - irrespective of whether 
or not the
IEEE wants to play in the same sandbox too. But - if we're going to do 
it in the
IETF, let's do it in the right Area.

--
Eric

[email-masked] wrote:

> am not sure that in-depth expertise in link-state routing protocols is

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 23 Jun 2005 09:20:21 -0400

Hi Eric,

At 8:41 AM -0400 6/23/05, Eric W Gray wrote:
>    If the intent is to specify the use of the OSPF routing protocol 
>to advertise MAC
>reachability - as it certainly seems to be - then the same argument 
>you make for this
>work in the IETF applies to doing it in the Routing Area as well. 
>That is where the
>specific expertise lies.

Determining how the Ethernet addresses would be advertised in OSPF 
(or IS-IS) would be done in the appropriate Routing area WG 
(presumably the OSPF or IS-IS WG).  I believe that we are in 
agreement about where this expertise lies.

>could be used as an argument for doing this in the Internet Area - 
>then the alleged
>expertise (for yet another L2 encapsulation) is no more specific to 
>the IETF than to

I have seen plenty of bad encapsulations.  If expertise is not 
required, then perhaps the people who wrote the bad encapsulations 
(ones that failed to consider MTU/fragmentation issues, for example) 
were just sloppy?

>    My general impression from the discussion is that we may have 
>been successful
>in playing word games with IEEE on this score where we have not been anywhere
>near as successful in a similar context previously. If that is the 
>case, then those who
>have been successful in this should be congratulated for their 
>ability to bandy words

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.

>have to go to the IETF anyway - they want to do it in the IETF. 
>Frankly, I think
>we might be able to make an argument for doing this work in the IETF 
>- but only
>energy being poured into this effort that is apparently based - at 
>least in part - on

It is not clear to me what motivations you are ascribing to whom.  If 
you think that there is a possibility of any type of misconduct or 
gaming of the system here, perhaps you could be more explicit?

>be done somewhere. And it should also be clear that not everyone in 
>the IETF is
>convinced that the IETF is the place to do it - irrespective of 
>whether or not the
>IEEE wants to play in the same sandbox too. But - if we're going to 
>do it in the

I am a bit concerned about this paragraph, because you seem to be 
indicating that "some members of the IETF leadership" are doing 
something underhanded here.  Personally, I think that the TRILL 
proposal is technically interesting and may benefit the Internet.  I 
also respect the key contributors to this effort.  I have advocated 
for this work because it was brought to me, and because I believe 
that it would be a good thing to do.  This is how most IETF efforts 
get started, and I don't think that there is anything unethical going 
on here.  Do you think otherwise?

If the IESG decides to charter this work (we are considering that on 
our telechat today), then the IESG will need to decide in which area 
to charter it.  I don't consider this choice to be as black-and-white 
as you apparently do.  However, I do think that the work itself (what 
the TRILL WG would be doing, not what the link-state routing protocol 
WG would need to do) is more closely related to other INT area 
efforts (such as L2VPN) than it is to the routing area.

Your comments about the "alleged expertise" required to design an L2 
encapsulation, and the fact that you didn't mention the configuration 
aspects of this work indicate to me that you may be underestimating 
the amount and complexity of the non-routing-protocol work involved 
in this effort.

Just so that you understand, I am not planning to be the responsible 
AD for this work, and it is not an issue to me whether the 
responsible AD is Mark, Bill or Alex (I trust all of them, and I 
believe that they all have the expertise to do a good job here).  The 
decision about where to place this work should be based, IMO, on 
where it belongs in the current structure of the IETF areas, and I 
personally see it as more appropriate for the INT area.  I understand 
that you see it differently, and some other people share your view. 
This is something that we will have to work out in the IESG if we 
decide to charter the group.

Thank you for your input, and I hope that you will consider being 
involved in the resulting WG, regardless of the area in which it is 
chartered.

Margaret

---

From: Eric W Gray <[email-masked]>
Date: Thu, 23 Jun 2005 10:15:09 -0400

Margaret,

    What you did not answer is my initial comment about encapsulation.  
I will include
that again here:

"The interesting thing here is that any changes in the encapsulation of 
Ethernet
frames would have drastic implications on all Ethernet equipment - 
including NIC
cards in Ethernet end stations. If this is not the case, then we are 
talking about an
encapsulation of a transport segment, rather than encapsulation 
end-to-end. If that
is what we are talking about, how does this 'encapsulation' differ from 
Martini? "

    As this was my first paragraph, and it set the tone for the 
remaining comments,
omitting it may have been just a little disingenuous.

    Given that nobody has explained - as far as I know - what 
encapsulation changes
we expect to make (that are not covered by work already completed), your 
entire
argument about "encapsulation complexity" may be irrelevant.

    As for my specific references to word-smithing, this also requires 
an understanding
of the scope of intent to change Ethernet encapsulation. If we talk to 
the IEEE about
using OSPF to transport MAC address information, naturally they would be 
amenable
to specifying how that should be done in the IETF. But did we talk 
specifically about
introducing a new Ethernet encasulation when we talked to the IEEE?

    If we are not talking about a new (or changed) end-to-end Ethernet 
encapsulation,
then we are talking about tunneling encapsulation for L2 frames across 
part of the
network. If we plan to use L3/label encapsulation to do this, then we 
need to know
how this requirement differs from existing mechanisms (hence the Martini 
reference
that also is included in the text you omitted).

    If we are talking strictly about defining ways to use existing 
encapsulation in some
combination with extending routing protocols. then the work belongs in 
the Routing
Area, more than in the Internet Area.

    One other possibility is that we may be talking about single hop 
encapsulation for
OSPF-like advertisements in BPDU-like setup transactions. In this case, 
the expertise
you refer to does not exist in the IETF any more than it does elsewhere 
- since this is
not something that has been done before.

    My concern is that - if we are indeed talking about a replacement 
for Ethernet
encapsulation, then we will probably find out that the IEEE does care. 
The fact that
we intend to liase with the IEEE is good, but it will not help if it 
turns out that they do
not want us to proceed further after we have spent huge amounts of 
energy getting
to the point that everybody finally understands what it is that we 
intend to do.

--
Eric  

Margaret Wasserman wrote:

> Determining how the Ethernet addresses would be advertised in OSPF (or 
> IS-IS) would be done in the appropriate Routing area WG (presumably 
> the OSPF or IS-IS WG).  I believe that we are in agreement about where 
> this expertise lies.
>
> leadership about this topic, and the IEEE leadership did not object to 
> this work being done in the IETF.
>
> for this work because it was brought to me, and because I believe that 
> it would be a good thing to do.  This is how most IETF efforts get 
> started, and I don't think that there is anything unethical going on 
> here.  Do you think otherwise?
>
> WG would need to do) is more closely related to other INT area efforts 
> (such as L2VPN) than it is to the routing area.
>
> the amount and complexity of the non-routing-protocol work involved in 
> this effort.
>
> AD for this work, and it is not an issue to me whether the responsible 
> AD is Mark, Bill or Alex (I trust all of them, and I believe that they 
> all have the expertise to do a good job here).  The decision about 
> where to place this work should be based, IMO, on where it belongs in 
> the current structure of the IETF areas, and I personally see it as 
> more appropriate for the INT area.  I understand that you see it 
> differently, and some other people share your view. This is something 
> that we will have to work out in the IESG if we decide to charter the 
> group.
>