Inline......
> -----Original Message-----
> From: Joe Touch [mailto:[email protected]]
> Sent: Friday, July 1, 2016 1:25 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,
>
> On 7/1/2016 9:47 AM, Ronald Bonica wrote:
> > Hi Joe,
> >
> > Good to hear from you! Responses inline.......
>
> Same here on both counts...
> >
> > Ron
> >
> >> 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.
> 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.
> ...
[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 ]
> > 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?
>
[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.)
> >> 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?
>
> 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.
>
[RB ]
Agree
Ron
> Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
