Re: [Pppext] Proposal to solve ML-PPP ambiguity

[James Carlson <[e-mail]>]

Vineet kumar Garg wrote:
> Hi James
> 
> Thanks for your inputs on this. Really appreciate.
> 
> I agree with your point that the situation mentioned below is an error case and should be ok to not bring up the links in case of mismatch.
> 
> You have explained how one of the possible solutions in such situation would work. thats fine. But the solution described is not mentioned in the standard (as far as I know) leading to ambiguity in implementation with a possiblity of inter-operablity problems when two different approaches are chosen to solve the problem at hand. IMHO, it will be nice if the best approach is documented in the RFC so as to remove the ambiguity.

If someone is interested in writing a new document that resolves
problems that have been seen in the existing document -- and that
doesn't create new ones -- that's certainly fine by me.  Have at it.

For what it's worth, although I agree that an implementor's guide might
be helpful, I'm not so sure that this is something that needs to be
covered by the existing document.  The existing text makes it clear that
if you want to use the Short Sequence Number Header Format Option, you
have to include it on all links:

   configure-Reject the option.  If 12 bit sequence numbers are desired,
   this option MUST be negotiated when the bundle is instantiated, and
   MUST be explicitly included in every LCP configure request offered by
   a system when the system intends to include that link in an existing
   bundle using 12 bit sequence numbers.  If this option is never
   negotiated during the life of a bundle, sequence numbers are 24 bits
   long.

When a peer walks off the end of a "MUST," you're within your rights to
do anything reasonable to resolve the problem.  Often, the most
"reasonable" answer is to drop the link and report an error, rather than
continue talking to an obviously broken peer.  Of course, some
implementors may just ignore the problem and drive on.  Your results may
vary substantially.  Not all implementations are equal in quality.

> Another perspective of this could be using the latest negotiated option for the bundle since the peer may have informed of a change in parameter (say short seq number) at only one of the links in the bundle. I don't think RFC requires a system to re-negotiate all its links if any of the bundle level parameters change.

The text above makes it clear that if you want 12-bit sequence numbers,
you have to ask for them when the bundle is created, and you have to ask
for them on every link that will join the bundle.  And if you want
24-bit sequence numbers, you must never ask for the option on any of the
links in the bundle.

Because this option needs to be the same on all of the links in the
bundle, the only reasonable solution I can see for changing this
parameter would be to bring down the bundle head.  To do that, you have
to at least restart negotiation of LCP on all of the links or take the
links down.

But I'm unclear on what the point might be.  Why would you ever want to
do this?  Sequence number size is basically a function of the relative
link speed, available buffering, and tolerable timing skew among the
links.  If you don't know that 12-bit sequence numbers are safe for your
application, don't use them.  I don't think it's a flag that would make
sense for users to flip on and off at random.

> Basically this is the ambiguity because of which I suggested about using a separate negotiation leg for all the bundle level parameters. Maybe it does not make a lot of sense making this big a change for an error scenario, but it will lead to better and more clear designs and might hopefully have better use cases in future.

RFC 1990 has remained unchanged (and in widespread use) since 1996.  Are
you certain that making a fundamental change to the way it is negotiated
will bring benefits that are worth the incompatibilities it will cause?

If so, then I would insist on seeing those "use cases" documented
clearly now, and the compatibility issues described in detail.  Changing
an established protocol is not a matter of "if you build it, they will
come."  It has to be done only after all the reasonable alternatives
have been exhausted.

> One more ambiguity in the protocol that I think can be clarified in RFC is use of IPCP (or any other NCP) over a MC/ML-PPP bundle. Doesn't it make more sense to use only IPCP over NCP when using ML-PPP to resolve the issue of which member link to be used for IPCP?

I don't think I understand the question.

Once a link joins a bundle, all NCP messages (with some minor exceptions
-- the per-link variants of ECP and CCP) are always processed at the
bundle head, regardless of encapsulation.  This is in section 2 of RFC 1990:

   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.

In other words, with MP you have only a single IPCP instance, regardless
of how many links the bundle may have, regardless of which link sends
the IPCP negotiation messages, and regardless of whether MP headers are
used on those messages.  You don't get to run a separate instance of
IPCP down at the per-link level with MP!

Perhaps what you're saying is that you'd like to dedicate one link
within a bundle to carry only a single protocol.  Provided that you
follow the sequence numbering rules in section 4.1, or you send all of
those messages without MP headers, you're free to make the links
unbalanced in any way you choose.  The RFC is intentionally silent on
that point; if you do this, it's up to you (the implementor) to decide
how you want it to behave.

There's no defined negotiation mechanism in MP that will allow you to
determine non-uniform use of the links in the bundle.  I would suggest
that the easiest way to do this (if it's a requirement for your
situation) would be to do it by prior arrangement.  In other words, have
a special configuration knob in your implementation.  If negotiation is
required, then I think a substantial amount of background information on
the application and the requirements will be needed -- so write a draft.

-- 
James Carlson         42.703N 71.076W         <[e-mail]>