[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!
- [6lo] Gen-ART Early review of draft-ietf-6lo-path… Paul Kyzivat
- Re: [6lo] Gen-ART Early review of draft-ietf-6lo-… Luigi IANNONE
- Re: [6lo] Gen-ART Early review of draft-ietf-6lo-… Luigi IANNONE
- [6lo] Re: Gen-ART Early review of draft-ietf-6lo-… Paul Kyzivat
- [6lo] Re: Gen-ART Early review of draft-ietf-6lo-… Luigi IANNONE
- [6lo] Re: Gen-ART Early review of draft-ietf-6lo-… Carles Gomez Montenegro