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

From: Ronald Bonica <[email-masked]>
Date: Fri, 1 Jul 2016 16:47:54 +0000

Hi Joe,

Good to hear from you! Responses inline.......

                                     Ron

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Wednesday, June 29, 2016 5:11 PM
> To: Ronald Bonica <[email-masked]>; [email-masked]
> 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

---

From: Joe Touch <[email-masked]>
Date: Fri, 1 Jul 2016 10:24:42 -0700

Hi Ron,

> Good to hear from you! Responses inline.......

Same here on both counts...
> Absolutely. In the draft, we talk about "unnumbered interfaces". These are interfaces to which an IP address has not been assigned.
I'm talking about numbers assigned to the host, not the interface. What
kind of response are you expecting there?
...
> 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 possi…
That'd be useful to include in the justification for this (if not
already there - I haven't scanned it that deeply).

> 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 pr…
I'm referring to software stack, not protocol-compatibility stack.
FreeBSD allows  you to deploy multiple independent stacks associated
with different subsets of interfaces and addresses -- a stack that
implements this solution might not be capable of exchanging information
between software stacks.
...
> I'm not sure that I follow this paragraph.
Let's say a device has two interfaces with addresses A and B.

I might not be able to ping address B because of routing between me and
that device.

However, I might be able to ping B via a LSR through A.

Isn't that largely how this IDs approach works when you're using a
single AF with numbered interfaces?

> Just to be specific, which packet should have its hopcount decremented and by which node?

Hops account for relaying, not link traversal (RFC1812).

Hopcount should always be decremented during the relaying process. That
means when it arrives at a node, the hopcount is NOT decremented before
accepting it on the address of the incoming interface, but IMO it really
ought to be decremented before accepting it on the address of an
outgoing interface.

Joe

---

From: Ron Bonica <[email-masked]>
Date: Tue, 5 Jul 2016 14:54:15 +0000

Inline......

> Sent: Friday, July 1, 2016 1:25 PM
> >> 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.
> I'm talking about numbers assigned to the host, not the interface. What kind
> of response are you expecting there?
> ...
[RB ] 
[RB ] 
Since the host has an address, the destination and probed addresses would be the same. In this case, eping behaves exactly the same as traditional ping.

> >> 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.
> That'd be useful to include in the justification for this (if not already there - I
> haven't scanned it that deeply).
>
[RB ]
[RB ] 
Will do.

> >
> >> 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.
> FreeBSD allows  you to deploy multiple independent stacks associated with
> different subsets of interfaces and addresses -- a stack that implements this
> solution might not be capable of exchanging information between software
> stacks.
> ...
[RB ] 
Good point. I'll catch that in the next version.

> >
> >> 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 ]
[RB ] 
Ah! Now I understand what you are saying.

Let's do a thought experiment. Assume that a router has three interface, A, B, and C. Assume also that all three interfaces are up.  A network operator needs to know the status of Interface B, so he executes traditional PING. The ICMP Echo Request message enters the router through Interface C and the ICMP Echo Response leaves through Interfaces C. The operator learns that Interface B is up, but he does not know whether his ping exercised interface B. (In this case, it didn't.)

The next day, the operator removes the address from interface B, so he can't ping it any longer. But he needs to know Interface B's status. So, he sends executes eping, with Interface A as the destination interface and Interface B as the probed interface. The ICMP Extended Echo Request message enters the router through Interface C and the ICMP Extended Echo Response leaves through Interfaces C. The operator learns that Interface B is up, but he does not know whether his ping exercised interface B. (In this case, it didn't.)

> ought to be decremented before accepting it on the address of an
[RB ] 
Agree

             Ron

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Jul 2016 08:25:24 -0700

Hi, Ron,

> Since the host has an address, the destination and probed addresses would be the same. In this case, eping behaves exactly the same as traditional ping.
I'm referring to the text, not the behavior. I agree the behavior would
be as expected.

The text should address the case above, however - it should not assume
that all IP addresses are always associated with interfaces.

...
> The next day, the operator removes the address from interface B, so he can't ping it any longer. But he needs to know Interface B's status. So, he sends executes eping, with Interface A as the dest…
The case you're giving is the one in which an operator can find out
about an interface without an IP address - which I agree this method
enables.

I'm speaking of a different case:

- send a ping to interface B
    let's say that ping fails because you don't have a route to B
    that would fail for both ping and eping

- send a ping to interface C
    let's say that works because you do have a route to C
    that would work for both ping and eping

- send a ping LSR to B via C
    that ping seems like it would work now, i.e., LSR ping would reach B
and get a response through C even though B isn't directly reachable
    that would work for both ping and eping

The unique aspect of eping is being able to ping (or get status) about
interfaces without names. Both LSR ping and eping are equally capable of
getting status about an *address* that is not otherwise reachable (e.g.,
because of routing issues).

Joe

---

From: Ron Bonica <[email-masked]>
Date: Tue, 5 Jul 2016 18:29:00 +0000

Hi Joe,

That's right. If we used LSR Ping, the probed interface would have to be numbered.

                                                  Ron

>     that ping seems like it would work now, i.e., LSR ping would reach B and get
> a response through C even though B isn't directly reachable

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Jul 2016 11:31:44 -0700

OK - what I'm suggesting is discussing how this approach is similar to
LSR ping for numbered interfaces. I think it's a useful additional point
to make and helps motivate the need for the rest of the approach - for
unnumbered interfaces.

Joe