Vineet kumar Garg | 26 May 2011 11:21
Favicon

Proposal to solve ML-PPP ambiguity

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
(Continue reading)

James Carlson | 26 May 2011 13:31

Re: Proposal to solve ML-PPP ambiguity

Vineet kumar Garg wrote:
> 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?

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.

(Continue reading)

Vineet kumar Garg | 26 May 2011 21:45
Favicon

Re: Proposal to solve ML-PPP ambiguity

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 [carlsonj <at> workingcode.com]
(Continue reading)

Vineet kumar Garg | 26 May 2011 21:47
Favicon

Re: Proposal to solve ML-PPP ambiguity


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

 Regards
Vineet

________________________________________
(Continue reading)

James Carlson | 26 May 2011 23:32

Re: Proposal to solve ML-PPP ambiguity

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
(Continue reading)

Vernon Schryver | 26 May 2011 23:55
Favicon

Re: Proposal to solve ML-PPP ambiguity

> From: James Carlson <carlsonj <at> workingcode.com>
> To: Vineet kumar Garg <vineet.garg <at> aricent.com>
> Cc: "pppext <at> ietf.org" <pppext <at> ietf.org>

> For what it's worth, although I agree that an implementor's guide might
> 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    vjs <at> rhyolite.com
_______________________________________________
Pppext mailing list
Pppext <at> ietf.org
https://www.ietf.org/mailman/listinfo/pppext

James Carlson | 27 May 2011 13:44

Re: Proposal to solve ML-PPP ambiguity

On 05/26/11 17:55, Vernon Schryver wrote:
>> From: James Carlson <carlsonj <at> workingcode.com>
>> To: Vineet kumar Garg <vineet.garg <at> aricent.com>
>> Cc: "pppext <at> ietf.org" <pppext <at> ietf.org>
> 
>> For what it's worth, although I agree that an implementor's guide might
>> 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:

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.  :-/)

--

-- 
James Carlson         42.703N 71.076W         <carlsonj <at> workingcode.com>
_______________________________________________
Pppext mailing list
Pppext <at> ietf.org
https://www.ietf.org/mailman/listinfo/pppext


Gmane