Hi Joe,
Good to hear from you! Responses inline.......
Ron
> -----Original Message-----
> From: Joe Touch [mailto:[email protected]]
> Sent: Wednesday, June 29, 2016 5:11 PM
> To: Ronald Bonica <[email protected]>; [email protected]
> Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-
> eping-00.txt
>
> Hi, Ron, et al.,
>
> I'm a little confused at this proposal.
[RB ]
"Confusion is the welcome mat at the door to creativity." :-)
>
> 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).
[RB ]
Absolutely. In the draft, we talk about "unnumbered interfaces". These are
interfaces to which an IP address has not been assigned.
>
> Second, I think the claim that this can measure "unreachable" interfaces is
> misleading. The doc assumes that the probed interface IS reachable - e.g.,
[RB ]
You have a good point. I am using the words "unreachable" and "unaddressable"
interchangeably. They aren't synonyms.
An interface is totally unreachable if its operational status is down. It might
be partially unreachable if it is partially isolated by ACLS. That isn't what
we are talking about in the draft. In the draft, we are talking about
unaddressable interfaces. While it may be possible to send a packet *through*
an unaddressable interface, it is not possible to send a packet *to* an
unaddressable interface. For example, it is impossible to send a packet to an
unnumbered interface. It is also impossible to send a packet to an interface
whose only address is link local from an off-net device.
I will fix this in the next draft version.
> 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).
[RB ]
There is another difference. In order to determine the status of the probed
interface using hopcount-exceeded, you have to make the probe packet traverse
the probed interface. This may not be possible. This is why we need both
(traditional) ping and traceroute today.
>
> 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.
[RB ]
Not always. For example, in our implementation, it is possible to identify the
destination by IPv4 address and the probed interface by IPv6 address. Yet IPv4
and IPv6 are different network layer protocols.
>
> 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.
[RB ]
Same response as 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.
[RB ]
I'm not sure that I follow this paragraph.
>
> 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.
[RB ]
Just to be specific, which packet should have its hopcount decremented and by
which node?
As always, thanks for the careful review
Ron
>
> Joe
>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
