Subject: PPPmux and MP

From: Ali Irfan-FIA225 <[email-masked]>
Date: Fri, 30 Jun 2000 14:48:55 -0500

There were some off-mailing-list discussion on the interaction of PPPmux and
multilink PPP (MP) (RFC-1990). The issue is that if PPPmux LCP option is
negotiated on a link of a bundle, then can the multiplexing only occur on
just that one link or on the entire bundle? PPP multiplexing can be done
either way, on the entire bundle or on an individual link only. We would
like to allow both, if the group agrees. 

We are intending to update PPPmux draft <draft.ietf.pppext.ppmux.00.txt> by
adding the following paragraph

4. Interaction with PPP Multilink (MP) Protocol

   The PPP Multiplexed Frame option is negotiated by LCP for an
   individual link.  If the PPP Multiplexed Frame option is
   negotiated on any link of a Multilink PPP bundle, then the
   receiver has agreed to support the PPP Multiplexed Frame
   option on the Multilink Bundle.  The transmitter is under no
   obligation to multiplex frames on the bundle or the individual
   links.

Comments are solicited.
Thanks

Irfan

---

From: James Carlson <[email-masked]>
Date: Fri, 30 Jun 2000 16:27:06 -0400 (EDT)

>    obligation to multiplex frames on the bundle or the individual

The paragraph you give seems to imply that this is a possibility and
that it could be done simultaneously at both bundle level and link
level, leading to a protocol nested in itself.  The only other
instance I know of something like that -- MPPE and MPPC -- is also a
flawed design.  I can't see a reason for doing PPPmux on a per-link
basis with MP.

Worse, at the time you negotiate LCP, you don't necessarily know
whether you're joining an existing bundle (Vern's nifty preselection
idea aside).  You have to wait until after authentication occurs to
determine this.  This implies that you cannot know whether nor not to
accept the PPPmux option when presented.  You can't know what you're
necessarily agreeing to.

Worse still, it's not obvious how this should work in practice.
Suppose links A, B, and C are in a bundle.  A starts first and does
not include PPPmux.  B starts next and does include it.  Then C starts
without PPPmux.  Presumably, the bundle can now do PPPmux.  If B
leaves the bundle, though, does the PPPmux capability go with it?  If
so, then we have the strange condition that the implementation must
have a quorum of links of a particular flavor in order to perform a
given network layer.  If not, then we have the strange condition that
the bundle is permitted to do something that neither link has
explicitly negotiated.

This would appear to have much the same flavor to it as the CCP and
ECP at bundle versus per-link debate.  The only problem is that PPPmux
is negotiated at the wrong point in the architecture; it should be an
NCP, just like CCP and ECP, and (if desired) have a per-link variant.
That way, the intent would be unambiguous.

As long as PPPmux stays at LCP level, it seems to me that the right
hack is to treat it in the same manner as the MRRU and SSN options.
If it's set on any link, then it must be set on all links.  Dissimilar
settings for this option within a bundle should be prohibited.

-- 
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
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp