Subject: RE: L2TP charter

From: Danny McPherson <[email-masked]>
Date: Wed, 26 Jul 2000 14:33:14 -0700

I'm obviously OK with that :-)

-danny

> Perhaps the investigation can be made quickly and 
> we can move towards your text.

---

From: Barney Wolff <[email-masked]>
Date: Wed, 26 Jul 2000 20:36:40 -0400 (EDT)

I'd like to register skepticism on extending L2TP to tunnel other
things.  Primarily, I'd resist with vigor any attempt to make
"L2TP standard compliant" depend on support for anything but PPP.
Dunno if the proponents really intend that, but the proposed
charter language makes me a little paranoid.

Secondarily, I'd really like to hear why X needs to be carried over
L2TP, rather than over whatever X is carried over today.

Barney Wolff

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 27 Jul 2000 17:15:31 -0700

At 04:41 PM 7/27/00 -0700, Danny McPherson wrote:
>
>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.

Read rfc2107 for a solution that implements a signaling mechanism
for GRE that negotiates a 'tunnel ID'.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 27 Jul 2000 18:20:09 -0600 (MDT)

> From: Danny McPherson <[email-masked]>

> ...
> -*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 is in a different universe.

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

Those points are not mutaual consisttent.

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

The first seems to me to assume characteristics of L2TP that do not exist.
The second is content free.
The third is both wrong and a red herring.

> -*Other issues?
>
> L2TP provides for ease of implementation in hardware as the 
> switching can be done based on Tunnel and Session ID.

Ditto for all of the others.

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

ditto.

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

ditto.

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

Assumes conclusion. 

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

ditto.

L2TP is a very sick protocol that has been almost wrecked
by exactly such accretion as this proposal.  L2TP started out
as a simple thing to solve a couple of known problems that
already had more or less proprietary solutions.   Look at the
mess it has become.
For that matter PPP has a similar history.

The last thing the IETF needs is yet another tunnel protocol.
We already have at least half a dozen (not counting such as IP/SMTP).
Intellectual honesty requires admitting that the proposal
is yet another tunnel protocol, even if it is cloaked in L2TP colors.

See for another such story.
http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers

Vernon Schryver    [email-masked]

---

From: Danny McPherson <[email-masked]>
Date: Thu, 27 Jul 2000 19:30:48 -0600

>Those points are not mutaual consisttent.

Not following you here?

>The first seems to me to assume characteristics of L2TP that 

Which are proposed in our draft, have you read it?

>The second is content free.

Though makes a point --  if another higher-layer protocol
that resides parallel to PPP and performs the same (and 
more functions for the application), it doesn't make sense 
to use PPP as well.

>The third is both wrong and a red herring.

Care to clue me in here?

>Ditto for all of the others.

Please do elaborate on other IP-based tunneling protocols that 
provide this support (other than ATMP -- for obvious reasons).

>> implementations as they can reject Service Type AVP.

Ditto what?
>> network (either DiffServ, MPLS or others), and not a function 

Uh, yeah.

>> subscriber management tunneling already.

Not following you here?

>For that matter PPP has a similar history.

I suppose you'd prefer to develop a new protocol for every 
tiny new enhancement?  Not happening...

>The last thing the IETF needs is yet another tunnel protocol.

My Point!

>Already have at least half a dozen (not counting such as IP/SMTP).

IP/SMTP, stretching now aren't we...

>is yet another tunnel protocol, even if it is cloaked in L2TP colors.

How exactly does a single new AVP (similar to "bearer" one on the
2661bis draft) create an entirely new protocol here?  Given, the 
LAC-LAC model is new, though it's as much a semantics issue.

-danny

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 27 Jul 2000 21:45:14 -0700

At 09:24 PM 7/27/00 -0700, Andy Koscinski wrote:
>I would advise against using the tunneling
>as defined in the rfc2107 for the purpose
>of circuit emulation over IP on the following counts:

I was not suggesting that you use 2107 as is because it doesn't do
what you want, just like L2TP doesn't do what you want either.

What I was trying to show is that there are ways to add a signaling
mechanism to GRE. 2107 is just an example. It is not the solution to
all problems, just like L2TP isn't either. And yes, it has some
limitations, just like any other protocol does.

Regarding the status of the "Key" field, I suggest you read
draft-dommety-gre-ext-04.txt. If you want to hear more about the
status of GRE, you can subscribe to the gre mailing list at
[email-masked].

---

From: Andy Koscinski <[email-masked]>
Date: Thu, 27 Jul 2000 22:49:45 -0700

> -----Original Message-----
> From: Ignacio Goyret [mailto:[email-masked]]
> Sent: Thursday, July 27, 2000 9:45 PM
> To: Andy Koscinski
> Cc: Ignacio Goyret; Danny McPherson; [email-masked]'
> Subject: RE: L2TP charter
> 
> 

andyk> but L2TP is very close to support circuit emulation over IP,
much closer than GRE, on the follwing counts:

1. GRE rfc2784 does not specify any end to end signaling
for tunnels or sessions
2. The key field (tunnel id) has been removed in the text of 
the rfc2784 in 3/2000, I quote:
"the GRE header will never contain the
 Key, Sequence Number or Routing fields specified in RFC 1701."

> mechanism to GRE. 2107 is just an example. 

andyk>L2TP rfc 2661 is in my opinion a better example of signaling 
to follow, as suggested by the "informational"
and temporary rfc2107 itself ("There is ongoing effort in an IETF 
working group which could 
result in a standards track document which specifies a protocol 
which provides similar functionality.")

> draft-dommety-gre-ext-04.txt. 

andyk> I follow:

3. In 3/2000 there was a rfc 2784, removing the key field (with 
the tunnel id) "forever" (I refer to (2) above).

4. in 6/2000 there was the "draft-dommety-gre-ext-04.txt" asking
to re-introduce the key field again (sic!). This draft was submitted
at the same time (6/2000) the draft "draft-mcpherson-l2tp-es-01.txt",
(which is under discussion here) was submitted. How can you expect
the "draft-mcpherson-l2tp-es-01.txt" take an example from a not
yet published "draft-dommety-gre-ext-04.txt", rather than from
rfc 2661?

Regards,

[email-masked]

---

From: Danny McPherson <[email-masked]>
Date: Fri, 28 Jul 2000 15:03:49 -0700

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

Perhaps the benefits will become clear when we post the referenced ESP
draft.

> RSVP and CR-LDP, q.v.

However, both are still orthogonal of MPLS.

> 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 Myles's
> signaling capabilities.)

As for your arguing, I'm sure you will.  Though I'm more concerned with
reality and service provider requirements :-)

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

Though you've omitted the most obvious benefit of L2TP here -- it's IP
tunneling capabilities.  Something that clearly can't be provided in the
scenario you describe.  

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

Though this is in addition to the state machine and other issues.

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

Simply because you know if few implementations is no indication that they
don't exist.

> Same is true for PPP.

Hopefully, the ESP draft will make things clearer.  If not, I'm sure we'll
continue the discussion.

-danny

---

From: Andy Koscinski <[email-masked]>
Date: Fri, 28 Jul 2000 18:00:57 -0700

> From: Thomas Narten [mailto:[email-masked]]
> Sent: Friday, July 28, 2000 3:46 AM
> To: Andy Koscinski
> Subject: Re: L2TP charter 
> 
> 
> > 1. the "tunnel id" is not supported by the GRE any more:
> > The tunnel id was carried in the "key" field of the GRE 
> tunnel packets
> > as defined in the RFC1701 (10/1994). The "key" field has 
> been removed
> > from the newest GRE RFC2784 (3/2000), quote from RFC2784:
> > "the GRE header will never contain the Key, Sequence Number 
> or Routing 
> > fields specified in RFC 1701".
> 
> See draft-dommety-gre-ext-04.txt, "Key and Sequence Number Extensions
> to GRE". That document has been approved by the IESG as a Proposed
> Standard and is in the RFC Editor's publication queue.
> 
> Thomas
>

1. In 3/2000 there was a rfc 2784, removing the key field (with 
the tunnel id) "forever", I quote: "the GRE header will never 
contain the Key, Sequence Number or Routing fields specified in RFC 1701."

2. in 6/2000 there was the "draft-dommety-gre-ext-04.txt" asking
to re-introduce the key field again. 

Could you please help understand why such frequent changes?

Regards,

[email-masked]

---

From: Andy Valencia <[email-masked]>
Date: Sun, 30 Jul 2000 08:53:05 -0700

Glen Zorn ([email-masked]) writes:

>> L2TP was done because two other proprietary mechanisms -- L2F and PPTP
>> -- were getting market attention.
>Interesting 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?

The original protocol spec which became L2F was indeed PPP over GRE.  We
decided to deviate from GRE because there were some pretty major changes
(dynamic tunnels, and a bunch of signalling for instance) which didn't seem
appropriate to paste on top of a stable protocol which was already doing
what it was designed to do.  We also looked at doing PPP-over-PPP, with L2F
being a new NCP.  But again, things we wanted to do (running multiple
sessions over one tunnel) were pretty dissimilar to what PPP was designed to
support.

So if we "stayed with" GRE, but mutated it (perhaps dramatically), would we
be ahead of the game as compared to making Yet Another Tunneling Protocol?
Obviously, we thought not.  And if I were doing it over again, I still would
choose to leave GRE alone, rather than force a bunch of complexity onto a
nice, simple tunneling mechanism.

Andy Valencia
[email-masked]