Subject: RE: L2TP charter

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

>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.

This is not a correct assumption.

>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.

Having worked in the engineering groups of three large
networks, and still being involved with some of those
networks, as well as others, I assure you that inter-
domain QoS isn't high on anyone's priority list today.
Nor is inter-domain MPLS, for that matter.

>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. 

Eh?  I think you're a bit confused here.  TE isn't
required, and it's clearly a bit difficult to accomplish
in only DA-based packet networks (i.e. IP networks).

>The only 
>thing that L2TP would provide over static configuration 
>is a small amount of handshake.

That small amount of handshake, coupled with the AVP 
concept and the other call management stuff makes it
an ideal choice for circuit emulation over IP.  Much,
much more desirable than IP.  If it were really as 
simple as you say, we wouldn't need L2TP, we could 
just use GRE, no?

>No new working group is needed.

If not, then at least a considerable more amount of
work is. 

>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).

Cute.  You're obviously missing the point of why GRE
is not the answer.  It requires more than an encapsulation
protocol.

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

You've still not explained to me how a simple Encapsulation
Protocol such as GRE performs these functions?  Why, is that?
 
>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.

Ahh, and add additional network overhead, and packet processing,
for that matter -- all unnecessary.  I guess with enough glue 
you could do anything.

>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.

Manually configured, yes.  Long history as hacks, yes.
So you do see the point -- maybe?

>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.

You're still missing the point.  L2TP provides the 
dynamic call capabilities that ISPs want.  Not a 
bunch of unmanageable GRE gunk.  

Putting it over PPP would obviously work, though this 
increases network overhead significantly with no obvious 
benefit.  

L2TP is clearly the place to do this.  If requires the
least amount of work and working implementations have 
been demonstrated.  

-danny

---

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

> in only DA-based packet networks (i.e. IP networks).

It is required if you hope to emulate Frame Relay's advantages to any
extent.  Yes, it's difficult, but, no it's not impossible in a
hop-by-hop network.

That's beside the point.  If you use L2TP, you'll *still* have to
manually configure the tunnel endpoints.  You'll need to give the LAC
a list of LNS addresses to use for each endpoint in some way.  One way
to do this would be to propose RADIUS extensions to translate, say,
X.121 addresses into IP addresses needed for L2TP.  This is precisely
the same amount of work that's required to make the existing IP-GRE
tunneling mechanism function in the same way.  There's no difference
between the two, and the AVPs still don't provide a benefit for this
application.

> simple as you say, we wouldn't need L2TP, we could 

The AVP concept and the existing call management stuff are useful for
the case where you've got many PPP users needing to be tunneled to
various locations based on details available within the PPP
authentication protocols.  They don't much help you to do anything
useful otherwise.

If you believe that these L2TP features are helpful in some way, it
would be helpful to see a written proposal.

> Protocol such as GRE performs these functions?  Why, is that?

Two reasons.  First, for new features, the burden of proof is always
on the claimant.  Because you're suggesting that L2TP be extended for
this new purpose, that happens to be you.  Second, the use of GRE for
tunneling arbitrary protocols is already well described in RFCs 2784
and 1701.

> for that matter -- all unnecessary.  I guess with enough glue 

The additional overhead is (with both ACFC and PFC negotiated) exactly
one octet representing the PPP protocol number.  In the worst cast, if
you don't negotiate those options for some reason, it's at most four
octets.  In comparison with deploying yet another protocol extension,
that's not much of a burden.

If that is a burden for some particular application, then I'd suggest
that IP is unnecessary as well.  Run in ships-in-the-night mode, and
you'll be better off.  You'll discard 20+8+4 = 32 octets over L2TP in
that manner.  That's a much bigger win than avoiding PPP's overhead.

> So you do see the point -- maybe?

No.  You'll still need manual configuration with L2TP unless you're
proposing extensions to many other protocols as well.

> dynamic call capabilities that ISPs want.

No, it doesn't.  L2TP has no general tunnel endpoint locator
mechanism.

>  Not a 

L2TP data transport is just GRE gunk.

> increases network overhead significantly

How is one octet of overhead per packet considered significant?
What's the context in which this is true?

> with no obvious 

The obvious benefit is that *no new extensions* are required.  At
least in the standard IETF balancing act for such things, that's quite
a significant benefit.

> least amount of work and working implementations have 

It requires extensions and duplicates features already available in
existing protocols.  I don't think you've made the case that L2TP is
clearly the place to supply tunneling facilities all for possible L2
or L3 protocols.

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

---

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

> that manner.  That's a much bigger win than avoiding PPP's overhead.

Fingers moving faster than brain -- that should be "discard a minimum
of 20+8+6 = 34 octets (plus four more if sequencing on the data
channel were used)."

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 27 Jul 2000 14:56:55 -0700

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

> X.121 addresses into IP addresses needed for L2TP.  

I believe that this could be done with existing attributes from RFC 2868.

<text deleted>