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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 26 June 2021 22:58 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FA63A080A; Sat, 26 Jun 2021 15:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level:
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92RV9CtP_tA9; Sat, 26 Jun 2021 15:58:21 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099543A07F8; Sat, 26 Jun 2021 15:58:20 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id c7-20020a17090ad907b029016faeeab0ccso10223641pjv.4; Sat, 26 Jun 2021 15:58:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=no5JUZIkpK/k8YCUW1QJrEN8yHyr0lS+qgW3Yap39lY=; b=IF3DaPF8hA1dA3e0xyhv0fuGQ1UbkUWgXKQ34SpQOScZpiQWWvvXNonyCtLst8nSAU eg8hXW5qTuCCElJeSQt/vTXd5kludIomg+N0XZZ0RQjYQ74vskclgOWcLcz6t8S7sMUI SzyLX46IAGEz9AlMTj7EW2y96I2+fKjXIuCL/OrQE97DQLGFZfqYF7YsMLg6/j79p9Ag 7mqYP7w+uHMklZt6qpE/mk8DZdejJe03hN+57kQL1hVJcdRPKuc2JvAIAUgi6P1xeI2k XhEgl++zNWPOxaMtCqlm04NLBrE73AYqkq4xBHSK83ADluXdouc8aI7YGym8F/c2ZMdk jvYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=no5JUZIkpK/k8YCUW1QJrEN8yHyr0lS+qgW3Yap39lY=; b=deBMRceOAh06VhcB92VrPttQ4czjvT0m4kfmPT4p6jabiaL8yOxt3xas7nsZxw+yZe UsiiMDp1byWNw27Bbh5ID/YHdsCvgY64z0Q1Xp3flQzBRjgNL87w7x9+jikj7P4mVL6P RqYEJmQPOKf28jis7/bEbc1xAOsryBMn9SHv7w0iLVilpFkIb/WSnwmkKKkEF7VYF29o DFFouXChIcZIGiplUm2RmDls1WrIKRsVb6US89uR5gEKs/AgZg49++bGDt1V5yYGaJID TberfsUUSSQ7Z2Zj6+dlYBp6pUw3VWCkPkZ3dop5EiuYMuKsJyRIE7RjAsQfNwaLsucr sGGw==
X-Gm-Message-State: AOAM530xuK1ixM75Tc5FJvDpXuUsSdK03GQbGPQvalvSflmimxOJ9IIJ 4/09wP4sw7PWJ06zhULmwRjTjgc42g75Uw==
X-Google-Smtp-Source: ABdhPJyIHe7hdZYGnFVX99X36TTeO8nwN4h6LsJxp7T+wDMIdq3ZJoQCZGtQH/vFSgsfMtKEv1WukA==
X-Received: by 2002:a17:90b:4392:: with SMTP id in18mr19287682pjb.54.1624748299619; Sat, 26 Jun 2021 15:58:19 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id y206sm9331998pfb.3.2021.06.26.15.58.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Jun 2021 15:58:19 -0700 (PDT)
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, draft-ietf-anima-grasp-api.all@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>
References: <033a81cb-0a38-b291-80cb-c94e2147de3c@alum.mit.edu> <291a713f-b685-50fc-f097-1200e6127ef3@gmail.com> <86fa9191-1b74-97d9-d530-9415e7e035f9@alum.mit.edu> <3e979d48-04ee-b711-93e4-f1d51a3bd4bb@alum.mit.edu> <5332b21b-b5eb-7ac6-c759-12ef653706cf@gmail.com> <4fb44aa2-7973-349b-db71-e0ade76310ee@alum.mit.edu>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <78703311-ff19-bed0-423f-606d778bd376@gmail.com>
Date: Sun, 27 Jun 2021 10:58:16 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <4fb44aa2-7973-349b-db71-e0ade76310ee@alum.mit.edu>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/NDPYHNIptFIImYN4DeAsWRmGQi4>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Jun 2021 22:58:27 -0000

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
>>
> 
>