Subject: L2TP charter

From: Danny McPherson <[email-masked]>
Date: Thu, 27 Jul 2000 16:41:03 -0700

OK, let's try this again....

-*Why not use GRE instead of L2TP?  

For starters, if you're of the opinion that GRE is 
sufficient, perhaps reflecting on the initial justification 
of L2TP itself would be of benefit?  That is, why were PPP 
PDUs not tunneled through GRE?  The same advantages L2TP 
brought to PPP can be realized with non-PPP payloads as well,
with little work.

GRE provides only an encapsulation scheme, it provides no 
end-to-end signaling mechanism.

GRE does not generate a Tunnel ID, which can be used to 
assist with processing tunnel payload in hardware.

L2TP allows aggregation of large number of sessions into 
a single tunnel.  This helps to scale the management of 
total number of user sessions in the network.  The ADSL 
forum's proposal of L2TP over AAL5 is an excellent example 
of reducing the number of VCC's in the network.

-*Why not use MPLS?

The intent is to provide a generic tunneling mechanism for
IP networks.  Seamless integration with MPLS is then 
trivial.

An MPLS-based mechanism requires -- MPLS.

MPLS doesn't provide an end-to-end signaling mechanism.

-*Why not do it over PPP?

PPP doesn't provide sufficient parameter capabilities to 
support circuit emulation services (e.g. negotiation of 
specific frame relay or ATM parameters).  As a result, 
another protocol has to be developed.  With both, an 
unnecessary, unclean overlap in function occurs.  This 
quickly became obvious when we were implementing it.

Also, requiring PPP to use L2TP simply isn't clean 
architecturally.

In addition, unnecessary PPP overhead results.  Overhead from
PPP negotiation, it's state machine, and network overhead from
header bytes.

-*Other issues?

L2TP provides for ease of implementation in hardware as the 
switching can be done based on Tunnel and Session ID.

Current proposal is completely inter-operable with existing 
implementations as they can reject Service Type AVP.

The preservation of QoS for L2TP is a function of what's in the 
network (either DiffServ, MPLS or others), and not a function 
of L2TP itself.

L2TP provides a common, well understood mechanism for unifying 
subscriber management tunneling already.

The proposed model doesn't require an intervening LNS.  It 
provides direct LAC - LAC support.

It's obvious that every model will require some configuration.
The amount required, however, is a key component of the value
proposition.

---

From: James Carlson <[email-masked]>
Date: Fri, 28 Jul 2000 17:01:35 -0400 (EDT)

> brought to PPP can be realized with non-PPP payloads as well,

L2TP was done because two other proprietary mechanisms -- L2F and PPTP
-- were getting market attention.  Yes, PPP over plain GRE is quite
feasible.  One thing addressed by L2TP is that you bring the PPP
session half-way up, and it's commonly believed that you need some
non-PPP way to transfer the negotiated parameters to the peer.

Of course, that's not quite true.  We could have defined proxy
operations such that they'd work without the L2TP mechanisms.  That's
not what was done.

In the case of putting other protocols over L2TP, especially
protocols above layer two, it's much harder to make the argument that
L2TP provides any noticable benefit.  Would you, say, start doing X.25
call control, stop halfway through, and then tunnel the call control
over the Internet?  If so, then L2TP almost makes sense.  Otherwise, I
don't see how it helps this particular application in any way.

> MPLS doesn't provide an end-to-end signaling mechanism.

RSVP and CR-LDP, q.v.

> another protocol has to be developed.

PPP does indeed negotiate L3 capabilities.  That's the whole point of
PPP.  If you really do need a new L3, this can be added to PPP.  (Of
course, once you do, I'll argue that running MPLS over PPP and CES
over that is better still, since you can take advantage of MPLS's
signaling capabilities.)

Doing it in PPP means that you'll automatically run over everything
else as well, without requiring L2TP.  For instance, it would be handy
to be able to run CES over PPP over SONET.  Interposing L2TP adds
*quite* a lot of overhead, even if you remove PPP.

>  With both, an 

Sorry, don't see it.

> Also, requiring PPP to use L2TP simply isn't clean 

That doesn't make sense.  L2TP was explicitly designed for PPP.

> PPP negotiation, it's state machine, and network overhead from

Again, you're complaining about another 1 to 4 octets of PPP overhead
versus 36 or more for L2TP.  Removing the former helps only a little
and hurts a lot.  Removing the latter helps quite a bit more.

Another way to look at it is that putting this in L2TP solves only a
few vendors' problems.  Putting it in PPP solves more.

> switching can be done based on Tunnel and Session ID.

Variable-length headers -- such as the GRE header used for L2TP -- are
a pain in hardware.  I know of few high-speed implementations.

> implementations as they can reject Service Type AVP.

Same is true for PPP.

-- 
James Carlson                                  <[email-masked]>
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 29 Jul 2000 04:41:07 -0700

James Carlson [mailto://[email-masked]] writes:

> -- were getting market attention.

Iteresting statement.  What, then, begat L2F & PPTP?  Given that cisco is
the veritable Land of GRE and PPTP uses essentially the straight GRE header,
it could hardly haave been simple distaste for the protocol.  Could it be
that vanilla GRE just didn't fulfill the requirements?

> Yes, PPP over plain GRE is quite

<text deleted>