Subject: [rrg] [ILNP] What to do when Locator Updates are lost

From: Ran Atkinson <[email-masked]>
Date: Tue, 17 Jul 2012 16:18:23 -0400

Hi,

ICMP Locator Updates are acknowledged.  If the sender
doesn't receive an acknowledgement from a correspondent,
then the sender knows that either (more likely) the 
correspondent hasn't seen the ICMP Locator Update message 
yet or (less likely) the ICMP LU ACK was lost.  So an 
unacknowledged LU is sufficient information for the 
sender to realise that it ought to resend the LU to the 
correspondent node.

The precise frequency and interval of retransmissions 
for LU messages is difficult to specify in a precise and
correct manner absent more operational experience with 
ILNP implementations.  So we've left that detail for a 
future specification revision, when there is enough 
experience to recommend a specific retransmission 
interval/scheme for LU messages/ACKs.

A single received packet that authenticates due to the Nonce
option is not sufficient information to know whether or not
the previously-known set of Locators remain valid or not.
All the receiver knows is that that one Source Locator is
valid.  So I would not recommend deleting other Locators
for that correspondent node from an ILCC instance on the 
basis of a single received packet.

While the ILNP drafts were available for a good while,
to give people time to review and comment, the authors 
have been told very explicitly that no specification 
edits are allowed at this time.  A few implementer-driven
clarifications made it in between -05 and -06, but
no protocol changes occurred then either.

We do welcome questions and feedback, but we can't edit the 
current ILNP I-Ds, since they are in the RFC Editor queue.

Thanks very much,

Ran

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 18 Jul 2012 10:28:38 +0200

On Tue, Jul 17, 2012 at 04:18:23PM -0400,
 Ran Atkinson <[email-masked]> wrote 
 a message of 47 lines which said:

> The precise frequency and interval of retransmissions for LU
> messages is difficult to specify in a precise and correct manner
> absent more operational experience with ILNP implementations.  So
> we've left that detail for a future specification revision,

Makes sense. And I understand it is too late to add anything in the
draft. Keep it in mind for a future revision? It is an interesting
problem.

> the authors have been told very explicitly that no specification
> edits are allowed at this time.

It does not prevent to fix the "compression" bug in
draft-irtf-rrg-ilnp-dns-06, I presume?