Subject: Re: Rép : LAC -> LNS Interaction Problem (LCP)

From: "Philip A. Prindeville" <[email-masked]>
Date: Wed, 18 Feb 1998 12:12:26 -0800 (PST)

> From: [email-masked]
> Date: Wed, 18 Feb 98 09:42:13 +0100
> Subject: =?ISO-8859-1?Q?R=E9p_:_LAC_->_LNS_Interaction_Problem_(LCP)?=
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked],
>         [email-masked]

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

I think that anything that requires changes to the end-user's
machine is unrealistic.  The amount of time taken to update the
millions of machines out there (some of which are undoubtedly
still running Windows 3.11, or MacOS 6.0) is too long.  And an
important property of this protocol has been that, barring
severe network degradation between the LNS and the LAC, that its
presence should be transparent.

>      
>         2- AVPs:
>      
>                Initial Received LCP Confreq
>                Last Sent LCP Confreq
>                Last Received LCP Confreq

Hmmmm...  Reminds me of L2F.  (Just out of curiousity, who many of
you out there implemented L2F?  Pls. mail me off-line if you did.)

>                MUST appear in Incomig-Call-Connected message. 

This I could live with.

>       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, on the other hand, no.

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

You want to carry state over from one call to the next?  I don't
know about this....  Je ne suis pas du tout sur de cela.

-Philip

>      IMHO
>      Carlos