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

[Paul Kyzivat <[e-mail]>]

Brian,

Thanks. I'm happy now.

	Paul

On 12/3/20 4:22 PM, Brian E Carpenter wrote:
> 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
>