Re: [6lo] rgding 6775-update/EARO

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 28 July 2017 17:21 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0646A13216A for <6lo@ietfa.amsl.com>; Fri, 28 Jul 2017 10:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLbGxhh6pkwK for <6lo@ietfa.amsl.com>; Fri, 28 Jul 2017 10:21:42 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61AF132043 for <6lo@ietf.org>; Fri, 28 Jul 2017 10:21:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18164; q=dns/txt; s=iport; t=1501262501; x=1502472101; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=CRWjW9geSl1oUtfQSo6LaWfpM3cr2VNMuRq2Ay8PIvk=; b=O24CVs/kwr2HZWcvKaiNVv0FxHrdNy6WfqXJirBPMWiAHU5hIvn0xwi8 EqQ5v/jFf+i8cQjqALnOf0IaZL6jnIVBgsxkB5NPsJu3z4eIC94iRtCRS pMe76Jkp55MMzif1Llnpzwmk1D5Smx8K0LuXTZGQf89manYhWVOyl9AKx E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DTAQAZcntZ/4MNJK1dGgEBAQECAQEBAQgBAQEBgm9rZG0nB44Gj3qBa3WPZ4UvDoIEhUcCGoNYPxgBAgEBAQEBAQFrKIUYAQEBAQMjClwCAQgRBAEBKAMCAgIwFAkIAgQBEgiJQ2SwM4Imiz8BAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyiDTYFhgnM0hFtOgl2CYQWXYIgNApQbghWQMIlTjB4BHziBCncVhV8cgWd2iHKBDgEBAQ
X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208,217";a="458020309"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 17:21:40 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6SHLeEM010604 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 17:21:40 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Jul 2017 12:21:40 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 28 Jul 2017 12:21:40 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Rahul Jadhav <rahul.ietf@gmail.com>, lo <6lo@ietf.org>
Thread-Topic: [6lo] rgding 6775-update/EARO
Thread-Index: AQHTAJpuIReQXGcTwk2GqQcsGeWFv6JpiP7w
Date: Fri, 28 Jul 2017 17:21:26 +0000
Deferred-Delivery: Fri, 28 Jul 2017 17:20:57 +0000
Message-ID: <f7d473eef4754baaa4720ac7c92cb0f4@XCH-RCD-001.cisco.com>
References: <CAO0Djp3w=4Gz6Dthh7DsEGGHvu_Tha0CLav1_vRqk1169VsB1A@mail.gmail.com>
In-Reply-To: <CAO0Djp3w=4Gz6Dthh7DsEGGHvu_Tha0CLav1_vRqk1169VsB1A@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.82.156]
Content-Type: multipart/alternative; boundary="_000_f7d473eef4754baaa4720ac7c92cb0f4XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/1Xty8hEtpJX2TQPp0F6f7IQsNqQ>
Subject: Re: [6lo] rgding 6775-update/EARO
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jul 2017 17:21:44 -0000

Hello Rahul :

I am reintroducing the TID freshness evaluation now copied from RPL, as we discussed at the meeting.

About cleaning up, the current text has:
«
   A node that ceases to use an address SHOULD attempt to deregister
   that address from all the 6LRs to which it has registered the
   address, which is achieved using an NS(EARO) message with a
   Registration Lifetime of 0.

   A node that moves away from a particular 6LR SHOULD attempt to
   deregister all of its addresses registered to that 6LR.

   Upon receiving a NS(EARO) message with a Registration Lifetime of 0
   and determining that this EARO is the freshest for a given NCE (see
   Section 4.2), a 6LR cleans up its NCE.  If the address was registered
   to the 6LBR, then the 6LR MUST report to the 6LBR, through a DAR/DAC
   exchange with the 6LBR, or an alternate protocol, indicating the null
   Registration Lifetime and the latest TID that this 6LR is aware of.

   Upon the DAR message, the 6LBR evaluates if this is the freshest EARO
   it has received for that particular registry entry.  If it is, then
   the entry is scheduled to be removed, and the DAR is answered with a
   DAC message bearing a Status of 0 "Success".  If it is not the
   freshest, then a Status 2 "Moved" is returned instead, and the
   existing entry is conserved.  The 6LBR SHOULD conserve the address in
   a DELAY state for a configurable period of time, so as to protect a
   mobile node that deregistered from one 6LR and did not register yet
   to a new one.

«

Is there anything missing ?

Take care,

Pascal

From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Rahul Jadhav
Sent: mercredi 19 juillet 2017 16:22
To: lo <6lo@ietf.org>
Subject: [6lo] rgding 6775-update/EARO

Hello Pascal,

This is the same query as what i raised during the 6lo session. Like it was pointed out, better to take it on ML.

The new mechanism described in the draft allows a proxy registration on behalf of the "target node" using EARO.
My question is: Will de-registration be possible for such targets, especially considering that state information (in the form of TID) is maintained for such registrations?
It will be helpful to clarify in the document.

Thanks,
Rahul