Subject: Re: LCP renegotiation

From: "Philip A. Prindeville" <[email-masked]>
Date: Thu, 12 Feb 1998 15:29:03 -0800 (PST)

> Date: Thu, 12 Feb 1998 16:57:01 -0500
> From: Richard Shea <[email-masked]>
> To: Andy Valencia <[email-masked]>
> CC: Philip Rakity <[email-masked]>, [email-masked],
>         ietf working group <[email-masked]>
> Subject: Re: LCP renegotiation

> I think protocols advance and don't hung up on possible futures when
> they are defined in such a way that they don't have dependencies on
> layers below or above them.  Why is TCP/IP ubiquitous?  In large part
> probably because all you need is a TCP port number and things start
> working.  TCP doesn't worry about futures of what it will carry because
> it was defined not to have dependencies on what it carries.

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.

> I honestly see it as a weakness of the protocol as currently defined (or
> at least as currently explained!) that we are even having this
> discussion.

> [ ... ]

> Again, I don't think we have to stall the protocol, it shouldn't be a
> huge change.  And may save us countless future changes and amendments
> down the road.

And I don't want to leave a possibly broken protocol as a legacy
of my hurriedness.

-Philip

> Richard.

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

---

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

Philip A. Prindeville wrote:
[..]
> that we have to concern ourselves with so that no one else will

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.

---

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

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 12 Feb 1998 18:37:02 -0800

Rick,
In four words: I like your proposal.
-Ignacio

PS: see comments below

>to and leave the dealing of link layer items to the LAC.  

We already have AVPs defined that can be used for this purpose perfectly well:
see AVP #27 and #28.

-----------------------------------------------------------------------
Ignacio Goyret, Sr. Software Engineer             Voice: (510) 747-2823
Ascend Communications, Inc.                       FAX:   (510) 747-2859
1701 Harbor Bay Parkway, Alameda, CA 94502