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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
