Subject: [Int-area] Alvaro Retana's No Objection on draft-ietf-intarea-probe-09: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Wed, 13 Dec 2017 13:17:16 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-intarea-probe-09: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) The Code field of the Request is set to 0 - what happens if a different
value is received?

(2) The Request includes 2 fields (Identifier and Sequence Number) that are
used “to aid in matching Extended Echo Replies to Extended Echo Requests”. 
Their use seems to be a local matter (as the values are simply copied in to the
Reply.  Can you please provide guidance on their use?  Why are there 2 fields
(and not just a single one)?  I’m assuming/hoping that the design had use cases
in mind that can be reflected in the document.

(3) It would be nice to set up a registry for the Reserved fields.

(4) I’m not sure I understand the use/intention of the L-bit.  The description
says that it is used (on the Request) to indicate whether the probed interfaces
resides on the proxy node (or not).  How does the originator of the Request
know that information?  The other function of this bit seems to be to control
how the Interface Identification Object can identify the probed interface…while
it seems to make sense that a probed interface that doesn’t reside on the proxy
node would only be identified by it’s address, it still makes me wonder how the
sender of the Request would know, and why it even matters that it does and that
it indicates it to the proxy node.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 15 Dec 2017 19:33:32 +0000

Alvaro,

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

                     Ron

> -----Original Message-----
> From: Alvaro Retana [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2017 4:17 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Luigi Iannone <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Alvaro Retana's No Objection on draft-ietf-intarea-probe-09: (with
> 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.)
> 
> 
> Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=d_E7NtGz7Mkv4ZHGdIjRM02eCQ1JZ_Yt4EEM6IC
> muk4&s=4NMprXR5y7Q_uFaDi3U-1CH5RCEEnk7dsr64WAgvz58&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dintarea-
> 2Dprobe_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=d_E7NtGz7Mkv4ZHGdIjRM02eCQ1JZ_Yt4EEM6IC
> muk4&s=em-7xrUp_9BjsRysGOLNV0SVdf0bFXg9jE7Pa5AQ_80&e=
> 
> 
> 

[RB ] 
Good catch. In version 10 the description will say "MUST be set to 0 and MUST be ignored on receipt".

> (and not just a single one)?  I’m assuming/hoping that the design had use
> cases in mind that can be reflected in the document.
[RB ] 
Appendix A describes the PROBE application. In version 10, I will add a sentence describing how the Identifier and Sequence Number are used.

> (3) It would be nice to set up a registry for the Reserved fields.
[RB ] 
Are you talking about the reserved fields whose value MUST be equal to 0 and MUST be ignored upon receipt?

Or are you talking about the following text:

      Protocol Flag Bit mappings are as
      follows: Bit 0 (IPv4), Bit 1 (IPv6), Bit 2 (Ethernet), Bits 3-15
      (Reserved).

If the later, that text has been removed. It was an artifact from a very early version of the draft.

> says that it is used (on the Request) to indicate whether the probed
> interfaces resides on the proxy node (or not).  How does the originator of
> the Request know that information?  The other function of this bit seems to
> be to control how the Interface Identification Object can identify the probed
> interface…while it seems to make sense that a probed interface that doesn’t
> reside on the proxy node would only be identified by it’s address, it still
> makes me wonder how the sender of the Request would know, and why it
> even matters that it does and that it indicates it to the proxy node.
> 
[RB ] 
The L-Bit helps to identify the probed node by specifying whether it resides on the proxy node or is directly connected to the proxy node. In at least one case, it is required for disambiguation.

For example, assume that a proxy node has two interfaces, ge-0/0/0.0 and ge-0/0/0.1. Both links have IPv6 link local addresses. The local side of ge-0/0/0.0 has the address fe80::dead:beef and the remote side of ge-0/0/0.1 has the same IPv6 link local address. If the ICMP Extended Echo Request identifies the probed interface by address, the L-bit disambiguates between the two similarly numbered interfaces.