Subject: LAC -> LNS Interaction Problem (LCP)

From: Philip Rakity <[email-masked]>
Date: Tue, 17 Feb 1998 11:41:30 -0800 (PST)

Mark,

A number of folks have raised significant issues with L2TP concerning the
interaction between the LAC/LNS.  I was wondering is you have some
suggestions on how we should proceed.

I have copied to e-mails below for your information.

kind regards,

Philip Rakity

============================================================
>From [email-masked] Tue Feb 17 11:36:26 1998
Date: Thu, 12 Feb 1998 22:54:06 -0800 (PST)
From: Philip Rakity <[email-masked]>
To: William Palter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: L2TP - PPP encapsulations and LCP renegotiation

Bill,

On Thu, 12 Feb 1998, William Palter wrote:

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

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.

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

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.

> 
> 
> 	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 [email-masked] Tue Feb 17 11:36:54 1998
Date: Fri, 13 Feb 1998 10:20:00 -0800
From: Brian Lloyd <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: L2TP - PPP encapsulations and LCP renegotiation

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

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

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

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.

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

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: "W. Mark Townsley" <[email-masked]>
Date: Tue, 17 Feb 1998 15:55:50 -0500 (EST)

> suggestions on how we should proceed.

Phillip,

I am well aware of the issues that have been raised recently.  While away
last week, I left my voice on draft issues in the capable hands of Andy
and Bill. I have been giving some of these issues more thought since my
return and would like to come up with something that is workable but does
not derail the spec. I consider the latter of signifigant importance.

How should we proceed? As we always do, by writing code, getting together,
and giving things a whirl. We have overcome more signifigant problems in
the past, and assuming it does not float away in the rainstorms, we will
all be in San Francisco next week to talk about them in person. In
general, I think it foolish to change the spec one or two weeks before an
interoperability bakeoff. We have had months, even years, to discuss these
items. It is bothersome that they are appearing this late in the game. As
has been stated, at some point you have to bite the bullet and move on. 

I would also echo Richard's remarks that some of the items discussed this
past week are intractable by nature and as such are important to be noted,
but do not affect the protocol message exchange per se. On these items, I
think enough has been said.

- Mark

---

From: [email-masked]
Date: Wed, 18 Feb 98 09:42:13 +0100

I think all problem comes from to points:
     
     1- PPP is allowed to renegotiate LCP parameters whenever It wants
     
     2- L2TP is physical medium dependent.
     
     Each behavior by itself is not really a problem, but both together ....
     
     I see a solution which keep L2TP draft almost like it is and also 
     touches PPP:
     
        1- A new LCP option extension could be introduced. This option 
     forbids new LCP negotiations for all PPP connection life. New LCP 
     parameters imply to close and reopen PPP.
     
        2- AVPs:
     
               Initial Received LCP Confreq
               Last Sent LCP Confreq
               Last Received LCP Confreq
     
               MUST appear in Incomig-Call-Connected message. 
     
      Last Sent and Received LCP Confreq are modified to include new LCP 
     option forbiding new LCP negotiation. LNS will keep initial parameters 
     negotiated by the LAC.
     
        This solution forgets that maybe MRU negotiated by the LAC can not 
     be supported by LNS. In that case LNS should close session suggesting 
     new MRU to the LAC, This MRU value should be borne in mind by the LAC 
     in the next LCP negotiation.

     IMHO
     
     Carlos

____________________________ Séparateur Réponse ________________________________
Objet : LAC -> LNS Interaction Problem (LCP)
Auteur :  pmr ([email-masked]) à SMTP
Date :    17/02/98 20:41

Mark,

     
kind regards,
     
Philip Rakity

Bill,

     

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.

     

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

---

From: Richard Shea <[email-masked]>
Date: Wed, 18 Feb 1998 08:48:05 -0500

[email-masked] wrote:
[..]

Note: I answered this email on the L2TP list but didn't copy ietf-ppp in
order to contain the conversation and cut down on repeat emails for most
of the people involved.

Richard.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Richard Shea                                  [email-masked]
Bay Networks, Extranet Access                     978-266-1011 x210