Subject: strange boundary cases in RFC 1990 (Multilink)

From: John Shriver <[email-masked]>
Date: Mon, 12 Jan 1998 18:23:11 -0500

(Please reply to [email-masked], we're having continuing sendmail
misconfiguration problems here.)

I've run into a case where a pair of PPP clients wind up in a state
which appears to be on the fuzzy edge of what RFC 1990 specifies.
Indeed, I think it specifies things that don't make sense in this
state. 

At any rate, here's the scenario.  Running PPP over L2F, so we want to
choose a MTU less than 1500 bytes to avoid IP fragmentation of the L2F
packets.  So, lets say the L2F entities (NAS and HG) are both
configured for an MTU of 1450 bytes.  Microsoft NT RAS client software
dials in, ISDN multilink.  It will not let you negotiate the Multilink
MRRU below 1500 bytes.  So, I eventually stop proposing an MRRU in LCP
due to excessive Config-NAKs.  But I still ACK the peers MRRU option.

So, Multilink is on in the HG to client direction, and off in the
client to HG direction.  Well, I think that's the clear explanation
when reading section 1.2 of RFC 1990.

The conflict comes in the third & tenth paragraphs of section 2:

   We suggest that multilink operation can be modeled as a virtual PPP
   link-layer entity wherein packets received over different physical
   link-layer entities are identified as belonging to a separate PPP
   network protocol (the Multilink Protocol, or MP) and recombined and
   sequenced according to information present in a multilink
   fragmentation header.  All packets received over links identified as
   belonging to the multilink arrangement are presented to the same
   network-layer protocol processing machine, whether they have
   multilink headers or not.

   [...]

   The effective MRU for the logical-link entity is negotiated via an
   LCP option.  It is irrelevant whether Network Control Protocol
   packets are encapsulated in multilink headers or not, or even over
   which link they are sent, once that link identifies itself as
   belonging to a multilink arrangement.

I think that the last sentence is intended to say that an NCP
negotiated on any member of the link, or on top of the Multilink
entity, applies equally to all links in the bundle.

That makes perfect sense when Multilink is on in both directions.  It
makes far less sense when Multilink is on in one direction and off in
the other.  (Yes, that's a degenerate case, but perfectly legal by the
overall PPP architecture.)  

Or should both ends treat the links as part of a bundle, even if
Multilink is only on in one direction?  (Provide a clearer definition
of "links identified as belonging to the multilink arrangement".)  I
suppose that would be consistent.  We really need to exactly define
what it means to have Multilink on in only one direction.

(Yes, of course I know that the fundamental solution to my problem is
to not quit proposing the MRRU, and instead to give up trying to
reduce the MRRU below 1500 bytes.  Or, renegotiate LCP if I get
half-on Multilink.)

There is also the question of whether it is legal for the peer to
endlessly Config-NAK my proposal of a 1450 byte MRRU.  I suppose it
says in section 5.1.1: 

   [...] A system MUST be able to receive the full 1500 octet
   Information field of any reassembled PPP packet although it MAY
   attempt to negotiate a smaller, or larger value.

I presume MAY means that I may try, but it may fail.

We made a mistake by having the MRRU option negotiate two things:
Multilink and it's MRRU.  It should have always been seperate LCP
options.  One option for Multilink: either you agree on that or you
don't.  Another option for MRRU.  That way you can refuse to negotiate
MRRU (which is already the case in LCP for MTU) if you won't do
anything other than the required 1500 bytes, without refusing to do
Multilink.

But, we're too deep in this mire to fix that, I think.

Perhaps we need to state:

   If repeated attempts to Configure-request an LCP MRRU option with a
   value other than 1500 bytes (or the current LCP MRU default) fail
   with Config-NAK's of MRRU of 1500, then the peer SHOULD be
   understood to support Multilink, but not the negotiation of MRRU
   other than 1500 bytes.  

-- 
John Shriver
[email-masked]

---

From: Archie Cobbs <[email-masked]>
Date: Mon, 12 Jan 1998 16:04:48 -0800 (PST)

> overall PPP architecture.)  

It sounds like you have identified a real "loophole". It doesn't make
sense to have single-directional multilink, because the word "bundle"
is really a bidirectional thing. Yet negotiation of just such a thing
is allowed. Cool :-)

> anything other than the required 1500 bytes, without refusing to do

I don't see how this follows. If server A doesn't want to do multilink
unless server B's MRRU is at least 1500, then who is server B to argue?
Server A is entitled to require this if it wants.

Clearly you can't have it "half-way", so therefore if one half isn't
working, you have to call the whole thing off.

That is, the spec should change so that MRRU must be successfully
negotiated in BOTH directions, or else multi-link is not valid at all
(IMHO).

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com