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

Ran Atkinson <ran.atkinson@gmail.com> Tue, 17 July 2012 20:17 UTC

Return-Path: <ran.atkinson@gmail.com>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B30C21F8663 for <rrg@ietfa.amsl.com>; Tue, 17 Jul 2012 13:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lV7v9QmAQMs for <rrg@ietfa.amsl.com>; Tue, 17 Jul 2012 13:17:39 -0700 (PDT)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id C716421F8621 for <rrg@irtf.org>; Tue, 17 Jul 2012 13:17:39 -0700 (PDT)
Received: by qcsg15 with SMTP id g15so663107qcs.13 for <rrg@irtf.org>; Tue, 17 Jul 2012 13:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=o1qgXN+vIWLxKcOLlaklw1cFqSvKK35d18jenW3vHLk=; b=MOgU0YSekmIoSBxvJv5uPkCxZ22YFbLirbaia08OENgMZwbGnEHgHwyf45baNIQqRv KVazE8iZ+kFHGROapEjB29tg7iTkTgnwxbJlNlrVariOS5RdgddD5vahIintg/EuqO9G R3+ouXFj9CKdNIK7NPXFSjkXTHJsP9SLos8iXoE0M18lHlf+WmcGleXhzfMlZ168RDRX UX/Zi0vUCuB+4r+R0Aqd6njqi4swF50QAS7aR3ZrT5BEkR5Qg4iCMZWys4hMy8SXswj1 jXxa64iqh1tiIoe9ovXfRL/RbhnyM0prgUmkh1B6ZVMytZHSfxXFGk9kRzl5gx/Our+x VA9g==
Received: by 10.224.203.8 with SMTP id fg8mr1617936qab.38.1342556307432; Tue, 17 Jul 2012 13:18:27 -0700 (PDT)
Received: from [10.30.20.12] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id et8sm27725423qab.9.2012.07.17.13.18.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 13:18:26 -0700 (PDT)
From: Ran Atkinson <ran.atkinson@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Tue, 17 Jul 2012 16:18:23 -0400
Message-Id: <9ACA09DB-4312-4CAB-8AC7-647903749F87@gmail.com>
To: IRTF Routing RG <rrg@irtf.org>
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
Subject: [rrg] [ILNP] What to do when Locator Updates are lost
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2012 20:17:40 -0000

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