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 woul=
d work. thats fine. But the solution described is not mentioned in the stan=
dard (as far as I know) leading to ambiguity in implementation with a possi=
blity 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 i=
s 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, bu=
t it will lead to better and more clear designs and might hopefully have be=
tter 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 mor=
e 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 protected]]
Sent: Thursday, May 26, 2011 5:01 PM
To: Vineet kumar Garg
Cc: [email protected]
Subject: Re: [Pppext] 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 problem=
s which I think should be solved at the protocol level. Please review the a=
bstract below and let me know your valuable opinions:
>
> As per existing RFC, following are the key characteristics of LCP negotia=
tion for multi-link parameters:
>
> =95       MRRU option is considered as mandatory option for a link to joi=
n a MC/ML-PPP bundle
> =95       Endpoint discriminator is optional and can be used to identify =
different PPP peers
> =95       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 f=
or bundle level parameters to be negotiated with different values on differ=
ent 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 fro=
m the latest link that came
>                                         - Choose the first value that was=
 negotiated
>                                         - Choose the one matching operato=
r 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.

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.

> -> Proposed solution
>
>           Since the bundle level parameters like MRRU & sequence number l=
ength are applicable to all bundles in a link, it is better to negotiate th=
em like an NCP after LCP has already been done. So, like other NCP protocol=
s, 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 amb=
iguity about choosing the values of bundle level parameters and also preven=
t 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 wh=
ich 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 wa=
nt to join a bundle.
>
> Maintaining backward compatibility with existing implementations might be=
 a challenge, however in this case. However, that can be resolved by includ=
ing 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 protected]>

"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