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

[Jeff Tantsura <[e-mail]>]

Toerless,

We will provide a slot, most likely during the 2nd meeting.
Please send an email to RTGWG with a short intro so people who might be interested have the time read up.

Thanks!

Cheers,
Jeff
On Nov 10, 2020, 11:48 AM -0800, Brian E Carpenter <[e-mail]>, wrote:
> 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.
>
> Regards
> 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: <[e-mail]>
> >
> > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/rtgwg
> > >
> > > --
> > > ---
> > > [e-mail]
> >