Re: [Int-area] Warren Kumari's Discuss on draft-ietf-intarea-probe-09: (with DISCUSS and COMMENT)

[Ron Bonica <[e-mail]>]

Hi Warren,

Thanks for the review. Comments inline.......

                           Happy Holidays,
                          Ron

> -----Original Message-----
> From: Warren Kumari [mailto:[e-mail]]
> Sent: Wednesday, December 13, 2017 4:54 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Luigi Iannone <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]
> Subject: Warren Kumari's Discuss on draft-ietf-intarea-probe-09: (with
> DISCUSS and COMMENT)
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-intarea-probe-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This is, I believe a minor DISCUSS, and I'll happily clear it once a commitment
> is made that it will be addressed / on the call (AKA, I'm not going to hold up
> the document, but there isn't a "Comment" and "Very important comment"
> in the datatracker).
> 
> Stefan Winter's OpsDir review contains:
> "* Introduction
> states "[...] if it appears in the IPv4 Address Resolution Protocol (ARP) table
> [RFC0826] or IPv6 Neighbor Cache [RFC4861]." "Appears" is a rather loose
> word, as entries in those tables can have multiple states. E.g. for IPv6, which
> of the states DELAY, STALE, REACHABLE do you mean? All? Or only a subset?
> In IPv4, do you mean the "C" flag exclusively? Also, when the proxy operates
> remotely (i.e. bases the reply on ARP/Neighbor Cache rather than
> ifOperStatus), does it actively ping the interface in question itself? If not,
> how does it handle an interface address which is not in the ARP/Neighbour
> table simply because the entry has timed out? The interface might be up and
> active nontheless. In such a case, reporting "does not exist" is false."
> 
> Ron Bonica's suggested solution in:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-
> 2Darchive_web_int-
> 2Darea_current_msg06136.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBX
> eMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=-FTEnwX0qAUuswd5C59LJixx92pB-
> lCmDysSzvMuD4E&s=eYX_7OsniE8LwWIAtu0fANguom6rE7Uvol5fgVcNQCU&
> e= works for me, but I do not see it in the version being discussed. This
> would make a substantive change to the document, I wanted to draw
> attention to it.
> 
[RB ] 
Stephan raised the following legitimate points:

1) The presence of an ARP TABLE / Neighbor Cache entry on the proxy node is not sufficient evidence to prove that the probed interface is active
2) The absence of an ARP Table / Neighbor Cache entry on the proxy node is not sufficient evidence to prove that the probed interface does not exist

We addressed the second point by changing an error message. When the proxy node probes the ARP Table / Neighbor Cache and finds nothing, it used to return an ICMP Echo Reply with code equal to "No Such Interface". Now it returns an ICMP Echo Reply message with code equal to "No Such Table Entry". This is more accurate.

Frankly, we didn't address Stephan's first point. I think that we should address it by making the ICMP Echo Reply Message report more accurately. Specifically, when the proxy node searches the ARP Table / Neighbor Cache and finds an entry:

- Set the code to 0 (No Error)
- Clear the A-bit, the 4-bit and the 6-bit
- return the state of the neighbor cache entry

What do you think?


> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In the version I'd initially reviewed there were codes for things like: "E
> (Ethernet) - The E-bit is set if the A-bit is also set and IPv4 is running on the
> probed interface.  Otherwise, the E-bit is clear." I was going to fuss and ask
> what makes Ethernet special -- but, seeing as this is removed in the newest
> version I have nothing to fuss about. :-)
>