Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 15 April 2020 11:35 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E832E3A0AD1 for <roll@ietfa.amsl.com>; Wed, 15 Apr 2020 04:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=OvC2jtry; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YRu4NARY
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 gUXAsculbNKM for <roll@ietfa.amsl.com>; Wed, 15 Apr 2020 04:35:37 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E0A3A0AD0 for <roll@ietf.org>; Wed, 15 Apr 2020 04:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=79138; q=dns/txt; s=iport; t=1586950537; x=1588160137; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=doD+Cc0W3S1KGPh+becrD9ybSeqcj3diVdF5MapMxsU=; b=OvC2jtryVt0olczPyg58mUu8sGGCY83bnX2eHNE3VvAqod/LaTxoL9N4 qH1vNwL/1N4aeuvfKx8HGX/A/MmRLac4Cj5owgUr8rBt2xAigXn6yINkF EjCcphI+f5te8HKBww4RVcc0rO2NLPGRtsjcr6545F90LfM9cBK72fLu1 s=;
IronPort-PHdr: =?us-ascii?q?9a23=3A7Ok7wRFV+WzVlPthY+kwvZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrEwAS8JZe/4oNJK1mHQEBAQkBEQU?= =?us-ascii?q?FAYF7gSUBLiknBWwPSSAECyqDXECDRgOKaU6CEYEBlyOBQoEQA1AECgEBAQw?= =?us-ascii?q?BARgBCgoCBAEBhEQCF4FsJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQM?= =?us-ascii?q?BAQoGCAkKEwEBJQcMDwIBBgIRBAEBIQEGAwICAiULFAkIAgQTCBqCOUYEAoF?= =?us-ascii?q?+TQMuAQ6SaZBnAoE5iGJ1gTKDAAEBBYUWGIIOAwaBOIJjgkKHERqBQT+BEUO?= =?us-ascii?q?BT0kHLj6CZwEBAgGBRAQBGysJglwygi2RIIYNikePcQqCQod+gWmOCYJUiEa?= =?us-ascii?q?NJINwhGWJMYp9kx0CBAIEBQIOAQEFgWkiDYFKcBU7gmlQGA2RWAwXg1CFFIV?= =?us-ascii?q?BdAKBJ44cAQE?=
X-IronPort-AV: E=Sophos;i="5.72,386,1580774400"; d="scan'208,217";a="463666684"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Apr 2020 11:35:36 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 03FBZaom019836 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Wed, 15 Apr 2020 11:35:36 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Apr 2020 06:35:35 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Apr 2020 07:35:34 -0400
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 15 Apr 2020 06:35:34 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I8gMA9qG32aJ5IcT6mroplfi7GpghwOL2jHWkpJrr5j7liTPsNe7QHUOcFfgnF2m6RT9qZMNRGKrJPWhHXRe3xsX+s+J85bIuMFRqivmmaddGnu6E9FHm8vn2vY9xtW5W/RJDoR7DrkKjhJYAXjD4qn3eBV0DS0mdMue2HhAqTJTi0ZgAuDXeC5NSqTOmbtpd4+gPWiU1lgk1MN0IFo+hByo9roouL2xVNQ9bN5emz18p9WS7TknRtJuTu1+61XVTlFIGOsQHXiGKFoj+mEzuuiF09PmVLDxLEc3gSIbSEsB7tjA++ylzBTISgyHdFS8GJk2b7l0b6eGsCThInn97Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=doD+Cc0W3S1KGPh+becrD9ybSeqcj3diVdF5MapMxsU=; b=WHcisnmQRL+nyv1SJFSwSL78BEtw888ndyXddLJEcJk8WCRPdWCz+O9uMHU3AGvMeDg/RpWaro5S/SOePC098L4Gtw/kMc/PEwg3jouW2wvRNChJV3JZ3c/Amml9IUaMGeJ5x6SbhRQQfNRacdEec7Tgs6oqvyQybZwzUdHI8a1gMYKTplImRyMw3njp/xRSVZVRs8BvR5OboV/2UJ6+jYrQh3Op30IyoqELv9kcS2HWsD3msNyOrkDTL4BQJHOcTGezz+ufFgElegkFhAyAzYp5b32BMPrMOVyGKMgBj7iE/zWALr9jO9U/CMiZwgVQDY6/fxuBhAPKXBxn5rWcYA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=doD+Cc0W3S1KGPh+becrD9ybSeqcj3diVdF5MapMxsU=; b=YRu4NARYaSm5PuzRqvla8UcSVLmJr0TQVYo4WxqQI8B+FYFcvkJVeOzmCVweE5UA3Y9wO6kb/PxWzsGZuRew5Z+8nW/cVgISIdOQaoBXdB0Tlu63WdZYgD3D2vBy+tvSko4r/FUe+Eirc+jpWSTcfCnDk3aPQ+Wn/HcovrnU+yM=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3933.namprd11.prod.outlook.com (2603:10b6:208:13d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Wed, 15 Apr 2020 11:35:33 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2900.028; Wed, 15 Apr 2020 11:35:33 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] unaware leaves - graceful shutdown of attached-6LR
Thread-Index: AQHWEZQvbgNuDRZQpEGmjIYHLkz6MKh3KT0IgAC0VwSAAFNOAIAAGVODgAAZELCAABxgnIAAFPGAgAAC4lCAAXdBwA==
Date: Wed, 15 Apr 2020 11:35:19 +0000
Deferred-Delivery: Wed, 15 Apr 2020 11:34:53 +0000
Message-ID: <MN2PR11MB35655E925F0FAA85E75E7A7CD8DB0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <BM1PR01MB4020A5C1C43CDC700477C39EA9DA0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>, <MN2PR11MB3565E4FB6ECA0B86327478FCD8DA0@MN2PR11MB3565.namprd11.prod.outlook.com> <BM1PR01MB4020DBE40E76D2EAE97C9611A9DA0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>, <MN2PR11MB35653AEC812269C1BF5D8CC4D8DA0@MN2PR11MB3565.namprd11.prod.outlook.com> <BM1PR01MB4020EF7E08144EB39D1F9433A9DA0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>, <MN2PR11MB3565C5E0EBC2E0A55593F0EBD8DA0@MN2PR11MB3565.namprd11.prod.outlook.com> <BM1PR01MB4020EC14D4C01D863D180FF3A9DA0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <BM1PR01MB4020EC14D4C01D863D180FF3A9DA0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:686b:95ad:c883:2bca]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 506a4bd0-0fa2-48b5-53b4-08d7e1311bfd
x-ms-traffictypediagnostic: MN2PR11MB3933:
x-microsoft-antispam-prvs: <MN2PR11MB3933B73D47A6534083B2F546D8DB0@MN2PR11MB3933.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0374433C81
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(366004)(346002)(136003)(33656002)(86362001)(76116006)(6666004)(7696005)(71200400001)(8936002)(9686003)(316002)(55016002)(52536014)(66476007)(66574012)(5660300002)(478600001)(66946007)(6916009)(45080400002)(30864003)(66446008)(2906002)(81156014)(53546011)(66556008)(64756008)(8676002)(6506007)(966005)(186003)(579004); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 31DqUy/hdLgIfi9TmIREFblyVqLsLU+CDd7Hmfe3rtvUF3qq8W7RkDtTwDno0DkqOZaayzinKPMCciUsgIYCFDFFmmmQAjgMlWhTXK97wfF2F8fBNeOvgc+c8B6As+O85HppOqCeZI7w9/P/ETKprglSy2XcgwHszAQoeM9VUE/4i2Wz/h2HAK5q8q/28fCxSwdUPYlnTw5Pp7kM58uEDqHT2YFMjlUOiLkdjEVsp9nd/jFJEnBWslHW0SPd3aYncgZN9AFkJ6Fv1+tQRQCoRHq4MuHeWygW2tQxTw62wXq6s6vMFvXYQj9eGr8AK2MI2Jp+92wiNgeiKvCMwbIqoGhHwCE6yjZ6qRpUDuKBTWTvasV6hWK3086es6xelyA0uNXLvJXo6X2beObVX95erXhtEzV6P3PKZwAb5+WudkdPJo0z5+lE/yW9QUGwLj95hw86/pepA5OvQnlkEw+dSWQzrVIHYJmvmMDgGUfd4RZIMpczoR8xcemy8P+/fUZVMUxKRnNoHwBXmwSTEHunyw==
x-ms-exchange-antispam-messagedata: X1/kPaQLpobBR2/Uv2/csKdpvnP7bYQX+N1LK5Xob7Q07eLWdUFk6qVNSY+nOj9R/N1ksnXGEcIUMMa7StNgBJ6e84pR1MBvLCq+tT4hBtmz53rsv5ScTfJo01tdvUtoiWqv2nOV/XXT4RvNBQycEuNReEkJczSsU8mZ+CGOVtkmQk+pI4Z2N3zSV+yds4dY0CYR5rtwhS6/bVL8KZmyZg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35655E925F0FAA85E75E7A7CD8DB0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 506a4bd0-0fa2-48b5-53b4-08d7e1311bfd
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 11:35:33.3639 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EbfSRZE6uJ/fANAVc3240QmWU691xP0nw6gPOcaHTqsGEVnBYzu/lh+QcTj6b1kZ371MuvgEuiRQkYY79FCkQQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3933
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/bJkYi6T6rBm04WMcI6wN2d-k2Lk>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2020 11:35:40 -0000

Hello again Rahul.

So I’ll add:

“

   The 6LN signals the termination of a registration with a 6LR using an
   NS(EARO) with a Registration Lifetime set to 0.  Upon this, the 6LR
   MUST perform an EDAR/EDAC exchange to clean up the state at the 6LBR,
   as illustrated in Figure 8, unless it uses the ROVR in the RPL
   Target Option and, in Storing Mode, it is propagated to the Root.

“
And

“
   The 6LR may at any time send a unicast asynchronous NA(EARO) with the
   "R" flag reset to signal that it stops providing routing services,
   and/or with the EARO Status 2 "Neighbor Cache full" to signal that it
   removes the NCE.  It may also send a final RA, unicast or multicast,
   with a Router Lifetime field of zero, to signal that it stops serving
   as router, as specified in section 6.2.5 of [RFC4861].

“

With this I believe we’re done. Please have a final look when I post 14.

Many thanks again!

Pascal


From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav
Sent: mardi 14 avril 2020 15:06
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

Yes, it does make sense.
I think this covers it all.

Thanks,
Rahul
________________________________
From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>>
Sent: 14 April 2020 08:59 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR


Hello Rahul



The RA would be a traditional final RA.



1.       If the 6LR stops being a router at all the signal is a final RA. We could actually mandate to unicast it to all registered nodes.



2.       if the 6LR keeps the registration but stops being a router, then signal is the ‘R’ flag only.



3.       If the 6LR accepts a registration it should keep it as long as it is a router. If -and that’s your case- the 6LR drops the registration but keeps acting for other registration. This is where it would send an EARO (Neighbor Cache full)



 Makes sense?



Pascal









From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav
Sent: mardi 14 avril 2020 14:12
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR



Neighbor Cache full seems the only code that is applicable in this context.



However, can RA carry an EARO? RFC 8505/6775 mentions ARO/EARO only in context to NS/NA.





________________________________

From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>>
Sent: 14 April 2020 07:34 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR



Hello Rahul



I agree, our proxy mechanism doesn’t allow to change the period in run time by the 6LBR. Note that the 6LBR or the Root could send an EDAC back to the 6LR asynchronously. There’ s not much text on that in the existing specs but it’s doable.



The multicast final RA is the normal behavior. Unicasting it is possible and more reliable. That was true already so I agree we do not need to mandate anything new here. It is something that we could have said in RFC 8505, nothing specific to RULs.



For the reason why the 6LR would on its own remove just one BCE, I only see the cache full. What else do you have in mind?



Cheers,



Pascal



From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav
Sent: mardi 14 avril 2020 11:44
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR



Thanks for the detailed response. Please find my response inline.



One key point you mentioned is that EARO parameters are managed by 6LBR. The initial registration happens using EDAR/EDAC through 6LBR and using EDAC(EARO-lifetime) the 6LBR can control the lifetime in the NA(EARO).

But during lifetime refresh, the keepalive NS sends a lifetime and the 6LR replies directly using NA using the same lifetime. Won't this lifetime create problems? Is it expected that the 6LR remembers the lifetime sent from 6LBR and uses it in the subsequent refresh NA(EARO) reply?



To instantiate this point, consider Figure 10 which shows that DAO is created from NS(EARO) and the lifetime of EARO is converted to lifetime in DAO-transit option. This DAO results in anonymous EDAR from Root to 6LBR and a response EDAC. The response EDAC status value is used in the DAO-ACK but the (possibly updated) lifetime from EDAC is dropped.



________________________________

From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>>
Sent: 14 April 2020 04:25 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR



Hello Rahul



For the lifetime I do not necessarily agree with your wording. My reading is that the registration lifetime is requested by the 6LN and granted by the 6LBR. What the 6LBR returns might be less than what the 6LN requested. This might not be very explicit in RFC 6775 but “5.5.2.  Processing a Neighbor Advertisement” says

“

   The host saves the Registration Lifetime from the ARO

   for use to trigger a new NS well before the lifetime expires.

”

Which tells you that the network has the ultimate control, which is good in a managed network.



[RJ] This makes sense to me now.



Then “8.2.3.  6LR Sending a Duplicate Address Request” says

“

      The EUI-64 and Registration Lifetime are copied from the ARO

      received from the host.

”

Which tells you that the 6LR is just an transmission but has no say in the story.



Normally:

- If the 6LR stops being a router at all the signal is a final RA. We could actually mandate to unicast it to all registered nodes.

- If the 6LR accepts a registration it should keep it as long as it is a router so ‘removed’ comes from above.

- if the 6LR keeps the registration but stops being a router, then signal is the ‘R’ flag only.



So we are talking about a unexpected case where the 6LR would drop an NCE on its own but continue being a router, IOW break its contract with the 6LN.



I see the value of using status “Removed” there. The problem I have here is to clarify what comes from the 6LBR which means that the address is not usable at all vs what comes from the 6LR, which means that this 6LR is not useable, but the 6LN can try with another 6LR. I thought the lifetime helped but on second thought it does not. “Removed” and lifetime are both 6LBR decisions.



If that’s a problem with the 6LR only, we need to signal that. RFC 8505 helps us there. Section “5.7.  Maintaining the Registration States” indicates that

“

   space is exhausted.  In that situation, the EARO is returned in an NA

   message with a status code of "Neighbor Cache Full" (Status 2; see

   [RFC6775<https://tools.ietf.org/html/rfc6775>] and Table 1), and the Registering Node may attempt to

   register to another 6LR.



   If the registry in the 6LBR is full, then the 6LBR cannot decide

   whether a registration for a new address is a duplicate.  In that

   case, the 6LBR replies to an EDAR message with an EDAC message that

   carries a new status code indicating "6LBR Registry Saturated"

   (Table 1).  Note: This code is used by 6LBRs instead of "Neighbor

   Cache Full" when responding to a Duplicate Address message exchange

   and is passed on to the Registering Node by the 6LR.  There is no

   point in the node retrying this registration via another 6LR, since

   the problem is network-wide.  The node may abandon that address,

   de-register other addresses first to make room, or keep the address

   "tentative" [RFC4861<https://tools.ietf.org/html/rfc4861>] and retry later.





“



So I’d suggest that we mandate unicast final RA if the router goes away, and if the router just drops that NCE then use "Neighbor Cache Full" in the NA.

Works?



[RJ] So essentially NA(EARO) is strictly controlled by the 6LBR. Using 'Neighbor Cache Full' will tell the 6LN to move to other 6LR, and this should work, even though the status code does represent the appropriate reason.

I understand mandating final RA but why only unicast? Can't a multicast final RA be sent by a 6LR who is about to go down and has several RULs connected via it?



Note: The 6BBR draft uses it for the 6LBR to clean up a state in the old 6BBR when registering to a new 6BBR. As a second thought it appears that ‘moved’ would be better. That’s what 6BBRs do with one another when it’s a different 6LBR. I’ll fix that unless someone raises an issue.



Regards,



Pascal



Le 14 avr. 2020 à 04:05, Rahul Jadhav <nyrahul@outlook.com<mailto:nyrahul@outlook.com>> a écrit :



Please find my response inline.



________________________________

From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>>
Sent: 13 April 2020 11:14 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR



Great point Rahul.



Normally this is done using a final RA. But the RA is broadcast so unicasting a NA with ‘R’ flag off is a great idea. This is the exact signal that this router does not serve this node. Lifetime 0 would indicate that the router removes the NCE.

Status removed indicates an error. I’d rather use status 0, lifetime 0, ‘R’ off. Don’t you think?



[RJ] Imo, Lifetime is something that is controlled by the target/owner. There has never been (?) a case where someone else changes lifetime on behalf of the target node.

RFC 8505 states: "Removed: The binding state was removed.  This Status MAY be placed in an NA(EARO) message that is sent as the rejection of a proxy registration to an IPv6 ND Registrar, or in an asynchronous NA(EARO), at any time."

I still feel using Status="Removed", 'R' off may be applicable more.



Keep safe.



Pascal



Le 13 avr. 2020 à 15:07, Rahul Jadhav <nyrahul@outlook.com<mailto:nyrahul@outlook.com>> a écrit :



Hello Pascal/Authors,



In the event that the attached 6LR needs to gracefully shutdown, it needs to inform the RUL(s) to detach and possibly move to another 6LR.

I believe this could be done using NA(EARO, Status="Removed"); from the attached-6LR. Can this NA be multicasted if the attached-6LR has more than one RULs attached to it?

Is this correct/allowed? For RPL we have route-poisoning using which a 6LR does a graceful shutdown, but the route-poisoning is not applicable to RULs.. I believe this should be clarified in the text.



Regards,

Rahul

_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll