[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
- [rrg] [ILNP] What to do when Locator Updates are … Stephane Bortzmeyer
- [rrg] [ILNP] What to do when Locator Updates are … Ran Atkinson
- Re: [rrg] [ILNP] What to do when Locator Updates … Stephane Bortzmeyer