Subject: Re: LCP renegotiation

From: Richard Shea <[email-masked]>
Date: Thu, 12 Feb 1998 18:44:46 -0500

Philip A. Prindeville wrote:
[..]
> 
> I think you are being naive.  As you go up the ISO reference
> model it gets easier to abstract things away because the lower
> layers are designed to deal with such details.
> 
> The news is:  *we* are at the lower layer.  These are the issues
> that we have to concern ourselves with so that no one else will
> have to.
> 

Well, the TCP-like abstraction is certainly an ideal which we can't
achieve at this level, as you point out.  My point was that L2TP could
be defined to attempt to contain the more physical-level characteristics
of the link to the end with the actual physical connection (i.e. the
LAC).

If we changed L2TP to differentiate HDLC and non-HDLC sessions at the
LNS, then the LNS would be able to satisfy the ACF handling for HDLC
links; And for non-HDLC links the LNS would just not include ACCM or
ACFC options, and not prepend the ACF on any packets it sent out (nor
expect to receive them!).  Then, as long as all of the PPP-over-X
protocols can take care of framing at the LAC and simply forward
rfc1661-style PPP frames between the LAC and LNS we are all set.

I don't yet understand (which may be entirely my fault!) why this
wouldn't be effective.

If in the future some portion of PPP framing has to be known at the LNS
then we can add in that functionality to the L2TP protocol at that time
(fairly simply).

Richard.

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

---

From: Rick Sewill <[email-masked]>
Date: Thu, 12 Feb 1998 17:27:11 -0800 (PST)

Richard,

I think we should combine what you have been saying with what Brian Lloyd
has been saying.

I believe the LAC should be in charge of Link Layer functions, i.e., the
LAC should tack on the ff03 on output to the client if HDLC, and remove
the ff03 on input from the client if HDLC.  Similarly, a LAC supporting
PPP over ATM should pass the data between the client and LNS transparently
if VC-Multiplexing is used;  and should tack on/remove the fefe03cf if
LLC-Multiplexing is used.

The LAC should tell the LNS in an AVP what the LAC can do (if the LAC
offers the LNS more than one choice) or will do (if the LAC offers the LNS
only one choice).

The LNS will negotiate with the client, and when it comes to link layer
items, use the values recommended/required by the LAC.

The LNS will tell the LAC in an AVP the link layer items that were agreed
to and leave the dealing of link layer items to the LAC.  

This seems, IMHO, a reasonable way to resolve the questions of MRU size,
ACCM, ACF, HDLC v.s. ADSL v.s. the next ppp protocol over whatever media,
and resolve a substantial technical concern with L2TP.

I will now run for cover in a bomb shelter while the tunneling begins.

-Rick