Subject: [Int-area] FW: New Version Notification for draft-bonica-intarea-eping-00.txt

From: Ronald Bonica <[email-masked]>
Date: Thu, 23 Jun 2016 17:50:58 +0000

Please review and comment.

                            Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 23, 2016 11:08 AM
To: Ronald Bonica <[email-masked]>; Reji Thomas <[email-masked]>
Subject: New Version Notification for draft-bonica-intarea-eping-00.txt

A new version of I-D, draft-bonica-intarea-eping-00.txt has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:		draft-bonica-intarea-eping
Revision:	00
Title:		Extended Ping (eping)
Document date:	2016-06-23
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-bonica-intarea-eping-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bonica-intarea-eping/
Htmlized:       https://tools.ietf.org/html/draft-bonica-intarea-eping-00

Abstract:
   This document describes a new diagnostic tool called Extended Ping
   (eping).  Network operators execute eping to determine whether a
   remote interface is active.  In this respect, eping is similar to
   ping.  Eping differs from ping in that it does not require network
   reachability between itself and remote interface whose status is
   being queried.

   Eping relies on two new ICMP messages, called Extended Echo and
   Extended Echo Reply.  Both ICMP messages are defined herein.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 Jun 2016 14:11:05 -0700

Hi, Ron, et al.,

I'm a little confused at this proposal.

First, IP addresses can be assigned to interfaces or hosts. Interfaces
don't have to have IP addresses, esp. point-to-point interfaces or those
used "anonymously" (e.g., for broadcast send/receive).

Second, I think the claim that this can measure "unreachable" interfaces
is misleading. The doc assumes that the probed interface IS reachable -
e.g., AFAICT, you can't find out anything that ICMP hopcount-exceeded
wouldn't report. The only difference is that you can control the target
better and that the response comes back as an Echo-reply (which might be
less likely to be blocked than hopcount-exceeded).

Third, the destination interface and probed interface need to share the
same network stack, not just be on the same node. There are network
stacks that isolate processing for different interfaces, which might not
be able to see the state of other interfaces inside the same machine.

Bug:

   Because the Extended Echo message makes a distinction between the
   destination and probed interfaces, eping can probe every interface on
   a node if it can reach any node on the node.  

I think you mean "if it can reach any interface on the node", but again
this is misleading as per above.

Additionally, I think this might have an existing equivalent when the
probed interface has an address, e.g., it really seems like it ought to
be equivalent to an IP with LSR whose destination IP is the
"destination" and whose probe IP is the LSR "next hop". In a sense, it
seems like you're just extending ping with LSR that allows for using
ifName, ifIndex, or non-IP addresses rather than just IP addresses. It
might be useful to describe that way, FWIW.

Also, IMO, the "hopcount" of this test ought to be decremented by 1 if
the probed interface is not the received interface. Otherwise, you'd be
reporting the same hopcount for the incoming interface and forwarded
outgoing interfaces, which doesn't seem right to me.

Joe

On 6/23/2016 10:50 AM, Ronald Bonica wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 30 Jun 2016 02:22:30 +0000

Hi, Ron,

Scanning through the document, please find a couple of quick questions and comments:

  1.  Have you considered an approach as in draft-shen-traceroute-ping-ext<https://tools.ietf.org/html/draft-shen-traceroute-ping-ext>, which is more general and has potentially better changes of success (working on ICMP Echo but also UDP Ping and TCP Ping)?
  2.  What is the reason for the “by address” option? The main use case of this functionality as defined seems to be unnumbered / link-locals. And if there’s a need for “by address”, a proxy ping is more general.
  3.  The “by ifIndex” option is essentially pulling operational state out of a box — what’s the line between an SNMP get or reading operational info on /interfaces-state/interface/oper-status vs. getting other node operational info (get CPU%)? And in this context, what’s the Auth model?

Thanks!

— Carlos.

On Jun 23, 2016, at 1:50 PM, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:

                           Ron

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, June 23, 2016 11:08 AM
To: Ronald Bonica <[email-masked]<mailto:[email-masked]>>; Reji Thomas <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-bonica-intarea-eping-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area