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

From: Vineet kumar Garg <[email-masked]>
Date: Thu, 26 May 2011 14:51:45 +0530

Hi All

While working with ML-PPP over some time, I have come across some problems which I think should be solved at the protocol level. Please review the abstract below and let me know your valuable opinions:

As per existing RFC, following are the key characteristics of LCP negotiation for multi-link parameters:

•       MRRU option is considered as mandatory option for a link to join a MC/ML-PPP bundle
•       Endpoint discriminator is optional and can be used to identify different PPP peers
•       Short-sequence number as an option is negotiated as part of LCP although same value has to be negotiated on all the links

        Problem that current protocol creates is that it allows a scope for bundle level parameters to be negotiated with different values on different links. This leads to an implementation ambiguity about which values to be chosen for the bundle. Some of the ways applications can implement this choice are:
                                        - Choose the negotiated value from the latest link that came
                                        - Choose the first value that was negotiated
                                        - Choose the one matching operator configuration etc.

Is there already a solution to this problem as part of protocol that I am missing?

-> Proposed solution

          Since the bundle level parameters like MRRU & sequence number length are applicable to all bundles in a link, it is better to negotiate them like an NCP after LCP has already been done. So, like other NCP protocols, there can be a new protocol called ML-CP which will configure all bundle level parameters for all the links in the bundle. This will remove the ambiguity about choosing the values of bundle level parameters and also prevent different values being negotiated for same parameter in case of some mis-configuration.

          However, still there is a need to have some parameter in LCP which determines the bundle association of a link. In order to do that we can use endpoint discriminator as a mandatory option in LCP for links which want to join a bundle.

Maintaining backward compatibility with existing implementations might be a challenge, however in this case. However, that can be resolved by including a simple version number option in LCP.

Regards
Vineet

"DISCLAIMER: This message is proprietary to the Aricent Group and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. The Aricent Group accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

---

From: James Carlson <[email-masked]>
Date: Thu, 26 May 2011 07:31:16 -0400

> Is there already a solution to this problem as part of protocol that I am missing?

At the point where LCP is negotiated, it is not necessarily yet known to
which bundle the new link belongs.  You ordinarily have to wait for
Authentication to complete.  Thus, the negotiation of those low-level
options needs to be separate.

I think the solution is straightforward.  When you create a new bundle
head, you use the LCP options that were negotiated on that single link.

When attempting to join a new link to an existing bundle (because
authenticated peer names and E-Ds match), check the options on the new
link.  If they match the ones on the bundle, then join up.  If they
don't, then signal an error and terminate the new link.

Since this is a "should never happen" case, it's not really something to
worry about.  Bundles are not just established out of the blue; they're
established between cooperating systems.  If you have one line
configured to use short sequence numbers and the other not, then you've
misconfigured your systems, and having those systems report errors and
fail to establish the bundle is the best result.

> Maintaining backward compatibility with existing implementations might be a challenge, however in this case. However, that can be resolved by including a simple version number option in LCP.

I don't think a new NCP is necessary.  The current mechanism (checking
parameter compatibility when joining links to an existing bundle) seems
to work well enough.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: Vineet kumar Garg <[email-masked]>
Date: Fri, 27 May 2011 01:15:50 +0530

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.

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.

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.

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?

 Regards
Vineet

________________________________________
From: James Carlson [[email-masked]]
Sent: Thursday, May 26, 2011 5:01 PM
To: Vineet kumar Garg
Cc: [email-masked]
Subject: Re: [Pppext] Proposal to solve ML-PPP ambiguity

---

From: Vineet kumar Garg <[email-masked]>
Date: Fri, 27 May 2011 01:17:05 +0530

Hi James

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 ML-PPP when using ML-PPP to resolve the issue of which member link to be used for IPCP?

 Regards
Vineet

---

From: James Carlson <[email-masked]>
Date: Thu, 26 May 2011 17:32:31 -0400

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

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

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

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…

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.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 26 May 2011 21:55:14 GMT

> From: James Carlson <[email-masked]>
> To: Vineet kumar Garg <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

> be helpful,  

What's wrong with the existing implementors' guides?  I thought at
least this one mentioned that de facto standard tactic for handling
MP misconfiguration:

    "PPP Design, Implementation, and Debugging" (2nd Edition)
    by James D. Carlson ISBN: 0201700530

See
http://www.google.com/search?q=PPP+Design%2C+Implementation%2C+and+Debugging
http://www.workingcode.com/ppp/

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: Fri, 27 May 2011 07:44:33 -0400

> least this one mentioned that de facto standard tactic for handling

I meant an Informational or perhaps Best Practices RFC describing MP
implementation issues.  I was trying to redirect away from
protocol-level fixes and towards documentation fixes.

Yeah, I could have suggested googling ... but I was trying to walk a
fine line about my own work.  (For what it's worth, I no longer get a
penny out of it.  :-/)