Subject: [Roll] Mirja Kühlewind's Discuss on draft-ietf-roll-efficient-npdao-12: (with DISCUSS and COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 25 Jun 2019 10:14:48 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-roll-efficient-npdao-12: 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-roll-efficient-npdao/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a small discuss that should be easy to address:

Sec 4.3: " The number of retries are implementation and deployment
   dependent."
(and also sec 4.4 point 6)

Please specify a maximum number of retries and also a minimum retry interval
(of e.g. 3 sec best with exponential back-off)!

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

One question on section 4.6.2: You present use of NPDAO and DCO as two options,
however, the problem with the I flag is that the sender does not know if the
ancestor understand the signal. Wouldn't it also make sense to use both in some
cases, e.g. send DAO with I flag first and if you don't receive a DCO after
some limited time, you also send the NPDAO?

Nits:
sec 1.2: s/so that the node changing it routing adjacencies/so that the node
changing its routing adjacencies/ -> "it" instead of "its"

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Thu, 27 Jun 2019 01:00:04 +0000

Thanks Mirja for the review and feedback.
For the DISCUSS point, I have to reach out to WG to check if anyone has specific recommendations towards this. There is also a similar messaging in parent document RFC 6550 which also does not explicitly puts how this retry should happen.
Please find my responses inline.

Thanks,
Rahul

Please specify a maximum number of retries and also a minimum retry interval (of e.g. 3 sec best with exponential back-off)!

[RJ] Section 4.3 says that it is implementation and deployment dependent. We have avoided to put an exact number here because of the differences in physical layers and wireless dense/sparse deployments this could be used on. I am not sure if putting an exact value like specifying 3 retries or 4 retries is ok. I don't know what to base this value/recommendation on. The DCO/DCO-ACK retry mechanism emulates DAO/DAO-ACK retry mechanism from RFC 6550 which also has not put an explicit details for this.

One question on section 4.6.2: You present use of NPDAO and DCO as two options, however, the problem with the I flag is that the sender does not know if the ancestor understand the signal. Wouldn't it also make sense to use both in some cases, e.g. send DAO with I flag first and if you don't receive a DCO after some limited time, you also send the NPDAO?

[RJ] Yes, it is possible for a node to use both DCO and NPDAO. Section 4.6.2 specifies this in detail.

Nits:
sec 1.2: s/so that the node changing it routing adjacencies/so that the node changing its routing adjacencies/ -> "it" instead of "its"

[RJ] Will fix this.