Subject: EtherIP

From: Danny McPherson <[email-masked]>
Date: Fri, 05 Jan 2001 13:04:13 -0700

This draft should be of interest here to the L2TP WG.

It would seem that yet another proposal for Ethernet 
over IP is pushing it.  I I understood Suhail's
original request for the L2TP Ethernet Service Type 
(check the archives for the explanation), and I also 
understand Carlson's concerns regarding use of PPP
with BCP.

I think perhaps if this draft can be merged into Suhail's
then it will alleviate Most of the concerns brought up
to date with Suhail's draft.

I certainly don't believe that three "Standard" ways of 
tunneling Ethernet/IEEE 802.3 over IP is in the best 
interest of the community.

-danny

------- Forwarded Message

To: IETF-Announce: ;
From: The IESG <[email-masked]>
SUBJECT: Last Call: EtherIP: Tunneling Ethernet Frames in IP Datagrams
	 to Proposed Standard
Reply-to: [email-masked]
Date: Fri, 05 Jan 2001 14:12:28 -0500
Sender: [email-masked]

The IESG has received a request to consider EtherIP: Tunneling Ethernet
Frames in IP Datagrams <draft-housley-etherip-00.txt> as a Proposed
Standard.  This has been reviewed in the IETF but is not the product of
an IETF Working Group.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by February 5, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-housley-etherip-00.txt

------- End of Forwarded Message

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 7 Jan 2001 12:32:26 -0800

>interest of the community.

Agreed. We should not have three proposed standards in this 
area. One would be best -- and soon, before an explosion
in implementation approaches makes the standards process 
irrelevant.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 8 Jan 2001 06:42:01 -0800 (PST)

hmmm... one already *does* exist, which is Ethernet over BCP/PPP. The thread
in the mailing list was questioning why a second proposal was being adopted as
a WG work item, given that there was already a way to carry ethernet over PPP.

I believe the answer to the question was simplicity. If that is the case, well
I think that EtherIP wins :)

PatC

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 09 Jan 2001 12:50:18 -0500

> I think that EtherIP wins :)

It all depends on what you are trying to keep simple.

My cursory reading of EtherIP is that it is simple "bridging" of
ethernet directly over IP. There is no control plane. There is a simple
1 byte header between the MAC address and IP, 4 bits for a version
number and 4 reserved bits. Indeed, a very simple protocol.

My understanding of the application space for Ethernet over L2TP
includes a grouping of PCs (MAC addresses) within an L2TP session. Use
of an assignable session id here means that the edge device does not
have to keep up with or update MAC address tables for the "bridged"
frames to a given destination (such as a PVC) on the downstream path.
One could argue that this makes the code (at least the switching path
and state maintenance) at this point in the network much simpler. 

A similar argument might be made for Ethernet over BCP/PPP/L2TP/IP vs.
Ethernet over L2TP/IP. Are we trying to keep implementations and code
simple within a given application space or trying to keep the number of
standards documents to a minimum? There are tradeoffs on both sides of
the equation here.

I am simply trying to make some counterpoints to the discussion at this
point. What I think we really need is an applicability section within
the Ethernet over L2TP draft which could be the basis of review and
discussion. This is something that has been requested of the current
authors repeatedly, and I hope that it will be forthcoming.

- Mark

---

From: James Carlson <[email-masked]>
Date: Tue, 9 Jan 2001 16:01:02 -0500 (EST)

> number and 4 reserved bits. Indeed, a very simple protocol.

Right; unlike BCP, I didn't see that as roughly equivalent to
Ethernet/L2TP.  The operational differences are significant.

> standards documents to a minimum? There are tradeoffs on both sides of

The argument is different here.  BCP/PPP/L2TP/UDP/IP uses only
standards-track material, supports all of the things that you'd want
out of L2TP (multiple sessions and such), does not *require* more than
LCP/BCP support out of PPP, and also properly supports Spanning Tree,
VLAN tagging, tinygram compression, identification of MAC type,
bit-endianness and other bridging related issues.

Ethernet directly over L2TP by contrast does not support Spanning Tree
nor VLANs, nor any of the other BCP features.  It merely forms a
minor, inflexible, and untested subset of BCP.

This statement in the Ethernet/L2TP draft is particularly bad:

   It is possible to use PPP Bridging Control Protocol (BCP) as
   specified in [RFC2878] to transport the Ethernet frame over L2TP
   without employing a new service type.  However, using BCP might not
   be feasible since the Ethernet client may not support BCP.
   Furthermore, the service type approach has less protocol overhead
   than using BCP.

If the "client may not support BCP" -- a standards track protocol with
several interoperable implementations and much field experience --
then what hope is there that the client supports this brand-new
scheme?  It seems to me that the argument for wanting a new protocol
to handle Ethernet over L2TP is circular -- you need this new protocol
because the peer might support only the new protocol and not the
standard one.

So, what about the overhead argument?  The overhead of Ethernet over
BCP over PPP versus Ethernet directly over L2TP boils down to
*negative* one octet in the best case (ACFC, PFC, F bit 0).  That is,
BCP encapsulation is one octet smaller than Ethernet/L2TP.

If you include the Ethernet FCS end-to-end under BCP (an option; F bit
set to 1), the BCP overhead is 3 octets more than Ethernet/L2TP.

Is 3 octets (a drop in the 28 octet bucket compared to the UDP/IP
overhead underneath L2TP) worth creating yet another standard?

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

---

From: "Srikrish" <[email-masked]>
Date: Tue, 9 Jan 2001 10:59:12 -0800

Hi Guys,

  Can anyone suggest standard (industry available)
  LNS Server?

  Is there any concept of having LNS server at all?
  i.e. Product running L2TP in LNS mode and terminate
  PPP calls and send IP packets to local server for
  handling.

  I would really appreciate the answers.

Thanks in Advance,
Regards
Srikrishnan

---

From: Suhail Nanji <[email-masked]>
Date: Tue, 9 Jan 2001 18:36:13 -0800 (PST)

> and state maintenance) at this point in the network much simpler. 

To add to the above accurate description, please note EoL2TP is not just a
method of transporting Ethernet over IP, since L2TP can be transported over
other media as well (ie, ATM, FR, etc).  Furthermore, EoL2TP allows
integration of Ethernet sessions and PPP sessions over one tunnel which may
be transported over IP. This reduces the number of tunneling protocols to
manage in a network.

> authors repeatedly, and I hope that it will be forthcoming.

I will add this section in the next draft.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 9 Jan 2001 18:39:51 -0800 (PST)

> be transported over IP. This reduces the number of tunneling protocols to

Sorry but your statements are contradictory. You want to reduce the number of
protocols, but instead of using existing standards track protocols, you opt 
to create new ones. btw, the standards track ones would "allow integration
of Ethernet sessions and PPP sessions over one tunnel..."

I think that the question that we've been asking is some justification for
duplicating work.

> I will add this section in the next draft.

Looking forward to reading it.

PatC

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 9 Jan 2001 22:07:00 -0800

> number and 4 reserved bits. Indeed, a very simple protocol.

I'm afraid however, that it is *too* simple.

As described in [1] and [2], there are a number of
"hard invariants" that MUST be met in bridging together of
two IEEE 802 LANs: nonduplication and sequential delivery. It is
incumbent on bridges to maintain these hard invariants
absolutely.

However, when EtherIP is run over the Internet, it
is to be expected that Ethernet frames will arrive out of
order and/or be duplicated.

That seems like a big problem to me.

[1] Seifert, Rich, "The Switch Book", Wiley & Sons, New York, 2000, pp.
74-83

[2] ISO/IEC 15802-1, Information Technology - Telecommunications and
information exchange between systems - Local and metropolitan area
networks - Common specifications - Part 1: Medium Access Control
(MAC) service definition, 1995

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 9 Jan 2001 22:11:55 -0800

>nor VLANs 

Can you explain this statement? What is needed to accomplish this 
within the protocol, other than forwarding of VLAN-tagged frames 
and BPDUs?

---

From: James Carlson <[email-masked]>
Date: Wed, 10 Jan 2001 08:48:24 -0500 (EST)

> within the protocol, other than forwarding of VLAN-tagged frames 

The draft in question explicitly calls out only untagged Ethernet
frame formats.  I agree, though, that it would certainly be a minor
modification to add VLAN support (or remove the reference to a
protocol [sic] field).

For STP, where do the segment and bridge identifier numbers come from?
Is this link considered a half-bridge arrangement or a LAN segment?
At a guess, I'd suppose that this information is intended to be
statically configured in some implementation-dependent way.  In any
event, that's more likely to cause difficult to handle
interoperability problems than BCP's negotiation model.

Similar concerns have been raised here before:

http://www.diameter.org/cgi-bin/lwgate/L2TP/archives/l2tp.archive.0101/date/article-0.html