Subject: Re: PPPmux and MP

From: James Carlson <[email-masked]>
Date: Sun, 2 Jul 2000 10:43:44 -0400 (EDT)

Craig Fox writes:
> This is PPP.  You only agreed that the peer knows how to do PPP muxing
> and has expressed a willingness to receive muxed frames.  You are not
> agreeing to send them.

Of course.  That's the problem.  You're agreeing to receive them
before you know whether or not you are able to.  The paragraph reads
in part:

> >>    [...] 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. [...]

This implies that if you're willing to receive either Multilink or
PPPmux, but not both, then you're stuck.

Consider an access server that terminates some sessions locally
(normal Internet access) and forwards others via L2TP.  How can the
NAS agree to do something on behalf of an MP bundle head that is
located remotely and has unknown properties?

That's why this should be an NCP.  Putting it in LCP doesn't make
sense to me.  It doesn't need to be negotiated before authentication.

> That works for me.  Is this text acceptable?

Assuming we can't agree to fix the PPPmux protocol to use an NCP for
negotiation, that's the better remaining alternative.

>   frames MUST NOT contain PPP Multilink frames.  As with a
>   non-Multilink link, the transmitter is not obligated to
>   send PPP Multiplexed frames.  

It's probably ok to repeat this idea in this last sentence, but this
is certainly true of everything else.  For example, agreeing to
receive with address and control compression does not obligate the
sender to compress, and so on.  This isn't a special feature of
PPPmux.

-- 
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

---

From: James Carlson <[email-masked]>
Date: Sun, 2 Jul 2000 12:47:44 -0400 (EDT)

Craig Fox writes:
> You mean that you would not send the option until you knew whether
> you are going to be in a bundle or not?

Yes, or until I know who the user is.

>  You are also negotiating
> MLP at that point.  If MLP is rejected, you can add/remove the
> other options as you see fit.  If MLP is accepted, then you will be
> in a bundle or disconnected, correct?

If it's accepted, then both MP (MRRU) and PPPmux are enabled at once.
Other than renegotiating LCP (which is avoided everywhere possible for
obvious reasons), I'm stuck.  If I offer both MRRU and PPPmux to my
peer, I have to be prepared for him to accept both.  I can't allow
just one or the other.

> Huh?  I don't understand.  Are you referring to the link being able
> to receive a PPPmux vs a Multilink frame while part of a bundle?
> Why would you want to do that?

The entity doing the MP reassembly might not be the same one doing
individual links.  They may well have different capabilities.  I can
think of reasons why I might want PPPmux at the link layer, but if I
want to offer that, then I have a choice between also implementing at
the bundle level or simply foregoing PPPmux.

> How does it do it today?  LCP will be renegotiated if the HGW/LNS is
> unhappy with the options negotiated by the NAS/LAC.

And the user's brain-damaged PC promptly hangs up.  I'd very much like
to avoid LCP renegotiation if at all possible.

> Hmmm, different attitudes...  I think that ECP/CCP are in the wrong
> location.  I think that they should be negotiated (along with the
> peer name) during LCP.  But that is water long over the dam...

Right.  Fortunately, PPPmux isn't over the dam yet.

I agree completely that authentication should have been put into LCP.
It would have fixed the complaints about callback (and the subsequent
botch CBCP).  I liked Funk's mechanism for LCP authentication.  That's
not what we're stuck with, though.

As for ECP/CCP, it is odd that they require multiple protocol numbers
and such, but at least, as NCPs, they're easier to configure
separately.

---

From: James Carlson <[email-masked]>
Date: Mon, 3 Jul 2000 10:54:54 -0400 (EDT)

Craig Fox writes:
> OK.  Don't you have the same problem with Multilink and every
> other LCP option including Authentication?

OK, you've convinced me.  This problem occurs in enough places now
that adding one more doesn't do obvious harm.

> However, if we switch to an NCP, then it would not be possible to set
> it at the link layer, correct?  Or were you considering violating one
> of the rules of PPP?

If you need it also at the per-link level as well, I'd advocate using
the CCP/ECP per-link model.  At least that's a well-known, well-
understood hack.  (Unlike having LCP negotiation affect which NCPs are
in use at the bundle level ...)

> Of course, since we have an assigned LCP option, we could negotiate
> with either an LCP or an NCP.
> 
> That's a joke....

I took it that way.  ;-}

> Are we stuck?  Or have we just accepted this?  Are you absolutely sure
> that it is too late to change?

Given that current efforts seem to be directed towards apparent
mistakes like EAP, I'd say yes, it's probably too late to add LCP
authentication.

> I distinctly remember early PPP meetings where the attitude was that PPP
> was a short-lived protocol since the IPLPDN (I Plop Down/IP over Large
> Public Data Networks) work was going to obsolete us.  That was 8 to 9
> years ago.  PPP is still here.  IPLPDN plopped.

Many have come and gone.  I don't think that's the point.  The last wg
consensus that I understood was that the group was attempting to
advance the remaining drafts and then, having completed its work,
become dormant.

> I would be willing to help work on an LCP Authentication scheme...

I've put a copy of the Funk proposal here:

	ftp://ftp.workingcode.com/pub/carlson/draft-ietf-pppext-link-negot-00.txt