Subject: multilink ppp with l2tp?

From: "S.Rajesh Kumar" <[email-masked]>
Date: Wed, 4 Oct 2000 15:39:33 -0700 (PDT)

(1) Does anyone use l2tp to tunnel multilink ppp?
Any well-known issues?

(2) How does ProxyLCP work in this case? Is the LAC expected to be
the same for all links in a bundle? What if multiple links in a bundle
go through different LACs?

(3) RFC1990 on Multilink PPP suggests a mechanism of using increasing
sequence numbers on links within a multilink bundle alongwith a scheme
where a receiver can quickly detect a lost fragment. Would this break
if the ppp session (multilink) were tunneled over an IP network, with its
possibility of reordering?

Thanks
Rajesh

---

From: James Carlson <[email-masked]>
Date: Fri, 6 Oct 2000 08:40:11 -0400 (EDT)

> (1) Does anyone use l2tp to tunnel multilink ppp?

Yes; many.  Multilink is negotiated by way of LCP MRRU.  Many L2TP
implementations negotiate LCP in the LAC before ever contacting the
LNS.  This means that the caller who is trying to establish a second
link must be tolerant of getting a reject on MRRU at first (from the
LAC), followed by LCP renegotiation (by the LNS) with MRRU.  (I know
of no demand-dialing peers that are so tolerant, and I think making
them tolerant to accomodate an L2TP problem would be unwarranted.)

I think it's fair to say that MP interacts poorly with most L2TP
implementations.  L2TP is far from transparent.

(This is not true if you're not doing proxy LCP.  If L2TP is merely a
configured tunnel between the LAC and LNS, then this part of the
problem is simpler.)

> go through different LACs?

They'll either have to be configured to give the same LCP Endpoint-
Discriminator, or the peer will have to be tolerant of being presented
with the "wrong" E-D and having LCP renegotiated with the "right" one
later.

> where a receiver can quickly detect a lost fragment.

It's quite a bit more than a suggestion.  It's a requirement.  MP will
fail miserably if you reorder fragments.

> Would this break

Unless you use the "Sequencing Required" option in L2TP, you may well
break the ordering rule in MP.

I'm probably in the minority on this, but I'd recommend doing the
bundling locally -- on the LAC if possible -- and then carrying the
reassembled packets back to the LNS via L2TP.  You have to do stateful
inspection and modification of the LCP messages at the LAC in order to
do this, so that the LNS can remain unaware of the MP options, but
it's not an impossible thing to do; ISDN TAs have done it for years.
(There are, of course, other problems; for instance, this mode of
operation breaks CHAP.)

The reason I recommend bundling locally is twofold.  First, as you've
noticed, L2TP interacts with MP in some undesirable ways in the
establishment of links.  Second, and more subtly, MP performs very
badly when there's differential delay between the links or noticable
fragment loss, as occurs with non-error (congestion) events.
Tunneling the links across an internet is one good way to destroy MP
performance.

You might want to get a copy of Rich Shea's book on L2TP.  It covers a
number of deployment issues such as this.

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp