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

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

Paul,

We had a bit of delay on updating the ASA Guidelines draft, but the new version tries to cover your point at:

https://www.ietf.org/archive/id/draft-ietf-anima-asa-guidelines-01.html#section-5-2

Regards
   Brian Carpenter

On 05-Dec-20 07:21, Paul Kyzivat wrote:
> 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
>>
> 
>