Re: [Anima] services-dns-autoconfig

> I think that the goal of this document is to somehow gateway DNS-SD
> requests/replies into GRASP M_FLOOD messages.  But, I'm having to reverse
> engineer that.

They don't need to be floods. My toy implementation uses GRASP negotiation
to proxy a DNS-SD lookup.

https://github.com/becarpenter/graspy/blob/master/AskDNSSD2.py
https://github.com/becarpenter/graspy/blob/master/GetDNSSD2.py

But certainly you could flood something that you felt everybody needs.

Regards
    Brian

On 17-Nov-21 01:52, Michael Richardson wrote:
> 
> I tried to read https://datatracker.ietf.org/doc/html/draft-eckert-anima-services-dns-autoconfig-00
> this afternoon between other appointments.
> 
> I think that the Introduction needs to tell me a lot more about the problem
> space.
> 
> The Day-0/Day-1 stuff, I sort of understood, but not really.
> Is it relevant how the device got onto the ACP, if it wasn't BRSKI?
> 
> I'm really unclear what the first sentence means:
> 
>     This document defines to support the autoconfiguration of Autonomic
>     Control Plane (ACP, [RFC8994]) nodes for fundamental decentralized
>     network services via DNS-SD GRASP, utilizing a new proposal mapping
>     of DNS-SD ([RFC6763]) onto GRASP as its hop-by-hop multicast
>     transport and encoding of messages.
> 
> I don't know what "DNS-SD GRASP" is, and I think I should know all the words
> in the first sentence :-)
> 
> I'm not sure if this is document is providing for autoconfiguration *OF* the
> ACP in nodes, or autoconfiguration of the nodes, once the ACP is configured.
> 
> I think that the goal of this document is to somehow gateway DNS-SD
> requests/replies into GRASP M_FLOOD messages.  But, I'm having to reverse
> engineer that.
> 
> A comment on:
> }2.3.  DNS for operations
> }
> }   Availability of DNS names for network operations/troubleshooting is
> }   today mostly an convenience in network operations, but with IPv6
> }   evolving the need to use DNS names even in CLI based network
> }   diagnostics is raising - because IPv6 addresses often are more
> }   difficult to memorize by operators.  More and more network features
> }   also support configurtion that instead of addresses include domain
> }   names or URLs, and ultimately, any non-fully autoconfigured functions
> }   should rather rely on domain-names and URLs instead of just addresses
> }   for greater flexibility and relilability in the face of address
> }   changes.
> 
> I think that there are three major reason why even CLI tools need to use
> names:
> 1) because SSH, PKIX and other identities of the remote nodes are bound to
>     the name.
> 
> 2) because there are a multitude of IPv{4,6} addresses available for the
>     destination, and the tools need to try them all.
> 
> 3) because picking a source address (and protocol) is going to become more
>     and more difficult as we get into new overlays, and MIF.
>     Where you get the name->IP mapping will affect what source is really allowed.
> 
> We lack the right APIs... getaddrinfo(3) isn't enough.
> 
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 