Subject: Re: Notes from 49th IETF L2TPEXT in San Diego

From: Danny McPherson <[email-masked]>
Date: Fri, 05 Jan 2001 11:34:07 -0700

FWIW, I hope to have ATM and FR drafts available within a 
few weeks.

-danny

> 
> > A charter revision requires consensus of the WG (which I believe we
> > have) and approval of the IESG (which needs to be done). I will post a
> > new charter to the list for presentation to the IESG.
> > 
> I agree that the best approach is to create a new charter, and have the WG and
> IESG approve it. Some text hidden in one I-D is not justification for adding
> new work to the WG.
> 
> Also, I am not really in favor of multiple options that achieve the same goal.
> If ethernet can be sent through L2TP via BCP, then I agree with James that a
> new method will only create interoperability problems in the field. If the
> authors cannot come up with an actual reason why BCP won't work, which btw
> DOES NOT require a charter change, and DOES NOT require any engineering
> efforts, then we should reconsider this work.
> 
> The goal of the WG should not be to see how long it can live, but how it can
> successfully shutdown.
> 
> PatC

---

From: Danny McPherson <[email-masked]>
Date: Tue, 09 Jan 2001 21:56:15 -0700

This is the whole intent of the "Service Type" work.

-danny

> Perhaps I've been out of the loop, but when did we decide that FR and ATM
> would be encapsulated directly within L2TP? I thought the work was to allow
> L2TP to run *over* the circuit switched networks.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 15 Jan 2001 18:06:56 -0700 (MST)

> From: Suhail Nanji <[email-masked]>

> ...
> I am not sure what you mean by "market-specific".  If you mean PPPoE
> support only, it is just one of the Ethernet protocols which may take
> advantage of EoL2TP.  For instance, the LNS could be an IP endpoint for
> Ethernet frames from a client which uses RFC1483 to communicate with a
> LAC.

> ...
> I am not arguing for this case, but this obviously does not force anybody
> to implement EoL2TP.
> ...

The reason to not get excited about this distinctly bad idea is hidden in
those two paragraphs.  The reason is that it will not matter except perhaps
in restricted, essentially proprietary cases.  In the long run, it will
be forgotten with a bazillion other premature not-really optimizations.

By the way, the stealth modification of the L2TP charter reminds
me of of the IEEE 802 and ANSI X3 standards committee politics I've
watched.  It's not nearly as bad as such genuine nastiness as
HP-Roseville's efforts to spike 100BASE-T in favor of 100VG-AnyLAN,
but it is a significant step down that road.  I don't mean to say
that the motives for the L2TP charter change are evil.  On the
other hand, the person who ruined her reputation by not doing as
the 802.3 committee voted never seemed to understand her sin.

Vernon Schryver    [email-masked]

---

From: Danny McPherson <[email-masked]>
Date: Mon, 15 Jan 2001 20:38:40 -0700

I think anyone who has read the mailing list should be aware 
of the work and ***PROPOSED*** charter modifications.  I'm not 
sure if folks were expecting a personal email directly to them 
requesting their review and acceptance of the new charter -- 
BEFORE it was proposed to the WG, but if they were, well, I
guess that's unfortunate.

There was email requesting the charter change as early as 
May of last year, from myself and a number of others.  There
were discussion last July that even you participated in.

And another discussion (I reference again for sake of brevity):

[]
Date: Fri, 04 Aug 2000 19:02:26 -0400
From: "W. Mark Townsley" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: l2tpext meeting synopsis

.....
Consensus in the meeting was that l2tpext will define only the
extensions necessary to L2TP for carrying other PDUs, within the
confines of L2TP's extensibility framework (e.g. new AVPs, but no
changes in the L2TP protocol itself). This will involve standardization
of the AVP(s) that identify the type of PDU to be carried, and new or
existing AVPs that will be used during L2TP call setup or teardown. Any
real time signaling or modifications to the particular protocol being
carried by L2TP are outside the scope of l2tpext WG. If consensus is
concurred on the mailing list, l2tp-bis and the l2tpext charter will be
revised accordingly.
.....
---------------------------------------

Because consensus can't officially be reached in the meeting, 
Mark sent the above message to the mailing list.  I'm not 
quite sure I understand what's stealthly about this?  You've 
had, umm.., over 5 months to object to this, and Mark's just 
getting around to ***PROPOSING*** the new charter wording now.
What more is it that you expect?
 
If you don't believe this work belongs here, then please let
us know why.  I really can't think of another IP-based Layer
2 Tunneling Protocol that would be more applicable than L2TP, 
especially with the dynamic tunnel and session capabilities,
extensible signaling model, trivial modifications to support
Service Types, etc..

And I'm aware of several deployed implementations that use 
L2TP for this purpose (other than PPP) today.  It just seems 
fitting, I guess, using L2TP to tunnel layer 2 protocols. 
And it also makes sense to standardize a common model for 
L2 transport over IP before lots of different models are 
deployed.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Tue, 16 Jan 2001 11:52:47 -0700

> If I recall correctly, Ethernet over L2TP was the first of these
> non-PPP cases, and inspired the service-type draft.

We'll, actually, the Service Type draft was a union of 
the EoL2TP draft and a generic model I was attempting to
define.  As such, the Service Type draft provides the 
generic mechanism to communicate payload type, it is
intended that subsequent drafts will document Service-
specific attributes.

It just so happens that the EoL2TP draft is the first of
these subsequent drafts.  Similar ATM and FR drafts will 
be available RSN.

-danny

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 16 Jan 2001 16:52:23 -0700 (MST)

> From: Rene Tio <[email-masked]>

> ...
> However, Suhail's earlier point that per-session PPP state is a serious
> limitation to scalability still stands.  Ethernet is stateless and for
> this application there is no need at all to introduce per session state
> beyond a session ID.

Don't many protoocols run above Ethernet depend on not experiencing
any re-ordering, with the notable but only partial exception of IP?
(TCP really dislikes reordering.  Other protocols just plain croak.)

Without more state than a session ID, how do you ensure that Ethernet
frames are not re-ordered?  It seems to me you need at least a timer to
detect lost packets (and probably dead sessions) and some sequence number
state.  (E.g. when you get packet #10 and then packet #12, you must not
forward packet #12 until you either receive packet #11 or a timer or some
other session machinery tells you that packet #11 will never arrive.  Or
you must always discard packet #11 if it arrives after #12.)

Given the need to keep a session ID, how many more bits do you figure are
needed?  How many per-session bits do you count in a bag of PPP per-session
state?  Isn't the big step that between 0 bit and 1 bits ofstate.

> ...
> it does, the per-session state-keeping makes this type of service all
> but useless except for small scale deployments.  Most vendors count PPP
> scalability in terms of PPP sessions.  Unless you can strip BCP/LCP of
> PPP state, no amount of simplification will suffice.

Given the need for enough state to at least detect and drop re-ordered
Ethernet frames, how much simplification would you really have?

> Just because BCP came first doesn't make it any better a protocol than
> EoL2TP.  If L2TP had been invented before BCP, EoL2TP might very well
> have come first.

On the contrary, unless EoL2TP has clear and compelling needs that
simply cannot be satisified by existing standards, EoL2TP is worse
simply because it came second and regardless of its abstract
technical attractions.  History may be inconvenient or somehow
wrong, but it is never ignored in good engineering.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 17 Jan 2001 10:09:27 -0700 (MST)

> From: James Carlson <[email-masked]>

> ...
> Then why invent a new protocol for Ethernet bridging over point-to-
> point sessions, but not invent a new protocol for tunneling in
> general?  If you're reinventing BCP/PPP, I don't see why reinventing
> L2TP is a barrier.  If you're not reinventing L2TP, I don't see why
> you should reinvent BCP/PPP.

That finally touches on the business reason why I think the L2TP WG's
everything/everything tunneling enthusiasm is misguided and doomed to be
forgotten even sooner than BACP and AO/DI were.

  - There are already plenty of IETF and non-IETF tunnelling protocols
   and products that don't involve L2TP.

  - Any tunneling product that does not cover the security checklist
   of a VPN product will eventually die.  Users will eventually figure
   out, perhaps with the help of VPN salespeople, that it is not smart
   to expose the data of applications in a tunnel that does not defend
   against snoopers or modifiers.

  - the new L2TP tunneling stuff is said to be wonderful because it
   saves 1 or 2 bits (not bytes) of per-session state.  To give it the
   features of a VPN (e.g. by running L2TP over IPSec), you must add at
   least 100 and perhaps 250 bites of per-session state in the crypto
   machinery.  It is obviously impossible to reduce that burden and not
   have encryption that can be broken in real-time.

> ...
> > Incorrect again.  These implementations will only support EoL2TP if the
> > application is a SP-to-SP (note: NOT client-to-SP) transport of Ethernet
> > frames.
>
> Vendors do not set application domains; users do.  There's no obvious
> way to contain this protocol so that it affects just the vendors who
> believe they need to have it.  It will, without question, affect many
> others.  (Myself included; I've already done PPPoE under duress.  I
> don't want to add EoL2TP to the mix.)

I disagree with both Mr. Carlson and those advocating this protocol on
that point.  Even bad ideas such as PPPoE can become popular if enough
users buy them.  However, even good ideas soon go down the memory hole if
they don't get critical mass.  There are enough existing alternatives to
these tunnelling proposals that regardless of their technical merits, they
have no future.  Any vendor that doesn't offer them first need only treat
them like BACP or AO/DI.  Put them on your checklist with a RealSoonNow
footnote and forget them.  In the short time before they're forgotten,
users won't notice their absence just as they don't notice when BACP or
AO/DI are not present.  Vendors playing that game need only tell users
"for now try this."  The only thing that users will notice that does not
work is interoperating with products that don't support the obvious,
existing alternatives.  The salespeople of the latter vendors can try to
counter that, but the proof of the pudding will make it hopeless.

> ...
> That's not at all the same as saying that this niche market isn't
> important.  It just doesn't deserve its very own little protocol.

Well, that and my words above are wrong if the niche market is created
by the salesmanship of a large enough vendor.  Examples include PPTP,
MS-CHAP, and a host of other protocols from Redmond and several
protocols from a large router vendor.  However, in such cases the
involvement of the IETF in defining the protocols is at most a charade.
If this proposal has the backing of an outfit that can make a proprietary
tunneling product survive competition with the VPN tunnel vendors, then
this whole discussion is bogus.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 17 Jan 2001 14:51:41 -0700 (MST)

> ...
> PPP is not active unless your box reboots or line gets cut and restored.
> Yes, there are methods for throttling and graceful bring-up, but the
> fact is running the PPP fsm is a non-trivial task, especially when you
> are counting outages in subscriber minutes and you're aggregating many
> tens or hundreds of thousands of subscribers.

I don't understand how anyone who understands the PPP finite state
machine can say that.  I think it is entirely false.

> ...
> L2TP is required for BCP as well, so it cancels out if we are discussing
> EoL2TP vs. BCP+L2TP.  Besides, the only place where sequence numbers
> need to be checked are on the receive path.  On the transmit the
> processing is trivial.

> ...
> Although storage is a far lesser issue than CPU cycles, it does have
> some bearing.  The FSM state requires far more than one bit to store.
> Even worse it requires many CPU cycles to run.  Multiply both by 100,000
> or more and it becomes significant.

I'm sorry, but only someone who has never written or even maintained a
reasonable PPP implementation could make those statements, because they
are false.  The CPU cycles required to run the PPP FSM's are absolutely
trivial, at least in code I've written and in code I've seen from others.
You can spend many cycles on logging, tracing, special case error handling,
and elaborating the many PPP options, but if you are short of CPU cycles,
you need not.