Re: [Anima] RTGWG-chairs: slot for RTGWG@109 to present on GRASP ? (was: Re: draft-li-rtgwg-protocol-assisted-protocol (was: Re: IETF 105 mic comments on draft-li-rtgwg-protocol-assisted-protocol))

Brian E Carpenter <> Tue, 10 November 2020 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 211C23A0EA8; Tue, 10 Nov 2020 11:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id whrWLItHRLth; Tue, 10 Nov 2020 11:48:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56A4A3A0D22; Tue, 10 Nov 2020 11:48:01 -0800 (PST)
Received: by with SMTP id a18so12210891pfl.3; Tue, 10 Nov 2020 11:48:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6inBZq2nUUYkMmEU4kiUN5pPr/CHjSCu1YFoXovFYJs=; b=bmhazLWFRWsUAuyn3t3FPOyZDi01lwx6SPa4yocVKmLWG1DKWftY1n0TxwGWEzFveu ZsaZTrGtQuOsL+3sfKqmNAwCdLc5ZhGM8T/rdV/zgqme5MV+B7as2bh92WUrOKB2V+Tc jj4sUjAoMFzu513XIHifhwPK0s+QqrEKwRfBaRAxiyk5vqR0I5WA+zlw6cDAfrtnBk84 vMUunU3E9s6FPFXQTN713RTlPraNMKU5kWuR6xsIyEl8ud0ySdHsj5lsqkomMUAfV3It UoyBj+qg43/91xw080Z8i1jy4U5+9M3JYgWjlWQ90qUw/DTPak4Zwfd1Ml+NjO7IAijI YfiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=6inBZq2nUUYkMmEU4kiUN5pPr/CHjSCu1YFoXovFYJs=; b=sa0PVNR6ATwLWUxB6hD7v+1dhD3llGYgXUgpFo42ipoVjSez4oyvo1eoYe/9/8lknr o1kHsSvgJ0Zpk/PlHpaIJ5b2KiNRF3NiKKj1aBxZlQSb5caPfeAf9O15kTPQhfzNP+QE z1kDjdu9RxTWCJsvKEs0TamL1c507W7RdbeS0pBn8RFKnQ2aZDPJ06Zla3/zgak+rxZI EoCObgbiycJju0UL9VJ1+UXo4bHHAiDqR7gJy6++i4QO3CDdaWMmXf1M9NlvE9rrwMLv BDU6FFtdU51PElekh/xUTlbgSPqebVlbOpw9k+vqr5d3UEAmTWopth+efAy7Qm9iwwuK Qe8g==
X-Gm-Message-State: AOAM532issIf82RQY9w+ymMcl0+fib5qVS5Km24WVShg8G4dSvDPJCw+ q0u+dwIF53ByhePCqA+BHZs/WBhDtFqUzw==
X-Google-Smtp-Source: ABdhPJwfBLqgJUTZ38qUJHKRAEZPMgFBmWO8ROUmWgk1Y8Jc5/AipRASw73MkgM9t12sy9D/1jClpw==
X-Received: by 2002:a17:90a:5508:: with SMTP id b8mr758735pji.85.1605037680217; Tue, 10 Nov 2020 11:48:00 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id f17sm7588263pfk.70.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Nov 2020 11:47:59 -0800 (PST)
To: Toerless Eckert <>,, Jeffrey Haas <>, Chenshuanglong <>, "" <>, Lizhenbin <>, "" <>, Guyunan <>,
References: <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 11 Nov 2020 08:47:54 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] RTGWG-chairs: slot for RTGWG@109 to present on GRASP ? (was: Re: draft-li-rtgwg-protocol-assisted-protocol (was: Re: IETF 105 mic comments on draft-li-rtgwg-protocol-assisted-protocol))
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Nov 2020 19:48:03 -0000

I'd like to underline what Toerless said. I looked at the two use casess
in the protocol-assisted-protocol draft and they seem very easy to
map onto GRASP. I don't really have time before the meeting to do
that but they are certainly use cases we could have included in the
original use case BOF that led to ANIMA.

   Brian Carpenter

On 11-Nov-20 05:57, Toerless Eckert wrote:
> In followup to the discuss on  draft-li-rtgwg-protocol-assisted-protocol:
> Checking RTGWG agenda, it seems you might still have time available,
> so if you are interested, i would be happy to whip up a few slides
> to five an overview of GRASP and how we imagine it to be useable
> to automate operational workflows for various services, including
> routing protocols.
> Cheers
>     Toerless
> In-Reply-To: <>
> On Tue, Nov 10, 2020 at 05:52:35PM +0100, Toerless Eckert wrote:
>> I see subject draft is again on the agenda of RTGWG'109 and the authors also asked
>> for a slot to present to ANIMA (which we would be happy to have, time permitting). 
>> Some thoughts as contributor, maybe ANIMA chair:
>> Reading the draft it looks like a reinvention of the ANIMA GRASP protocol
>> that we finished almost 3 years ago, but without many of the mechanisms
>> that make GRASP a well reuseable, easily extensible protocol. So i wonder
>> why we would want to also do another more imited protocol for the same
>> goals.
>> On the mike RTGWG @IETF105, interest was raised to see a more comprehensive
>> signalling enxchange example. Version 03 of the document seems to have
>> expanded the BGP example a bit, but still not comprehensive enough for me
>> to understand if/how this approach would ultimately work.
>> I would like to encourage the authors to concentrate on fully specifying
>> intended use-cases - ideally by simply specifying the use-case as
>> solution using GRASP (we call this GRASP objectives). I am sure
>> ANIMA participants (including me) would be happy to help explaining how
>> to specify such a protocol on top of GRASP once we understand the use-case.
>> Cheers
>>     Toerless
>> On Mon, Jul 22, 2019 at 11:02:31AM -0400, Jeffrey Haas wrote:
>>> To repeat my comments from the microphone regarding this draft:
>>> We already have per-protocol operational and configuration state via the
>>> IETF yang models for a given protocol.
>>> We also have mechanisms to fetch operational state for such protocols; e.g.
>>> netconf and restconf.
>>> Rather than inventing a new mechanism to do troubleshooting for a protocol,
>>> I'd suggest it makes better sense to augment existing IETF yang models to
>>> include RPCs for interacting with troubleshooting for that protocol.
>>> -- Jeff
>>> _______________________________________________
>>> rtgwg mailing list
>> -- 
>> ---