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,
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:
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 ;-))
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
