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 abs=
tract below and let me know your valuable opinions:

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

=95       MRRU option is considered as mandatory option for a link to join =
a MC/ML-PPP bundle
=95       Endpoint discriminator is optional and can be used to identify di=
fferent PPP peers
=95       Short-sequence number as an option is negotiated as part of LCP a=
lthough 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 differen=
t links. This leads to an implementation ambiguity about which values to be=
 chosen for the bundle. Some of the ways applications can implement this ch=
oice are:
                                        - Choose the negotiated value from =
the latest link that came
                                        - Choose the first value that was n=
egotiated
                                        - Choose the one matching operator =
configuration etc.

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

-> Proposed solution

          Since the bundle level parameters like MRRU & sequence number len=
gth 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 l=
evel parameters for all the links in the bundle. This will remove the ambig=
uity about choosing the values of bundle level parameters and also prevent =
different values being negotiated for same parameter in case of some mis-co=
nfiguration.

          However, still there is a need to have some parameter in LCP whic=
h determines the bundle association of a link. In order to do that we can u=
se 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 includin=
g a simple version number option in LCP.

Regards
Vineet

"DISCLAIMER: This message is proprietary to the Aricent Group and is intend=
ed solely for the use of the individual to whom it is addressed. It may con=
tain privileged or confidential information and should not be circulated or=
 used for any purpose other than for what it is intended. If you have recei=
ved this message in error, please notify the originator immediately. If you=
 are not the intended recipient, you are notified that you are strictly pro=
hibited from using, copying, altering, or disclosing the contents of this m=
essage. The Aricent Group accepts no responsibility for loss or damage aris=
ing from the use of the information transmitted by this email including dam=
age from virus."
_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext