[6lo] Gen-ART Early review of draft-ietf-6lo-path-aware-semantic-addressing-05

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 29 April 2024 23:06 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 A3A2BC151548; Mon, 29 Apr 2024 16:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.651
X-Spam-Level:
X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bwG7KBtvpvB; Mon, 29 Apr 2024 16:06:03 -0700 (PDT)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2095.outbound.protection.outlook.com [40.107.236.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C458DC151087; Mon, 29 Apr 2024 16:05:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NC6cx65jGIsP+wCxVzcxKKkawOMSYUyXjp0+/wHsVtCcZ1MFfqC98ttQyJt4aUgLaD48jhXHceOOagnKP/bxUJ+89OMKW2/vI1t2+0THs5P0qPSOA6LPhiN9SdBNmQWemSQZ8Yt2QMpUc6Z26MDtI1BFvxtfhc4jL1cS3gjcUE3KaWazz6KnN62X8Rd0HaFxohrKJSgpMl1DnRn53z942fYmHAQRrrwUnMwVQy6WNZA9ei8SiG+m0YkCKwS6F64UhZvJUlMZ+Mh9UkPcRjBm+7X56ILWcAJn25FkVGfiIyABsKE7Roy7WgwGBwFjazRSVQofdqwQjh2hXWM3xCXFhg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=v3TCEVs8WJgUjafieDYE0knc16lLgT0mkw6QxsnbZxw=; b=bTMDO+XrqxXEFtF+3ecnuffdTdcEsRfY05UfVlEi0F5gj/or9X04CU1HKmC0CegUQ1EKdBZn1uhHuE/Z3VMZh8A5fKYiKbwAi8WW2lBaY+NmCzZuUmhTZ/rMrRnwjESlfUsrE9HqHW9l0DDJkolOrui+g+dMTB/x6K8cJUL9ywo+DsnFdrdbieOxtS0K8aXGDn1YZN4Ee98qEuFkIPZKEa6zXqh7zrF9tqRxLjNzKkwX3G1grQo/asSIpy2bH2yNb1nirSa7KbTriTzceir4Ojwxwl/P55HxWLkI7jG5ik3TyEFCS4bRe6WTuANmK1iN35qt1sWeaHpBIXNQGc08MA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=pass (p=none sp=none pct=100) action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v3TCEVs8WJgUjafieDYE0knc16lLgT0mkw6QxsnbZxw=; b=gqL6RBXPRfagarCRGi2RMb6qhQahr0B1npbHedikqlAazFLXe3osTMp/jsM8id7sXmdo7cPmFb4slE0QZunUAyJqmjk0TY9MGSQfVE9ft4CQHdebggN+YugeLKQhlWXuS/K3hzjQqAJTZ4Cj1e3tyOxRBzfXAGvQ5DbqLG8eklc=
Received: from MN2PR16CA0036.namprd16.prod.outlook.com (2603:10b6:208:134::49) by SJ0PR12MB6878.namprd12.prod.outlook.com (2603:10b6:a03:483::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7519.34; Mon, 29 Apr 2024 23:05:56 +0000
Received: from BL6PEPF0001AB4D.namprd04.prod.outlook.com (2603:10b6:208:134:cafe::61) by MN2PR16CA0036.outlook.office365.com (2603:10b6:208:134::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7519.34 via Frontend Transport; Mon, 29 Apr 2024 23:05:56 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; pr=C
Received: from outgoing-alum.mit.edu (18.7.68.33) by BL6PEPF0001AB4D.mail.protection.outlook.com (10.167.242.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.18 via Frontend Transport; Mon, 29 Apr 2024 23:05:56 +0000
Received: from [192.168.1.52] (c-73-143-251-114.hsd1.ma.comcast.net [73.143.251.114]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 43TN5sxb020135 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 29 Apr 2024 19:05:55 -0400
Message-ID: <83cef4a3-9260-4b89-aa6a-c4352e0d010a@alum.mit.edu>
Date: Mon, 29 Apr 2024 19:05:54 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: draft-ietf-6lo-path-aware-semantic-addressing.all@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>, 6lo@ietf.org
Content-Language: en-US
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB4D:EE_|SJ0PR12MB6878:EE_
X-MS-Office365-Filtering-Correlation-Id: aa078b0a-8d61-4132-4a4b-08dc68a0ed45
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0; ARA:13230031|36860700004|41320700004|1800799015|376005|82310400014;
X-Microsoft-Antispam-Message-Info: Rar3xwAsPdfzqPS+jkvbg6Y5ptpLxhKTfUKEh/4nUR4lTOwjN08oAfgVWbrvOkoBdBycjFA/FYilwPF04msc+O0VGyK5OAcbpkjNpacZofq73dTGadTLmnnn7WjCtAotvIYBrN5I7DfBRqEkmacu+SHF5WhKrDegs3wZtaW0DAWMDklhMB7gQZsKcy6PCSZzPUuqeWiSjWFXixDABiX6PRrCn0eyYzCl/W845rhTNuBtiwvt3MfAaSQi3vH5fFdYyPylxiFd95G/R1are0aXFOgUqWVoggiAa++vXRRWVE0d50k3052cbZCdUOTzs/1DvV7hg8jMw2ouTl+wltxRQKwPHAFK5nms+76vjJ2+zrnYpIWteHX8jytp5vakwkrVmmpRd+1ydrmGi5kKjZuPBlPglDDPkhnCfHPB4J369OumYWyQgePvKgSFzCOQAJgJS2eSc6+yzy5mHwwOhLIF9w1cPjQHLGoMhT7WwiQoez5Vfl9NGGMuu/gD01DbVeQN8QcipmQpBPW8G0RYHpuKfE1yfg8j6VJ6fVIb559aHaffJwAmbyHEksoH+uL0EhiTh0xMePSl9PBVUfXXHXWDI5vLx40ime58fGeDu+mihyuf5HeAqkeeVZAb6ohI8kYWgwgPsYYNmBbZ440ZhyNLdZr733BzLukRFHPsqGcrOgS0mFVBXRGPFQKgl5PXWXCCQh+v6ZdryEXmNR2ADFkOBdDp1hyaUng/w1axDfcQlf8tggR3UKJ9HqWQmdg2tbTIxMpv/dXLNwzcCmHym+fpQWv6hzIeZFfBD5jI59XURcz4xhuBIqc0wDbCHOx4uFKXwGOSGyhrpdAtGNt9NKPKq1Evl5Icbo/DzP+tf0MTlE6yOzybipaoxi4akEDbySB+jtIWWs2gpeQQJZcikuVlVYVFbXwH+XaVeZtG0zjL9yZ60yE3+vD1jdjE77OvL8YJrKKg0W5fmGwz+CdbuJdS0EfF37vl+m3ZbkBUuZY2XDWuvvqAAdOR2yBhEtz4xoamGWwCGkOES1cx65c4aUhVOCoM8x2S+27AILwxl6EFe445tFOqzYkNejIGcIMGwEKuHLsKzI9IR4MGhumhKEK/6vIEdTexm7m3WRzlopqNqrhinXwOSILwTAARztHKOiA6zlsYJXfGn9sblBbtdo3lOWnNs//2Ne1o9y5zkC9ABFj8l+cEsuP1GCkWbpWBhNHf/jhSTh4t4wZuVJmVgaXA0sYFJGZPf1CUa00bfFDJAb/B+ffEhrpegt/jQXjzs0TdKoKlYlvfzDvuzsy10NPSgeLz616aISgIxyqgPQOiNL5zZiRNDBTf7ROrxMd/K8xAXJMi+Q+bIxn0ppSA5JEfkAVduoK2cN58olhvpl0XcEdC1eZIg86q6MJCrTwmqJ9q
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(13230031)(36860700004)(41320700004)(1800799015)(376005)(82310400014); DIR:OUT; SFP:1102;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2024 23:05:56.3002 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: aa078b0a-8d61-4132-4a4b-08dc68a0ed45
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: BL6PEPF0001AB4D.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6878
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/gWJBIcf2uTgTMWy05TkkyTuY150>
Subject: [6lo] Gen-ART Early review of draft-ietf-6lo-path-aware-semantic-addressing-05
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 29 Apr 2024 23:06:05 -0000

I am the assigned Gen-ART reviewer for this draft.
For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-6lo-path-aware-semantic-addressing-05
Reviewer: Paul Kyzivat
Review Date: 2024-04-29
IETF LC End Date: TBD
IESG Telechat date: TBD

Summary:

This draft is on the right track but has open issues, described in the 
review.

This review was challenging for me because I know nothing of the subject 
area or any of the important references. I apologize for any stupid 
comments based on my lack of context.

Below I have not attempted to classify the severity of issues other than 
Nits vs. Issues.

ISSUES:

1) ISSUE: Router parents

In section 3 (Definition of Terms), in PASA Router:

Doesn't the router, like the host, request an address from its parent? 
If so then it should be stated.

In PASA Host:

s/to its selected parent/from its selected parent/ ???

2) ISSUE: Working of OT network domains

In section 4.4 Industrial Operational Technology Networks, regarding 
"The OT network is represented as PASA domain", I think you mean "The OT 
network is represented as *a* PASA domain".

In this domain do each of the sensors/actuators have an assigned PASA 
address so that the IPv6 nodes can address them directly?

IOW, does the PLC act as a PASA Router by assigning PASA addresses for 
each of the sensors/actuators? (Even though they don't carry out the 
steps for PASA Hosts.) It would be helpful for the document to be 
clearer about this.

3) ISSUE: Multiple Root Nodes

In section 5 (Architectural Overview) the description of PASA Root says 
"There is typically one root node in the PASA network". Using 
"typically" implies there may be exceptions where there are multiple 
root nodes. But I have the impression that this spec won't work right if 
there is more than one. Do you really want to define that?

4) ISSUE: Address Assignment

I have concerns about address assignment as described in section 5 
(Architectural Overview):

               ...  Each node acquiring a PASA address firstly needs to
    select a parent node by choosing among the nodes that replied with a
    Router Advertisement (RA) after an initial Router Solicitation (RS).
    A "first come first served" selection policy is sufficient.  Then it
    asks for a PASA address.  In its reply the parent will propose an
    address according to the node's role, which is indicated in the D-bit
    of the GAAO message (see Section 10).  The proposed address is
    algorithmically calculated using the PASA Address Assignment Function
    (AAF).

Is this algorithm stable if there are multiple replies to the RS 
message? IOW, will the same address be assigned regardless of the router 
chosen. This goes back to my question if you want to allow redundant 
routers.

5) ISSUE: Root Node Address

Figure 6 starts out with:
                             root           +--------------------------+
                                  1         | append more bits to form |
                                  O ----+   | brother's address        |

Subsequent discussion says the root address is "1". So why is the "0" 
present?

However the AAF algorithm always assigns addresses ending in "0" to 
routers. Wouldn't it be more consistent to give the root the address 
"0"? (Or does the address packing/unpacking described in section 7 
require the root address to begin with a "1" bit?)

6) ISSUE: Tree Address Assignment Function

In section 6.1 (Tree Address Assignment Function) the function is 
defined as "AAF(role, r, h)" but all the following examples show it as 
A(...). Please be consistent.

Also I don't understand *when* the AAF function is run for a particular 
node. It is when a particular node seeks its parent and then asks for an 
address, but does it every time it restarts? That doesn't seem 
deterministic. What if nodes start or restart at indeterminant times? I 
suspect you are making some assumptions that aren't stated. Please clarify.

7) ISSUE: Packet forwarding

In section 7.1 all the steps reduce to either "send to parent" or send 
to a particular child. How? I presume this requires a MAC address, but 
there has been no mention of these. It seems to require all nodes to 
keep a MAC address of their parent and routers to keep a MAC for each 
child with an assigned PASA address. This state hasn't been discussed.

8) ISSUE: PASA address padding

In section 8.2 (PASA-6LoRH Format) you say "PASA addresses are aligned 
on the least significant bits." But your example AAF assigns variable 
length addresses that are left aligned. I think these can only be 
reconciled by requiring the root node address to begin with a "1" bit 
and then left aligning to the first "1" bit when unpadding. One way or 
another you need to have a way to determine the bit length of the AAF 
address when unpadding.

9) ISSUE: Node role indication

In section 9 (Nodes role indication) you say "Nodes not setting both B 
and L bits are considered PASA Nodes." But I think you mean "Nodes with 
neither the B nor L bit set are considered PASA Nodes."

10) ISSUE: IANA registration

In section 11.2 (PASA Address Assignment Function) I couldn't find the 
IANA "Generic Address Assignment Option Parameters" registry. Do you 
intend to have it created? If so you need to request that.

11) ISSUE: Reliability Consideration

In section 12 (Reliability Considerations) as I mentioned above, I'm 
concerned that simple variability in the order that nodes start up may 
result in inconsistent address assignment. Hopefully I'm wrong about 
this. Can you explain this to me?

NITS:

In section 1 (Introduction), in "This document introduces a 
topology-based addressing mechanism with that allows".

s/with that/that/

In Figure 5, There is an extra space after "PASA Domain" that messes up 
the line art.

Section 7.1 (Forwarding toward a local PASA endpoint) starts with 
"Inner-domain packets carry ...". From context I conclude you mean 
"Intra-domain packets carry ..."

In section 7.2 (Forwarding toward an external IPv6 address), in "When 
the network forwarding operation are based on [RFC8138]",

s/operation are based/operation is based/
or
s/operation are based/operations are based/

In section 10 (PASA Address Configuration Procedure), in "The requester 
MUST indicate its role as indicated in {SEC:role}", what is 
"{SEC:role}"? I don't find any other mention of it. Is it intended to be 
an internal cross reference?

In section 13 (Security Considerations),

s/rouge/rogue/

In section 14 (Privacy Considerations),

s/buildbased/build based/
s/avoid expose/avoid exposing/

That's all!