> Le 9 nov. 2023 à 11:40, Manu Bretelle <[email protected]> a écrit : > > > > On Thu, Nov 9, 2023 at 10:21 AM Marc Blanchet <[email protected] > <mailto:[email protected]>> wrote: >> Hello, >> I presented draft-many-dnsop-dns-isolated-networks Tuesday at the end of >> dnsop meeting. Thanks for letting me present. Wanted to come back to a few >> points raised. >> >> - About use cases, I see the dnsop Zulip chat that some people were >> interested in the topic, noting about additional use cases (antarctic for >> example). I guess I did not touched enough on this because of limited time, >> but there are many « mostly isolated, often unconnected » networks use cases >> being discussed in various wgs. I think the best place to see those are in >> the Time-Varying Routing wg requirements and use cases documents >> (draft-ietf-tvr-requirements, draft-ietf-tvr-use-cases). Examples such as >> solar energy powered networks, power savings networks, remote networks, many >> are the resource constrained networks where connectivity is not permanent, >> others having dynamic reachability. These drafts were not written for the >> purpose of DNS, but routing, but they all applied almost as is to the need >> of what is discussed in the isolated-networks draft. >> - local names: as these networks are in fact sometimes connected (sometimes >> meaning more than exceptional), names need to be global so that both >> networks are able to resolve names. Local scope names may be in addition to >> global names, but not a replacement. >> - while some use cases like deepspace will take time to be deployed, those >> organizations involved are planning years ahead and need stable technical >> references that are used as requirements to vendors, RFPs, designs, etc…. In >> fact, it is useful now. Some other use cases could benefit it right away for >> implementing. > > I feel it is hard to provide generic solutions without knowing the actual > requirements, and solutions can widely vary depending on those requirements. > Are the "isolated network" actually stable on the other side? or can they > also be subject to poor network quality? Are the lion share of queries > internal to that possibly isolated network, or external connections are quite > prevalent? Are we talking about operators trying to access resources, or > machines needing to talk to each other? For the latter they can be a case > where one may want to avoid the extra dependency on DNS because then you have > a critical system in a hard to access environment that possibly relies on an > extra piece of infrastructure to be operational to operate. > > That being said, it is probably possible to bucket a set of requirement sets > and work from there. > > My gut feeling is that whatever is in those remote networks needs to be > self-sufficient to operate, and this probably call for a dedicated > sub-zone/local domain used and served locally and authoritatively in the > remote side with some form of push/zone xfr from the stable network. > If the remote network may occasionally need resources from across the > unreliable link, stale-answers probably go a long way, with a dash of > prefetching to keep things as up-to-date as possible. > > TL;DR, IMHO, concrete use-cases requirements should be enumerated before a > solution can be crafted.
Thanks. Agree. The draft is a bit light on this, as did not want to repeat what is described in the referenced documents, but I guess it is a mistake. So I’ll redo a pass adding more meat to the bone. Thanks for a constructive and helpful comment. Appreciated. Marc. > > Manu > > >> >> Regards, Marc. >> _______________________________________________ >> DNSOP mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
