Re: [Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08

[Brian E Carpenter <[e-mail]>]

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