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:
> Please review and comment.
>
>                             Ron
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: Thursday, June 23, 2016 11:08 AM
> To: Ronald Bonica <[email protected]>; Reji Thomas <[email protected]>
> 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
>
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to