Subject: Re: L2TP charter

From: Danny McPherson <[email-masked]>
Date: Thu, 27 Jul 2000 08:08:43 -0600

> Layer 3 or lower?  Could I interpret this to mean SNA over L2TP or
> DECNet over L2TP?

Let me clarify -- ANY PDU Type.

> I don't understand your objection to the "heavier" baggage of other IP
> tunneling protocols.  L2TP has a default encapsulation of UDP-GRE and
> thus is heavier than IP-GRE.  There's some precedent for using IP-GRE
> encapsulation to carry non-IP payloads across IP networks.  Do we need
> another?

L2TP clearly provides what's required to support IP-based emulation services, 
tunnel management and similar are already present.  GRE has none of this.

> You're right that ISPs do want to converge services, but I don't think
> L2TP is the right mechanism for that convergence.  MPLS has much lower
> overhead, behaves in a hop-by-hop manner familiar to ATM and Frame
> Relay operators and is already quite compatible with those protocols
> and defines interworking standards, and (very much unlike L2TP) is
> already supported in core routers.  MPLS is much more suited to this
> task.

MPLS-based mechanisms require MPLS.  L2TP doesn't and can be deployed in IP 
networks, both intra-domain and inter-domain today with very little effort, or 
over those MPLS networks.

> I suggest that L2TP stick to its roots in providing tunneling support
> for dial-up network access protocols only.  This should be explicitly
> listed in its charter, along with examples of such protocols -- PPP
> and SLIP.

And then what, create yet another WG to address IP-based tunneling mechanisms, 
or extend GRE (or create a new protocol) that looks and smells like L2TP and 
provides the tunnel management hooks L2TP does, all when L2TP provide an 
elegant way to accomplish this today?  That seems senseless and wasteful to me.

> (If someone has a need to carry ARAP across a network, I'd waver and
> say that the charter is still too broad.  ARAP inexplicably requires
> MNP for reliability and might be more suitably tunneled over TCP.)

I know of at least 3 vendors today that have working code (and hardware) that 
provides L2TP hooks to support tunneling of other-than-PPP PDUs, there's 
obviously sufficient interest and L2TP was the protocol of choice of these 
vendors not after a short-sighted leap into hardware and software development, 
but rather, after an careful consideration of "what's the closest thing there 
today?".  Providing a standards-based mechanism to accomplish this -- with 
very little change, can only be of benefit.  Tons of modifications or efforts 
into beefing up yet another protocol to support this is unnecessary.

-danny

---

From: James Carlson <[email-masked]>
Date: Thu, 27 Jul 2000 10:27:18 -0400 (EDT)

Danny McPherson writes:
> MPLS-based mechanisms require MPLS.

Right.  I'm explicitly conjecturing that any major ISP that wants to
supply Frame Relay-like services will do so over his own MPLS network.

>  L2TP doesn't and can be deployed in IP 

The inter-domain problem for non-IP protocols is much bigger than just
the transport itself.  The bandwidth reservation and ordering
requirements are much taller orders to fill.  The effort, I think, is
better spent on inter-domain QoS mechanisms.

> elegant way to accomplish this today?  That seems senseless and wasteful to me.

Look at any Cisco router.  You can already configure GRE tunnels for
any protocol you like.  I can see no particular benefit from L2TP's
management or negotiation capabilities.  You'll still have to manually
configure explicit traffic-engineered paths and manually configure
associations between the tunnel endpoints.  The only thing that L2TP
would provide over static configuration is a small amount of
handshake.

No new working group is needed.

> today?".

Please don't take it personally.  Mistakes sometimes do occur, and I
believe this to be one.  As for how many folks would like to do this,
see RFC 1925, especially truths (3) and (12).

>  Providing a standards-based mechanism to accomplish this -- with 
> very little change, can only be of benefit.

No.  Where it duplicates an existing mechanism, any such proposal is
to the detriment, not benefit, of the Internet.

If you really need to use L2TP to do this, use the existing mechanism.
Run PPP over L2TP, and run your L3 protocol over PPP.  That's what PPP
is for.  It already does what you want.

>  Tons of modifications or efforts 

I wasn't suggesting beefing up any other protocol to support this.
The non-IP transport and interworking capabilities of MPLS already
exist.  The manually configured GRE tunneling capabilities already
exist and have a long history.

I'd suggest that adding these capabilities into L2TP, including the
necessary AVPs and interworking specifications, constitutes an
unwarranted "beefing up" of L2TP.  It duplicates existing PPP
functionality and provides no obvious benefit.

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 27 Jul 2000 10:43:31 -0400

> L2TP clearly provides what's required to support IP-based emulation
> services, tunnel management and similar are already present.  GRE
> has none of this.

Can you please summarize just what features are needed that are not
present in GRE (or pick your other favorite tunneling scheme)? This
has always been a bit of a gray area to me in that different folks
have different ideas about what is really needed.

I ask also because there are a number of tunneling technologies in
place, yet every WG seems seems to want to tweak its own favorite
rather than fixing one of the more general ones so that it works
properly for a broad range of applications. Case in point, GRE was
recently put on standards track because it was favored by UDLR over
something like IP in IP (which was already on Standards Track). A big
argument for GRE was that it was widely deployed/available.

I can assure you that lots of folks with tunneling needs will never
use L2TP to tunnel (say IP).  I would love to see an effort to clean
up/extend an existing tunneling mechanism to make it generally useful
to lots of applications. But I do wonder whether L2TP is the right
starting point for this.

Thomas