Subject: [Anima] services-dns-autoconfig

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Nov 2021 07:52:21 -0500

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Nov 2021 10:15:35 +1300

> requests/replies into GRASP M_FLOOD messages.  But, I'm having to reverse

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:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>