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+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ 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
