Subject: L2TP - PPP encapsulations and LCP renegotiation

From: William Palter <[email-masked]>
Date: Thu, 12 Feb 1998 21:58:47 -0800

I think we are losing a little perspective on what we set out to
do and what we have already achieved. We set out to try and merge L2F and
PPTP incorporating the best features of both, and to  get the specification 
done quickly so that we would not end up with three standards and need to 
support all of them in every implementation (in order to be competitive).
We have also had two successful backoffs in between which we have done 
some tweaking to the protocol, the next backoff is scheduled in less than 
two weeks. 

	LCP renegotiation really falls into 4 cases, these cases are

	1) Client and LAC in the same box, an example of this is 
	   voluntary tunneling in windows NT, in this case the 
	   PPP client should have enough knowledge about the fact that
	   it is being tunneled thru L2TP that it should negotiate 
	   appropriate options with the LNS (since it knows that there
	   really is not physical layer PPP session).

	2) LAC negotiates LCP and then forwards the session. In this case
	   the LNS should be able to get enough info from the proxy LCP 
	   info that if it renegotiates LCP it can use options that are
	   compatible with the LAC.

	3) HDLC/AHDLC client dialing into a LAC and being forwarded to 
	   an LNS without LCP being negotiated by the LAC. When this
	   occurs the LNS needs to be conservative in what it negotiates
	   with the client, but we have shown inter operability with the 
	   in the past two backoffs. 

	4) non-HDLC type clients connecting to a LAC being forwarded to 
	   an LNS. This is the real sticky case, since the LNS really 
	   has no idea what LCP options to negotiate with the client,
	   but I think that if the LNS is conservative in what it does 
	   and takes some hints from the client, we should be able to 
	   inter-operate. We really haven't had any experience in the 
	   previous backoffs with this case.

	As for framing in the data packets, we choose basicly the HDLC 
	type framing that most PPP clients support with the assumption that
	LACs could do some simple framing conversion if it were needed, if
	we had to do it again I believe that we probably would have chosen
	to strip the 0xff 0x03, move the protocol field into the L2TP header,
	and just send the data part of the PPP packet, if we knew then what 
	we know now. But changing this now would break a lot of the interop
	that we have already done.

	If we decide at this point to go back and try to build a protocol 
	that can tunnel and support every possible combination of LCP options
	(such as different FCSes or COBS or anything else that maybe dreamt
	up) we will end up needing a few more backoffs and probably will end
	up publishing this draft after its usefulness has passed. 

Bill Palter

---

From: Philip Rakity <[email-masked]>
Date: Thu, 12 Feb 1998 22:54:06 -0800 (PST)

Bill,

> 	   in the past two backoffs. 

This can be fixed by either passing the MRU information etc to the LNS or
specifing options in the specification that make this work.  The question
is what is the correct approach to resolve the problem; eg DEFINE
conservative.

> 	that we have already done.

This the problem that the interoperability testing is supposed to
show up.  

Why not define the message flow between the LAC and LNS that are
needed to fix this problem, then define the default action, that occurs
when NO messages are passed.  The default action maps the current
implementations and the messages define the action that a full function
LAC/LNS will implement.  The interoperability test session can validate
the draft without the message exchange.  If we add text to the draft NOW
to handle the message exchange, then some of us might be able to test this
at the interoperability test session.  (We are prepared to put code into
our system to deal with this), and if we can interoperate with other
folks, then we can move the draft towards an RFC number.

---

From: Brian Lloyd <[email-masked]>
Date: Fri, 13 Feb 1998 10:20:00 -0800

At 21:58 -0800 2/12/98, William Palter wrote:

Everything you have written up to here makes sense to me.

>	that we have already done.

You just stated the key factor, "if we knew then what we know now."  OK,
you know it now.  You know that the assumptions originally made were
flawed.  You know where the flaw is.  FIX IT!  Don't screw around moaning
about interoperability testing that has already been done.  FIX IT!  DO IT
RIGHT!  Then go back and do new interoperability testing.  That is how you
end up with good protocols with logical, straight-forward implementations
instead of hacked up kludges that don't always converge, aren't likely to
interoperate without case-by-case tweaking, and won't adapt to new
technologies when the appear.  Failure to "do the right thing" is a support
nightmare.

>	up publishing this draft after its usefulness has passed.

What is going on here?  Do we have marketing people running the IETF
instead of engineers who write code?  (Gawd, I am starting to sound like
Bill Simpson.  Someone please shoot me now.)  Is the new attitude, "it is
more important to get it out than to get it right?"  Yeah, I guess it then
becomes the customer's problem.

Well, I believe that it should be possible to define the protocol generally
correctly in a week or two.  We will need a couple of implementations to do
preliminary testing which may result in tweaking the protocol.  We get a
few more people to implement the tweaked protocol and we do another
bake-off.

So you are worried about the different kinds of point-to-point framing you
may run into out there and and in the future.  If that is your concern,
then isolate the framing to the link layer and don't propagate that back up
the stack to the network layer.  Now if someone comes up with a new way of
framing data over the link, the network layer doesn't need to worry about
it.  Problem solved.

OK, how about it stated in more detail.  The problem is that the LNS really
shouldn't have to know about what is going on down at the LCP layer.  The
LAC and the remote host negotiate the framing options because they know
what the hardware looks like and know the requirements for the local link.
Once that happens the LCP layer in the LAC communicates with the
authentication/MP/NCP layers (phases?) in the LNS via L2TP and says, "you
have a good pipe over which you may exchange packets with the remote
client."  Now your PPP "network layer" packets consist of a PPP payload
preceeded by a protocol ID field.  There is no framing cruft that needs to
go back and forth because the envelope you are using; e.g. UDP, FR, or
X.25; provides complete delineation of the payload boundaries.  So if you
don't need to send extra cruft, don't send it.

<sigh> The fly in this ointment is the fact that the LCP layer also offers
the MP MMRU option to indicate that the virtual NAS (I want some different
name here to denote the system that is the logical fusion of LNS and LAC)
offers and supports MP.  That means that the LAC needs to know ahead of
time that the LNS is prepared to support MP.  I had this ugly little
feeling in the pit of my stomach several years ago that piggybacking the MP
option as part of the LCP negotiation (read "gross violation of layering")
would come back and bite me some day.

And let me reiterate one thing: just because you have code ready to ship
doesn't mean that you should ship it if it is wrong or that you won't ship
updates becuase you have learned something new or better.  Think about it,
solve the problems, roll new code, and then test it.  Repeat until it is
right.

Where the heck is our WG chaircritter?  Karl, you should be doing this
yelling about the meta issues, not me.  You've been there.  Please tell
them; how many times did you change your PPP code at Morningstar while we
were working out the problems with the base PPP spec?  How many times did
you ship updates to your customers because we discovered that we needed to
change something based on experiential data?

Folks, just because you have code out there doesn't mean you can't change
your code for the better.  Do you best to support backward compatibility
but don't be slavish about it.  If you have to abandon an older version of
a protocol because it is completely incompatible with the correct version
of a protocol, sobeit.

I apologize for jumping back and forth between the technical issue(s) and
the meta issue.  This message was stream of consiousness.  Hopefully this
makes sense to people.

Brian Lloyd                                    Lucent Technologies
[email-masked]                       3461 Robin Lane, Suite 1
http://www.livingston.com                      Cameron Park, CA  95682
+1.530.676.6399 - voice                        +1.530.676.3442 - fax    O-

---

From: Tim Kolar <[email-masked]>
Date: Fri, 13 Feb 1998 11:01:09 -0800 (PST)

Brian Lloyd writes...
> becomes the customer's problem.

The IETF risks finding itself sidelined if it can not operate in a timely
fashion.  I don't believe anyone on this list wants to see that, which is
why you're starting to see some urgency around getting the spec out.

The L2TP draft has long since satisfied its original goal of blending L2F
and PPTP into something workable.  In my opinion, we hit the point of 
diminishing returns sometime last March.

Part of being a good engineer is knowing when to stop fiddling with something
and ship it.  You build in extensibility (we have), you think through 
possible problems (we have), then you bite the bullet and expose your work
to the world.

-Tim

---

From: Philip Rakity <[email-masked]>
Date: Fri, 13 Feb 1998 11:16:02 -0800 (PST)

> possible problems (we have), then you bite the bullet and expose your work

Part of good engineering is knowing when to fix problems that show up
rather than pretend that they do not exist.  If the spec was so good last
March, why hasn't yet obtained an RFC number.  BTW, when was the 1st/2nd
interoperability kitchens for L2TP ?`

On another note, we have put a proposal on the table to help fix the draft
so that it can go forward.  I am still waiting for an e-mail to take up
the offer.

 Philip Rakity
FlowPoint

---

From: Tim Kolar <[email-masked]>
Date: Fri, 13 Feb 1998 11:29:13 -0800 (PST)

Philip Rakity writes...
> March, why hasn't yet obtained an RFC number.  BTW, when was the 
> 1st/2nd interoperability kitchens for L2TP ?`

It has not obtained an RFC number due to bickering over the details
of an endless stream of "vital" additions to the basic protocol.

Bottom line:  L2F works for what it was intended to do, and is 
functioning fine in the field.   PPTP works for what it was intended to
do, and is also functioning in the field.

L2TP in the meantime has gone way off into the weeds.  As a developer,
I know where to devote my time.

-T

---

From: Brian Lloyd <[email-masked]>
Date: Fri, 13 Feb 1998 14:10:32 -0800

>why you're starting to see some urgency around getting the spec out.

The IETF is recognized as an international standards body because it gets
work done and the work has, in the past, been of high quality, i.e. the
protocols actually worked and did what they are supposed to do.

I do not believe that the IETF will collapse because we feel that there is
a problem in the L2TP draft and need to put in a couple more weeks to try
to fix the problem.

>diminishing returns sometime last March.

I remain unconvinced that it is workable but then I haven't finished the
draft doc.  So far, what I see does not raise my expectations.

>possible problems (we have), then you bite the bullet and expose your work

Good.  I am part of the world.  I have been here before a couple of times
so I can put myself in your shoes.  If it appears right, or perhaps I
should say "best compromise," to me, I will say so.

The yardstick is, "rough consensus and working code."   I can tell you
right now you don't have "rough consensus."   If the protocol were indeed
"best compromise" you would probably have rough consensus.  There will be a
bake-off in about 10 days.  Maybe you will have universal "working code"
then.  Until then, I would certainly petition our Fearless Leader to hold
off on advancing this draft to Proposed Standard.