Subject: Re: l2tp-digest V1000 #171

From: Barney Wolff <[email-masked]>
Date: Tue, 18 Jan 2000 17:05 EST

Sorry to speak up yet again, but I don't understand why this case is
unrecoverable.  The PPP client may indeed throw away the last LCP frame.
But the PPP client is then bound to retransmit its LCP Conf-Req, and the
LNS must therefore send an SLI with the default ACCMs in it before
responding.  At the end of the second round of LCP, unless the
re-ordering happens again, things will be fine.  Only if the SLI
consistently passes the LCP Conf-Ack will negotiation fail.  A transport
that consistently manages to have the SLI pass the Conf-Ack is both very
smart and very evil.

The LNS does have to send the SLI with default ACCMs, but this is not
a new requirement - PPP peers are free to renegotiate LCP at any time,
although few actually do.  If 2661 says that an L2TP "call" can have
only a single LCP negotiation, I'm not aware of it.  RFC 1661 is clear
that LCP types 1-7 must always be sent using default options, so if
tunneling via L2TP breaks that, we have a fight with the PPP folks.

Barney

> Date: Wed, 19 Jan 2000 13:19:16 -0800
> From: "W. Mark Townsley" <[email-masked]>
> 
> Ensuring your output queue is empty before applying the SLI is a good,
> cheap defense, and would probably handle many (if not most) cases. But
> we still have the reordering problem. If the SLI is received at the LAC
> before the last LCP packet, then it could get applied first. This is the
> unrecoverable case.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 20 Jan 2000 15:31:39 -0800

> Sorry to speak up yet again, but I don't understand why this case is

No apology necessary... Please, this is what makes a Working Group work.

> a new requirement - PPP peers are free to renegotiate LCP at any time,

No, not a new requirement, but something that is not obvious in the
spec. I suspect most implementations do not do this today.

> tunneling via L2TP breaks that, we have a fight with the PPP folks.

I think I like this approach better. So, we have the following
clarifications to make:

1. The LAC must send all PPP packets in its queue before applying the
ACCM received in an SLI

2. The LNS must send an SLI of 0xFFFFFFFF when LCP renegotiation begins,
and an SLI with the new value when LCP negotiation completes (this last
point is already fairly obvious in the spec).

3. The LNS should optimize sending of the SLI when possible. e.g. an SLI
should not be sent if the value within is the same as the last SLI sent.

4. It should be noted that if the SLI and last conf ack at the LNS are
reordered on the intervening network, there is the potential for an
incorrectly escaped LCP packet to be sent to the PPP client. This may
cause some PPP clients to timeout and reinitialize LCP.