Subject: [Anima] ANIMA: pls comment: draft-eckert-anima-services-dns-autoconfig-01 / draft-eckert-anima-grasp-dnssd-03

From: Toerless Eckert <[email-masked]>
Date: Fri, 4 Mar 2022 19:15:23 +0100

Dear ANIMA WG members,

I have refreshed the two drafts to complete a solution for a real standalone ACP:

a) use DNS-SD service compatible service discovery in ANIMA/ACP via GRASP:
   https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/
b) Use service discovery for ANIMA/ACP to autoconfigure its own core services
   https://datatracker.ietf.org/doc/draft-eckert-anima-services-dns-autoconfig/

Could I ask you to review and comment these two drafts ?

If the responses are not too averse, I will request a call for adoption.

Thanks
    Toerless

Btw: I am happy to swap mutual review cycles, so if you are waiting for more reviews
of your very own draft for ANIMA, i'll be happy to reciprocate ;-))

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Mar 2022 14:03:37 +1300

Hi,

I can reply fairly quickly, since I studied these two drafts before,
and prototyped the draft-eckert-anima-grasp-dnssd mechanism.
I haven't exercised that code recently, but it can be found at:
https://github.com/becarpenter/graspy/blob/master/GetDNSSD2.py
https://github.com/becarpenter/graspy/blob/master/AskDNSSD2.py

So, the mechanism for mapping DNSSD info to a GRASP objective works.

The question that came to me was whether the proposed family of
SRV.<service-name> objectives was too general or not general enough.

Too general, because it claims to be applicable to, well, anything.

Not general enough, because for draft-carpenter-anima-grasp-config,
it didn't make much sense to define that as SRV.GraspConfig. However,
I found the CBOR map approach to defining an extensible objective very
useful. Hence, the code at:
https://github.com/becarpenter/graspy/blob/master/GRASPconfig.py
does *not* use the exact draft-eckert-anima-grasp-dnssd mapping,
but is directly based on it.

All the same, I think this approach to integrating GRASP-based service
management with DNSSD and with legacy NOC services is very interesting
and seems to be something ANIMA should consider carefully.

Could the authors deal with the various TBDs in both documents?

Regards
    Brian Carpenter

On 05-Mar-22 07:15, Toerless Eckert wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Mar 2022 09:54:12 +1300

On 08-Mar-22 02:40, Toerless Eckert wrote:
> Thanks, Brian
> 
> I hope i captured your concerns correctly in github:
> 
> https://github.com/anima-wg/grasp-dns/issues/3

Yes, thanks.

> 
> For draft-carpenter-anima-grasp-config i am a bit at a loss when & why
> one would apply the encodings defined there. Is this meant to be
> ?mandatory? objective parameters whenever you flood ? 

No, it would be a stand-alone objective. I was looking for a way to
solve one problem (how to tell an entire AN that the default GRASP
maximum message size should be changed) and decided to generalise the
solution for any possible GRASP config action. So I stole from
your proposal.

Possibly we should suggest a recommended way of using CBOR or JSON
maps in any GRASP objective, whenever that degree of extensibility
is needed.

> In which case
> i would have to see that i make grasp-dnssd include these parameters because
> it is meant to flood ??

No, I don't that that is necessary.

> 
> Could you maybe give an example ? 

I hope I've clarified enough that you don't need an example. The code
I cited reads in a JSON file, constructs a (Python) map that reflects
that file, and embeds it in a GRASP flood. I've also included an ASA in
my GRASP core, that receives the flood and applies any config changes.

> I am just guessing, but
> the DNS-SD service announcements are typically meant to be used to allow
> selecting a server and then connecting to it. But the general flooding of
> information is not limited to announcing servers. It could simply be
> about flooding of e.g.: intent which has to be just locally followed
> ("network wider parameters"). Just as a counter-example of what would
> IMHO NOT fit into the grasp-dnssd case...

Yes, absolutely. So we could generalise this as "flood any JSON we want
to all autonomic nodes".

Regards
     Brian

> 
> Cheers
>      Toerless
> 
> On Sat, Mar 05, 2022 at 02:03:37PM +1300, Brian E Carpenter wrote:
>> Hi,
>>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 7 Mar 2022 14:40:04 +0100

Thanks, Brian

For draft-carpenter-anima-grasp-config i am a bit at a loss when & why
one would apply the encodings defined there. Is this meant to be
?mandatory? objective parameters whenever you flood ? In which case
i would have to see that i make grasp-dnssd include these parameters because
it is meant to flood ??

Could you maybe give an example ? I am just guessing, but

Cheers
    Toerless

-- 
---
[email-masked]