skip to content

For streaming telemetry from 2,000 devices, when should collectors dial in with gNMI Subscribe, and when should devices dial out using RFC 8639 configured subscriptions?

level: seniorimportance: should knowfreq 15%

answer

  1. who opens the connection
  2. where the subscription is stored
  3. what survives a reboot
  4. a firewall that blocks inbound management
  5. call home flips only TCP

basics

~20 s

Dial in when the collector can reach every device and should own the subscriptions. Dial out when devices sit behind NAT or firewalls, or subscriptions must survive reboots: RFC 8639 configured subscriptions live in device configuration and connect to receivers themselves.

solid answer

~50 s

In **dial-in**, the collector is the client: it opens a mutually authenticated TLS connection to each device and calls gNMI `Subscribe`. The subscription lives exactly as long as that RPC, so the collector must reach all 2,000 devices and resubscribe after any restart. The IETF equivalent is a **dynamic subscription** (RFC 8639), created by `establish-subscription` and terminated when its transport session ends. In **dial-out**, the device initiates. The gNMI specification (OpenConfig, version 0.10.0) lists dial-out only as future work, so gNMI dial-out is implementation-specific. The standardised form is the RFC 8639 **configured subscription**: installed in the device's configuration, it persists across reboots and transport loss, can feed several receivers, and the device establishes the connection, for example with Call Home (RFC 8071). Choose dial-out when inbound management access is blocked or devices change address; choose dial-in when central control and quick changes matter more.

go deeper

for a junior

Recall the direction: in dial-in the collector connects to the device and subscribes; in dial-out the device connects to the collector and starts sending.

for a middle

Explain how lifetimes differ: a dynamic subscription is tied to its session, a configured one lives in device configuration, persists across reboots and can feed several receivers.

for a senior

Choose for a real estate: firewall direction, NAT, behaviour after collector or device restarts, gap detection through state change notifications, and gNMI dial-out being implementation-specific.

for a principal

Decide who owns telemetry intent, the automation platform or device configuration, and how that choice shapes change control, collector failover and security reviews.

## The question behind the terms "Dial-in" and "dial-out" ask one thing: **which side opens the connection, and where does the subscription live?** On an estate of 2,000 devices that decides firewall rules, what happens after a reboot, and who can change what is streamed. ## Dial-in: the collector connects and subscribes In gNMI (an OpenConfig specification, version 0.10.0, not an RFC) the collector is the **client** and the device is the **target**. 1. The collector opens a TLS session to the device. TLS is mandatory, with no fallback to an unencrypted session, and both ends validate each other's X.509 certificate. 2. It calls `Subscribe` and sends a `SubscriptionList`. 3. The subscription exists **only while that RPC is open**. Cancelling the RPC or losing the session ends it; the collector must subscribe again. The IETF's matching model is the **dynamic subscription** of RFC 8639: a subscriber creates it with the `establish-subscription` RPC, the receiver and subscriber are the same entity, and its lifetime is bound to the transport session. RFC 8640 (NETCONF) says that if the session that established it ends, the subscription must be terminated. Both IETF transport bindings, RFC 8640 for NETCONF and RFC 8650 for RESTCONF, cover **dynamic subscriptions only**. ## Dial-out: the device connects to its receivers The gNMI specification lists "dial out", meaning a target registering with a management system and publishing pre-configured subscriptions, under **outstanding issues and future features**. Products that dial out over gRPC therefore do so in their own way. The IETF standardised the device-initiated model as the **configured subscription** (RFC 8639, section 2.5): - It is **installed through configuration** and modified or deleted only by configuration operations. The subscription RPCs cannot touch it, and configuration cannot directly change a dynamic one. - It **persists across publisher reboots** and **while transport is unavailable**. - It can have **several receivers**, each named, and none aware of the others. - Support is optional, advertised by the `configured` feature, and transport parameters for each receiver come from a transport-specific augmentation. - Each receiver moves through states: `connecting`, then `active` once a `subscription-started` notification has reached it, `suspended` when buffers or CPU run short, and possibly `disconnected` if no connection can be made while connecting. - If records are lost because buffer capacity was reached, the publisher must send a new `subscription-started`, which tells the receiver there is a gap. To open the connection, RFC 8639 points to **Call Home** (RFC 8071). Call Home reverses **only the TCP role**: the device connects out to the client on port 4334 (NETCONF over SSH), 4335 (NETCONF over TLS) or 4336 (RESTCONF over TLS), but it stays the SSH or TLS server and the NETCONF or RESTCONF server, so existing certificates and authentication still work. ## Comparison | Question | Dial-in (dynamic) | Dial-out (configured) | |---|---|---| | Who opens TCP | collector | device | | Where the subscription lives | collector's RPC or session | device configuration | | After a device reboot | collector must resubscribe | restored from configuration | | After a collector restart | every subscription is lost | device reconnects to its receivers | | Receivers per subscription | the subscriber itself | one or more named receivers | | Who can change it | the original subscriber | any client allowed to write that configuration | | Firewall direction | inbound to every device | outbound from devices to a few collectors | ## Choosing on the estate - **Dial out** when devices are behind NAT or a firewall that allows no inbound management, have changing addresses, or must resume streaming without a collector's help after a reboot. RFC 8071 lists these situations, and adds that securing one open port in the data centre can be easier than an open port on every device. - **Dial in** when a central automation system should own what is streamed, needs to start and stop subscriptions often, and can reach every device. - Either way, plan what happens on loss. A dynamic subscription disappears with its session; a configured one suspends and resumes, and the receiver must watch the state change notifications to know whether it missed anything.

  • What happens to an RFC 8639 dynamic subscription over NETCONF when the session drops?
    RFC 8640 says that if the NETCONF session that carried `establish-subscription` terminates, the subscription must be terminated. Nothing is buffered for the subscriber; it must establish a new subscription and resynchronise. A configured subscription would instead keep its receiver in a `connecting` state and resume once transport returns.
  • Can a collector remove an RFC 8639 configured subscription with the delete-subscription RPC?
    No. RFC 8639 forbids mixing: a configured subscription cannot be modified or deleted with the subscription RPCs, and a dynamic one cannot be directly changed by configuration. You remove a configured subscription by deleting it from the `subscriptions` configuration, which any client with write permission on it can do.

saying these in an interview costs you the question

  • The gNMI 0.10.0 specification standardises device dial-out.
  • A dynamic subscription survives its NETCONF session closing.
  • With Call Home the device becomes the NETCONF client and sends RPCs.
  • A configured subscription can be removed with the delete-subscription RPC.
  • Dial-out removes the need for TLS and mutual authentication.