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

From: Alex Zinin <[email-masked]>
Date: Wed, 22 Jun 2005 10:28:30 -0700

Margaret,

  I did a quite detailed talk at the last BOF, explaining what potential
  routing-related issues are there, and how a naive approach would not
  scale.

  Routing expertise in TRILL is _extremely_ important if we want a solid
  technology.

-- 
Alex

Wednesday, June 22, 2005, 10:16:28 AM, Margaret Wasserman wrote:

> 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
>>
>>-----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:57:47 -0400

Hi Alex,

>   Routing expertise in TRILL is _extremely_ important if we want a solid

I think that I have said the same thing several times in this thread, 
although perhaps not with this particular cc: list...

It is vitally important that we have experts from both the RTG area 
and the INT area involved in TRILL, or the group will not be 
successful.  When the potential home of this work was discussed by 
the IESG, we all agreed that routing expertise would be essential to 
the success of this group.  That is why we had proposed to have a 
technical advisor and co-chair from the RTG area.

I am somewhat confused by this discussion, as the tone seems to 
indicate that if we have a group in the INT area, no one from the 
routing area can/will attend and vice versa.  There are many 
individuals who cross the boundaries between those two areas, we all 
meet in the same city at the same time, and I thought that this type 
of cross-fertilization was exactly why we choose to have IETF plenary 
meetings with all areas present.

Is it really true that none of the "routing people" who have posted 
passionate messages about this work will attend if the group is 
chartered in the INT area?  If so, I think we have a much bigger 
problem than what to do with this particular group.

Margaret

---

From: Radia Perlman <[email-masked]>
Date: Wed, 22 Jun 2005 10:41:05 -0700

TRILL also requires expertise in ND, and IP endnode behavior in general,
which
would be in Internet. Hopefully which area something is in does not
preclude cross-fertilization, or review by experts in other areas.
Security and management are also areas that need to be consulted for
almost any protocol.

Radia

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jun 2005 07:59:44 -0700

Eric W Gray wrote:

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

Perhaps I can help answer this.

The encapsulation is not end-to-end; it is merely between the TRILL 
devices. The draft-radia-rbridge draft shows the current thinking for 
the encapsulation, with a header than in the case of carrying things 
over Ethernet include
  - source rbridge MAC address (so that bridges between the rbridges 
don't get confused)
  - next hop rbridge MAC address (to avoid proliferation should the 
bridges flood the frame and multiple rbridges receive it)
  - ttl (to limit the damage from any temporary routing loops)
  - last hop rbridge (so that intermediate rbridges don't need to track 
the location of each station)
  - Ethernet type

So this is quite different than the Martini approach.

Should TRILL later be expanded to apply to run over MPLS (something 
which is not in the current charter) then I suspect we'd end up with an 
encapsulation like Martini, and a link-state routing protocol carrying 
the MAC addresses.

So the TRILL work is architecturally quite similar to the VPLS work in 
L2VPN. The encapsulation that is safe and scalable for Ethernet is a key 
difference.

    Erik