PROBE: A Utility for Probing Interfaces
RFC 8335

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, int-area@ietf.org, Luigi Iannone <ggx@gigix.net>, draft-ietf-intarea-probe@ietf.org, ggx@gigix.net, suresh@kaloom.com, intarea-chairs@ietf.org, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'PROBE: A Utility For Probing Interfaces' to Proposed Standard (draft-ietf-intarea-probe-10.txt)

The IESG has approved the following document:
- 'PROBE: A Utility For Probing Interfaces'
  (draft-ietf-intarea-probe-10.txt) as Proposed Standard

This document is the product of the Internet Area Working Group.

The IESG contact persons are Suresh Krishnan and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-probe/


Technical Summary

 This document describes PROBE, a new network diagnostic tool. PROBE is similar to the PING tool, since it can be used to test the status of a probed interface. However, differently from PING, it does not require bidirectional connectivity between the probing and probed interfaces. Bidirectional connectivity is required only between the probing interface and a proxy interface.  The latter can reside on the same node as the probed interface or it can reside on a node to which the probed interface is directly connected. This make PROBE useful in situations where PING would not work, e.g.:

   o  The probed interface is unnumbered
   o  The probing and probed interfaces are not directly connected to
      one another.  The probed interface has an IPv6 link-local address,
      but does not have a more globally scoped address
   o  The probing interface runs IPv4 only while the probed interface
      runs IPv6 only
   o  The probing interface runs IPv6 only while the probed interface
      runs IPv4 only
   o  For lack of a route, the probing node cannot reach the probed
      interface.

Working Group Summary

The tool proposed in the document document simply overcomes some of the PING shortcomings, and as such has raised interest. During the various presentations in the IntArea meetings no technical objections have ever been raised. Several people have commented on the document and authors addressed these comments.

Document Quality

 There is at least one implementation (by Juniper Networks) of the proposed
 mechanism.

Personnel

Luigi Iannone <ggx@gigix.net> is the Document Shepherd. Suresh Krishnan <suresh@kaloom.com> is the Responsible Area Director

RFC Editor Note