Subject: [trill] I-D Action: draft-ietf-trill-over-ip-01.txt

From: [email-masked]
Date: Fri, 04 Jul 2014 04:19:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

        Title           : Transparent Interconnection of Lots of Links (TRILL) over IP
        Authors         : Margaret Wasserman
                          Donald Eastlake
                          Dacheng Zhang
	Filename        : draft-ietf-trill-over-ip-01.txt
	Pages           : 16
	Date            : 2014-07-04

Abstract:
   The Transparent Interconnection of Lots of Links (TRILL) protocol is
   implemented by devices called TRILL Switches or RBridges (Routing
   Bridges).  TRILL supports both point-to-point and multi-access links
   and is designed so that a variety of link protocols can be used
   between TRILL switch ports.  This document standardizes methods for
   encapsulating TRILL in IP(v4 or v6) to provide a unified TRILL
   campus.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-trill-over-ip-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-over-ip-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Jul 2014 15:28:31 -0700

Hi, all,

I don't see TRILL as needing a specific solution, given ethernet can 
already be bridged using IP any number of ways (including GRE or L2VPN 
approaches).

IMO, this WG would be better served to require that TRILL run over 
Ethernet, and that TRILL run where Ethernet has - and can - already be 
extended to.

Joe

On 7/4/2014 4:19 AM, [email-masked] wrote:
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 11 Jul 2014 16:02:34 -0400

> Hi, all,

Hi Joe,

First off, I'd like to thank you for your contributions to this draft.
In particular, section 10.1 on Recursive Ingress was included in
response to comments that, as I recall, came primarily from you.

> I don't see TRILL as needing a specific solution, given ethernet can already
> be bridged using IP any number of ways (including GRE or L2VPN approaches).

Well, I suppose you would get different answers from different people
as to whether or not having convenient default security keying
leveraging IS-IS keying, zero configuration under some circumstances,
saving 14 or 18 or so bytes on every packet, having protection against
recursive ingress, etc., are worth it. But in the context of TRILL,
this has already been decided. TRILL over IP is specifically part of
the work in the TRILL Charter, that Charter was approved by the TRILL
WG and the IESG, it has been determined that there is a TRILL WG
consensus to use UDP encapsulation, and, in my opinion, most of the
work, although not all of it, has already been done as per this draft.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Jul 2014 16:43:32 -0700

Hi, Donald,

> response to comments that, as I recall, came primarily from you.

I can't find any posts I made that were involved in this topic other 
than to question its necessity.

> recursive ingress, etc., are worth it.

I saw some of those come up two years ago when I asked the same question 
before this was adopted by the WG.

 > But in the context of TRILL,
> this has already been decided.TRILL over IP is specifically part of

It can be decided, but that doesn't mean it has been addressed within 
the document. The document fails to explain why this is needed vs. the 
numerous ways to extend L2 over L3.

I would strongly suggest an extended discussion of the need for this 
solution as a key part of this document - esp. vs. other known approaches.

I would also strongly suggest a discussion of the limitations of this 
approach, i.e., that it should NEVER be used to extend the number of 
components or geographic distribution beyond that which L2 can support. 
I recall that being a core part of the TRILL problem statement that has 
been lost in the weeds.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Jul 2014 10:12:59 -0700

Hi, Donald,

I raised these concerns at the time the doc was proposed as a WG item, 
and these issues were never really addressed. WG adoption does not 
ensure a document gets published - there's always IETF LC, in addition 
to other steps - this being one of them.

I see your points about keying, zero-config, etc., but those argue for a 
new layer to support TRILL use of existing encapsulation, not for a 
totally new encapsulation.

Although I appreciate the IESG's "let a thousand flowers bloom" 
viewpoint, the result is a thousand wheels get reinvented, and it's 
nearly impossible to ensure that past mistakes are not repeated.

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 15 Jul 2014 13:01:07 -0400

Hi Joe,

Sorry for delay in response. I was traveling and am now being kept
busy at a meeting in San Diego.

On Mon, Jul 14, 2014 at 1:12 PM, Joe Touch <[email-masked]> wrote:
> Hi, Donald,
>
> I raised these concerns at the time the doc was proposed as a WG item, and
> these issues were never really addressed. ...

Well, you get to decide whether you believe your concerns have been
adequately addressed. And the WG Chairs get to decide what the
consensus of the WG is. None of your concerns have been, in my
opinion, technical, in the sense of arguing that something will not
work or will not be interoperable. Your concerns appear to me to be
matters of opinion, such as whether something is "needed", on which
reasonable people might have different opinions.

To the extent that your concern is that someone will think that using
TRILL over IP somehow, in itself, significantly changes TRILL's
scaling characteristics, I do not think there is anything in this
draft or any TRILL document saying that a choice of link protocol on
one or more links in a TRILL campus will do that. In any case I'd be
fine with adding a sentence or two to Section 2 of the draft,
clarifying this.

> I see your points about keying, zero-config, etc., but those argue for a new
> layer to support TRILL use of existing encapsulation, not for a totally new
> encapsulation.

I do not agree with your analysis. Creating a "new layer" seems to me
to be a lot of unnecessary work compared with using the method of
transporting X over IP by using UDP of which there are multiple
examples. ((Not really related to any of this but I just recently
noticed that RFC 768 which specifies UDP is almost 34 years old and
that no need to update, obsolete, or file an errata against it has
occurred so far.))

> Although I appreciate the IESG's "let a thousand flowers bloom" viewpoint,
> the result is a thousand wheels get reinvented, and it's nearly impossible
> to ensure that past mistakes are not repeated.

I don't think that there are 1,000 link protocols and I don't think
that a guarantee that no mistake be made should be a condition for a
standards effort.

In any case, the TRILL WG has thus far specified how to send TRILL
directly over 2 technologies, Ethernet (RFC6325) and pseudowires
(RFC7172), and the PPPEXT WG specified how to send TRILL over PPP
(RFC6361). This draft would increase the universe of link protocols
directly, interoperable, and efficiently usable by TRILL for 3 to 4 by
adding IP, which seems to me to be a particularly prominent and widely
deployed technology. I do not remember any proposal being made thus
far in the TRILL WG for any further TRILL over X standards track
documents.

Thanks,
Donald

>>> already

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Jul 2014 10:29:40 -0700

On 7/15/2014 10:01 AM, Donald Eastlake wrote:
> adequately addressed.

First of all, I raised concerns during the WG confirmation of consensus 
during the last IETF. Since there was NO response, it's very clear my 
concerns were not addressed at all.

> And the WG Chairs get to decide what the
> work or will not be interoperable.

The need for yet another layer of encapsulation, and the complexity that 
entails, is absolutely technical.

 > Your concerns appear to me to be

Necessity can be demonstrated. Your jumping to the conclusion that, in 
the absence of need, it's a matter of opinion as to whether a new 
protocol is appropriate or not. I agree, but only if you're claim is 
that there is no demonstrable need.

> fine with adding a sentence or two to Section 2 of the draft,

I think that would help. However, that's independent of whether TRILL 
goes over an existing Ethernet-over-IP solution or a TRILL-specific UDP 
encapsulation.

> examples.

You are creating a new layering here, but you're also importing a bunch 
of stuff you don't necessarily need to re-specify. TRILL runs over 
Ethernet. Ethernet already runs over lots of things.

Is this WG intending to develop a TRILL-over-X specification for every X 
for which there is an Ethernet-over-X specification?

If so, it strongly suggests that TRILL has a significant architectural 
flaw. Either it runs over Ethernet or not. If it does, it should run 
over anything Ethernet runs over - without the need for anything else.

> (RFC6361).

It would have been more useful to specify Ethernet over PPP.

 > This draft would increase the universe of link protocols
> deployed technology.

The key issue being ignored is that Ethernet already runs over IP (using 
GRE, among others), and that TRILL thus already runs over IP.

By specifying this, you just add yet another mechanism, one that the 
uninformed would think is necessary, but is clearly not.

 > I do not remember any proposal being made thus

Why not? Surely TRILL over SONET is useful. How about TRILL over 
powerline? TRILL over coax?

Joe

---

From: James Carlson <[email-masked]>
Date: Tue, 15 Jul 2014 14:02:08 -0400

> entails, is absolutely technical.

I agree with Joe on this point.  It's quite a bit of complexity to
create yet another link layer over UDP/IP specification.  The L2TP
documents show where this likely goes.

(And for what it's worth, I think you might be better off with "TRILL
over L2TP," as that gives you all of the authentication, NAT traversal,
and other bits that have already been worked out for L2TP.)

> for which there is an Ethernet-over-X specification?

I think a better question to ask is why none of the existing mechanisms
that could solve this problem are in fact adequately usable.  That
should be a core part of any new protocol description.

> It would have been more useful to specify Ethernet over PPP.

That already exists -- RFC2878 provides Ethernet bridging over PPP.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>