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

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Dec 2017 13:54:10 -0800

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.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-probe/

----------------------------------------------------------------------
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://www.ietf.org/mail-archive/web/int-area/current/msg06136.html 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.

----------------------------------------------------------------------
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. :-)

---

From: Ron Bonica <[email-masked]>
Date: Fri, 15 Dec 2017 16:06:43 +0000

Hi Warren,

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

                           Happy Holidays,
                          Ron

> -----Original Message-----
> From: Warren Kumari [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2017 4:54 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Luigi Iannone <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> Subject: Warren Kumari's Discuss on draft-ietf-intarea-probe-09: (with
> DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> 
> 
> the document, but there isn't a "Comment" and "Very important comment"
> in the datatracker).
> 
> [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."
> 
> 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?

> (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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 15 Dec 2017 11:19:00 -0500

> - return the state of the neighbor cache entry

That sounds perfectly fine to me.
Note that I have cleared my DISCUSS on the telechat - I was only
holding it so that I got a chance to note on the call that these
changes will require what could be argued is a substantive change to
the document, and to make sure that, like me, the rest of the IESG was
fine with that.

The above sounds fine to me, and I (of course) trust y'all and Suresh
to make whatever changes seem sensible.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf