Hello,
I have been selected to do a routing directorate "early" review of this draft.

Document: draft-ietf-anima-brski-discovery-13
Reviewer: Daniele Ceccarelli
Review Date: 2026-07-15
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be
resolved before it is submitted to the IESG.
The draft explains WHAT can be discovered (registrars, proxies, pledges)
and HOW variations are signaled, but I found it hard to understand HOW this
fits into a normal routed network with VLANs, routers, and possibly no
IPv6. The core ideas seem reasonable, but more plain-language deployment
guidance would help non-experts and operators.

Comments:

What I understood
BRSKI is about automatically enrolling new devices ("pledges") with a
trusted registrar. This draft does not define enrollment itself; it defines
how devices find the right registrar or proxy, especially when different
BRSKI variants exist and do not interoperate.
It supports three discovery methods:
- DNS-SD (often mDNS on the local link)
- GRASP (ANIMA signaling, sometimes over the Autonomic Control Plane)
- CORE-LF (CoAP-based discovery, often using multicast)
Join Proxies sit between pledges and registrars. The draft also defines how
to pick among multiple registrars and fail over if one is down.
What I found unclear from a routing perspective is the following:

1. What happens across subnets?
Much of the default behavior seems link-local:
- mDNS usually stays on one L2 segment
- GRASP proxy announcements use TTL=1 (one hop)
- CORE-LF examples use link-local IPv6 multicast
I understand pledges on the same switch/VLAN can discover a nearby proxy.It's not clear to me the expected design when:
- pledges are on access VLAN 10
- the registrar is in a data center on another subnet
- there is no mDNS relay and no GRASP/ACP infrastructure
Section 3.3.4 mentions large networks and anycast, but only briefly. As
someone new to this, I could not tell whether cross-subnet deployment is explicitly supported with defined infrastructure, or left to local deployment guides.
I would suggest to add a simple "how to deploy in a routed network" section with 2-3 example topologies and required network elements.

2. Which discovery method should an operator choose?
The draft supports DNS-SD, GRASP, and CORE-LF, but I could not derive a clear default for common cases:
- small factory floor (one L2 domain)
- enterprise campus (many VLANs)
- site with existing DNS but no ANIMA/ACP
Section 3.5.1.1 mentions that unicast DNS-SD needs working DNS (often from RA options), while GRASP may auto-configure more. That helped, but I would
like a short decision table: "if your network looks like X, use Y." Is this something doable or the combinations would be too many?

3. Addresses in announcements confused me
GRASP and CORE-LF examples mostly show link-local IPv6 addresses (fe80::).
If a Join Proxy on one subnet must reach a registrar on another subnet via
ACP/routing, should announcements contain routable addresses instead?
I may be missing something obvious, but this was not clear to me on first
read.

4. Security section helped, operations section is missing Section 6 explains discovery can be untrusted (fake mDNS/GRASP announcements) unless the network is secured (ACP, trusted DNS, etc.). That made sense. What I missed as a newcomer is: "given a typical enterprise LAN, what do I need to configure on routers/switches/DNS to make this work safely?"

Minor Issues
1. Section 2.2–2.3 and 3.1 are dense; a short "how it works in one page" diagram or walk-through before the registry details would help new readers(also noted in IoTdir review).
2. Section 3.5.1.1 mixes protocol signaling with DNS resolver implementation notes; hard to tell what is normative vs. advice for vendors.
3. Terms like "context", "variation string", and "socket" took effort to map to real network elements; a small glossary with examples would help.

Thank you
Daniele