Re: [Roll] WGLC on draft-ietf-roll-unaware-leaves-13

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 09 April 2020 16:45 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 A230B3A0C4E for <roll@ietfa.amsl.com>; Thu, 9 Apr 2020 09:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=VxgaI9cN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nUup38F+
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 BDupZ9KNk-Zk for <roll@ietfa.amsl.com>; Thu, 9 Apr 2020 09:45:56 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFD23A0C4C for <roll@ietf.org>; Thu, 9 Apr 2020 09:45:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7924; q=dns/txt; s=iport; t=1586450755; x=1587660355; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=J1bCCnf2uf3DvKBYdjBDPs7FpcPPtcBJutvg7DwMKYc=; b=VxgaI9cNifXt5mFvTSzMX1RfrzVP1Rtp/EB+iolfdVWLIDBJ2BPMlAOG 2nZjMA6tiI5GdQvFU2YVphegtY6RVOUYXnxvgsRd9IkH5fiOZo93mj6Xr C+2zgoZpVRwFOa48Wof2k7jCUM/oROEWswrJpebKQInQp10IEeza6cgq1 o=;
IronPort-PHdr: =?us-ascii?q?9a23=3AKaqtjBx048YAydzXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLFwDbUI9e/5tdJa1mHQEBOAUFAQI?= =?us-ascii?q?JAYFVgVJQBYFEIAQLKgqEEoNGA4ptToIRgQGXH4FCgRADVAoBAQEMAQEtAgQ?= =?us-ascii?q?BAYREAheBeCQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFcAEBAQECARIRBA0MAQE?= =?us-ascii?q?4BAsCAQgaAiYCAgIwFRACBBsahVADDiABA6VmAoE5iGJ1fzOCfwEBBYVDGII?= =?us-ascii?q?OCYEOKgGMMhqBQT+BEUOCGDU+hDQBG4MQMoIsjXsUgwCQSI9rCoI/l1mCUJR?= =?us-ascii?q?shFqRGZZhhAMCBAIEBQIOAQEFgWkigVdwFYMkUBgNgUWPaReDUIpVdIEpi1w?= =?us-ascii?q?tgQYBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.72,363,1580774400"; d="scan'208";a="736988911"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2020 16:45:54 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 039Gjs4w026728 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Thu, 9 Apr 2020 16:45:54 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 9 Apr 2020 11:45:54 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 9 Apr 2020 11:45:53 -0500
Received: from NAM12-MW2-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; Thu, 9 Apr 2020 11:45:53 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e0nrT3il70Isu1N5XmdsPbAQdkP1JBE2q604kKgLftUELpZYomV27OvSmFp8xKJkYTxVFeDKeftJT3kNZbxXIOAp1O/Nnm00mX3f5Dh61yk59zEP8OiN8v3xbEd+hGFPYjK1E7RXSqTVhHR5INLbU53u1ezh84N4nqNRa3j9K3gMcaXVBUp9Go5F7eej1c2Wy+RjEYjD7nHaUy88eDxLhp7z6W5UHXYQ9oWDRnyreVS/AB9fX2ebTFyriw07dOdobms9/XdapQ2n0yg9KYO/whLMS5XXTjjkMwF8zPmRTMFLhTM0df3HoDWXJbLhDdEDaPWDXS/sxh2Wu8it/0Ud5Q==
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=J1bCCnf2uf3DvKBYdjBDPs7FpcPPtcBJutvg7DwMKYc=; b=G7BXPoLPOvR4RCXkNn0/PgBWP3E0EXw0AEiiuOAejVvUer39S1E1umml1dtRbsM9pORpRZnVsKGkaIIPERFWbBLPgaVc88QmwxU2euTfOrU3mxMxItvj8JUvSbw7UmYNPmdLkIYz4P9Z/ea+E16e1EKkTaX9Q6CjwtRg/FKSsQe/efP43Nd100IINqnBNSAglDqIEomQsA1EJ9TzKaN9xn3xMjS0w9JPbG3VdX8j4aUxUwEsSblzfvu+atc5PxztqyL0jekqfX1Bdb+zV0/jpHSSoKpDCqSIg0HuoCYyxfrjY3e8gWhsOhGeGbfXvyJRJamrE2Q7FUnxx+Kjfnmxfg==
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=J1bCCnf2uf3DvKBYdjBDPs7FpcPPtcBJutvg7DwMKYc=; b=nUup38F+Pem32m0Upj5+gJzg0UddDQT6fYxALltXgXRYgx0/p+zXEAeAS9SLqSiHnS0i4ItzFoz5Tr0cNORO4D2Viz4jX5ZvAbk10I1SvCJdJqRaqFahW4XX1k1a2ESEBUbuHDiwldMig2xkI98xt04MfswS12iFu+NK2JA+rWY=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3712.namprd11.prod.outlook.com (2603:10b6:208:f6::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.17; Thu, 9 Apr 2020 16:45:52 +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.2878.018; Thu, 9 Apr 2020 16:45:52 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] WGLC on draft-ietf-roll-unaware-leaves-13
Thread-Index: AQHV/Ro9AOfHATbWbk+HyMb2raYz4qhtjAx3gAFYroCAAglh4A==
Date: Thu, 9 Apr 2020 16:44:23 +0000
Deferred-Delivery: Thu, 9 Apr 2020 16:44:11 +0000
Message-ID: <MN2PR11MB35650537494AB9FB8E0849D1D8C10@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CAP+sJUe7oF74F96zi5RuE985CD9LzNfwad=Zzstc8uat2wc3aQ@mail.gmail.com> <25495_1585151124_5E7B7C94_25495_267_1_DAA13A41.7291B%dominique.barthel@orange.com> <CAP+sJUchX+q_cX4_fOytz+q5RfjN+L51VM-+Auz4jVxK-6wpOA@mail.gmail.com> <CAO0Djp1QGASEu4fasZD6K6CSD0q-7F+CD0_JOOppWnnABdbo5w@mail.gmail.com>
In-Reply-To: <CAO0Djp1QGASEu4fasZD6K6CSD0q-7F+CD0_JOOppWnnABdbo5w@mail.gmail.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: [90.118.154.148]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e69143a1-7099-4757-bccb-08d7dca57779
x-ms-traffictypediagnostic: MN2PR11MB3712:
x-microsoft-antispam-prvs: <MN2PR11MB3712AEA3F096F8924C664DEFD8C10@MN2PR11MB3712.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0368E78B5B
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)(136003)(396003)(376002)(366004)(346002)(39860400002)(478600001)(6916009)(71200400001)(6666004)(7696005)(2906002)(186003)(26005)(86362001)(316002)(6506007)(33656002)(52536014)(64756008)(66556008)(66946007)(8936002)(66476007)(5660300002)(55016002)(66446008)(9686003)(8676002)(76116006)(81156014)(81166007); 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: /l9iXCLOJ5fFn3wcz/Qvz4lbDAZAu2EgN/eHB92VB/BfW1RNCKST3Tpa3FropmH6peg9eBmSEp1CChwMTg/O7XpEoILymxdgmmWwaAqEDbKarqJaQBCJanuff6CDBUS95m0wQCTgIK0o5mYpIqYf84Mv1bHZwc5O1FVzXor9VW/W0VOyk9MtvG+OcegwjKovQwtM22wITRqndqMwz1kGhoj1VmnA/tGYZuF6/NKE5zayxway+WQ9gsugAGAuzXAznUL2iRpcYg6X2qSwJS5ETfN8o+3xtkiu1wV9+FPa8GkVD58t6UICR5QYe9M7mSu51wJieVC5SkUTeckvZrr87I0YlJqNrjxAlG53b6WKsTmXbsRCQIs4AxalN914hqJ1/aItxo9uMPZbCz0OxPLQ7o7DlPHc7e/h8JKwirF1iCvZSQNU/OmYxej0VIhUj+pD
x-ms-exchange-antispam-messagedata: UTwTel4vWuDs3b2FXrsTDIaGc+2bn4FEwH8AuxPVQrUlmGCWrTfpmVEHyvmAy3DV1fOZj5XguAz+0mPX7WG7iWGdY2utrbYHRI9gO3mUoxaboiTcKIKk8sg0E3RWxhLts5uU04ggS/UQffa5EC7Zhw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e69143a1-7099-4757-bccb-08d7dca57779
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 16:45:52.6607 (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: sPmBZ91XHqI89Up2B49GazwkibcNSCR6VDElSSfPL5w8sHjCHgMdtFP6fV85hjZmVWr4/HZA0+6EwOlbevkCrQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3712
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/wTa6RczCnjJui3yysrXLShr0sqo>
Subject: Re: [Roll] WGLC on draft-ietf-roll-unaware-leaves-13
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: Thu, 09 Apr 2020 16:45:58 -0000

Many thanks Rahul!

I hope all is going right for you and your family; 

Let's see below, I need more precisions from you:

> 1. The draft requires that the first registration (EDAR/EDAC) is directly
> handshaked with the 6LBR but all the subsequent refreshes using DAO/DAO-
> ACK goes through the Root which in turn generates anonymous EDAR/EDAC
> handshaked with the 6LBR.
> **Can't we have the 6LR simply use DAO always to Root which generates the
> EDAR(with ROVR)/EDAC to 6LBR?** This would simplify the handling of 6LR.

Here is why: The 6LR does the traditional DAD and ensures that the address is not a duplicate before it injects it in RPL. 

On paper DAD is really a special operation that allows the address in the network. Using the address before DAD is against IPv6 and prone to attacks. 


E.g., if we skip that step, and RPL is not aware of the new ROVR field, then in storing mode the duplicate will take over the path as the DAO progresses upwards, and that's not desirable security-wise. When the Root comes back with a NPDAO, it's too late. At the moment, we do not change RPL to process the ROVR. Hopefully in the future we'll do more.

Arguably in non-storing we could do it because the flow is nested and the root can check with the 6LBR before it updates its state. That would be an even deeper integration of RPL and ND. Is that more useful than dangerous?

> With the updated target option it is now possible to send ROVR in target
> option in a backward-compatible fashion. The root is anyways handling the
> anonymous EDAR/EDAC and thus has all the required handling needed to
> proxy non-anonymous EDAR/EDAC. Also, the de-registration is also handled
> through Root which means Root also has to proxy non-anonymous
> EDAR/EDAC in that case? The de-registration case is not clarified in the Figures
> 7,8,9.

You're right we should add text on the deactivation of the state.

If the root cannot do non-anonymous then the state will stay as is in the 6LBR if an anonymous EDAR comes in with lifetime 0. The idea is really to add the ROVR to the DAO.

I will:
1) add figures for flows with lifetime=0
2) add text in the 6LBR section that indicates that a lifetime 0 is ignored in an anonymous EDAR. This is implicit already
" 
  an anonymous message can only increase the lifetime and/or increment the TID of an existing state at the 6LBR.
"
3) There is no mandate for using the ROVR in the target option. It is a SHOULD, should it be a MUST?


> 
> 2. The document introduces the term RAN for any RPL aware node which can
> act as a parent node for the RUL. But in the document, subsequently, the term
> 6LR is used to depict the parent node with which the RUL attaches. Wondering
> why? Isn't RAN the appropriate term to be used?
> 

This is by reference to RFC 8505, to echo what happens there. Wouldn't the use of RAN blur things?


> 3. Section 9.2.2: "If a 6LR receives a valid NS(EARO) message with the "R" flag
> reset and a Registration Lifetime that is not 0, and the 6LR was redistributing
> the Registered Address due to previous NS(EARO) messages with the flag set,
> then it MUST stop injecting the address."
> In this case, should the 6LR also evict the corresponding NCE?

The NCE does not depend on the "R" flag. The flag controls the redistribution into RPL only.

> 
> 4. Section 9.2.3: "the Registration Lifetime is adapted from the Path Lifetime
> in the TIO by converting the Lifetime Units used in RPL into units of 60
> seconds used in the 6LoWPAN ND messages;"
> The unit of lifetime for RPL is not a multiple of 60sec like that of 6lo ND. Thus
> it is possible that absolute conversion is not possible in some cases. I guess
> the implementation should round-up in this case?

Yes, I can add "rounded up to the upper value". Is that OK?


> 
> 5. Section 5 ... "anonymous message can only increase the lifetime"
> ... It should be "anonymous message can only update the lifetime"

I really meant that in terms of configuration, it can only increase the duration of the lifetime parameter but not reduce it, e.g., to 0. A lifetime value of less than the current value will trigger a restart of the current value.

That behavior on an anonymous can really be discussed. Think that anyone could send it, what change can we allow it to cause?

> 
> 6. Section 9.1 ... "On the first Address Registration, illustrated in Figure 5 and
> Figure 8" ... Figure 8 currently does not show first address registration.
> 

Oups fig 8 it was repurposed, because it was too obvious. Fixed in github. The paragraph becomes

"
   On the first Address Registration, illustrated in Figure 5 for RPL
   Non-Storing Mode, the Extended Duplicate Address exchange takes place
   as prescribed by [RFC8505].  Any combination of the logical functions
   of 6LR, Root and 6LBR might be collapsed in a single node.
"
> 7. Nits:
> Sec 9.2.2 "that is sends in response" -> "that is sent in response"
Actually I meant "it sends" : )

> Sec 10: "unicast to each if the interested children" -> "unicast to each of the
> interested children"


> Sec 10: "Layer-2 acknoledgement" -> "Layer-2 acknowledgement"   

> Sec 11: " whereby the it is possible to validate" ->  "whereby it is possible to
> validate"
> Sec 12.4: "DAO-ACK and RCO" -> "DAO-ACK and DCO"

> Appendix A: " Follows the RPI-6LoRH and then the IP-in-IP 6LoRH." -> Need to
> be rephrased

Wasn't that high poetry? Changed to

   The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH.
   When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that
   precede it are also removed.

Many thanks again Rahul, waiting for your advice on the issues raised.

Be safe

Pascal