Below...
On 04-Dec-20 04:17, Paul Kyzivat wrote:
> Brian,
>
> One more thing occurred to me:
>
> On 12/2/20 12:29 PM, Paul Kyzivat wrote:
>
>>>> Also, the goal of negotiation isn't clear to me. I gather it must be for
>>>> the two sides to agree on a particular value for the objective. But for
>>>> that to work there must be some rules about how values can change in
>>>> each step so that the result stabililizes, rather than causing a battle
>>>> that ends with loop count exhaustion. This could be achieved by always
>>>> negotiating *down*, or always *up*. But that requires that the objective
>>>> value type have an ordering function. Given the general nature of the
>>>> objective I don't think that can be assumed.
>>>
>>> No, it explicitly is not defined either in the protocol nor the API.
>>> The syntax and semantics of the objective value are defined
>>> per-objective,
>>> and the objective might or might not be ordered. So there is
>>> intentionally
>>> no answer to your question.
>>>
>>> In most cases I'd expect that there would be an ordering but we didn't
>>> want
>>> to constrain the use cases in that way. Also note that a failed
>>> negotiation
>>> (e.g. the loop count expires, or where one end simply rejects the other's
>>> offer) is not a protocol failure.
>>>
>>>>
>>>> ISTM that more work is needed to define the negotiation process in a way
>>>> that ensures it ends with both sides agreeing on a single value for the
>>>> objective.
>>>
>>> As noted, that is per-objective. The most complicated case I've coded
>>> is IP prefix assignment, and it works fine, except that if there is
>>> no prefix available of the maximum desired length, the requester ends
>>> up unsatisfied - as intended. There should be no condition in which
>>> the negotiation loops indefinitely; it either succeeds or fails.
>>
>> Without that the result in non-deterministic. The two sides may have
>> conflicting goals, and then the result will only be determined by the
>> loop count and timeout.
>>
>> Alternately, implementors will establish side agreements that aren't
>> governed by standards.
>>
>> That seems like an undesirable state of affairs.
>
> One possibility would be to define the negotiation policy on a
> per-objective basis. This would be required as part of the definition of
> the objective that is registered with IANA. It would define how the
> value may change from step to step of negotiation to ensure convergence.
The IANA policy is Specification Required. We already have this in the
GRASP spec itself:
There must be a well-defined procedure for concluding that a
negotiation cannot succeed, and if so deciding what happens next
(e.g., deadlock resolution, tie-breaking, or revert to best-effort
service). This MUST be specified for individual negotiation
objectives.
The natural place to expand on that is in draft-ietf-anima-asa-guidelines
as it develops.
Regards
Brian
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
