[storm] RDDP Registries Draft: Experimental values & RDMAP opcodes
<david.black@emc.com> Thu, 05 January 2012 21:00 UTC
Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F9821F889D for <storm@ietfa.amsl.com>; Thu, 5 Jan 2012 13:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level:
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYlj-a-DD4uP for <storm@ietfa.amsl.com>; Thu, 5 Jan 2012 13:00:31 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E3D2C21F888F for <storm@ietf.org>; Thu, 5 Jan 2012 13:00:30 -0800 (PST)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q05L0Qjg016586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <storm@ietf.org>; Thu, 5 Jan 2012 16:00:27 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for <storm@ietf.org>; Thu, 5 Jan 2012 16:00:21 -0500
Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q05L0IdC032196 for <storm@ietf.org>; Thu, 5 Jan 2012 16:00:18 -0500
Received: from mx14a.corp.emc.com ([169.254.1.216]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Thu, 5 Jan 2012 16:00:17 -0500
From: david.black@emc.com
To: storm@ietf.org
Importance: high
X-Priority: 1
Date: Thu, 05 Jan 2012 16:00:16 -0500
Thread-Topic: RDDP Registries Draft: Experimental values & RDMAP opcodes
Thread-Index: AczL7QaS6DcqU/89QrWJkKQ28N+CYA==
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5E7C342@MX14A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [storm] RDDP Registries Draft: Experimental values & RDMAP opcodes
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2012 21:00:31 -0000
IESG evaluation of the RDDP registries draft (draft-ietf-storm-rddp-registries-01.txt) has resulted in a need for a new version primarily to address some editorial issues. There is also a suggestion to set aside an experimentation/testing value for RDMAP operation codes (0xF) and SCTP Function Codes for DDP Session Control (0xFFFF). I wanted to make this suggestion visible for WG comment before making this change to the draft. IMHO (WG chair hat off), setting aside an SCTP Function code for DDP Session Control for experimentation and testing seems like a fine idea. OTOH, I'm concerned about overall usage of RDMAP opcodes, and want to discuss how to plan for the future in this space. The current situation is that the RDMAP opcode is a 4-bit field (16 possible codes. RDMAP currently uses 8 opcodes, the RDMAP extension draft proposes to use 4 more for immediate data and atomic operations, so setting aside an experimentation/testing value would use 13 of the 16 available opcodes. I'm a bit concerned that there would only be three opcodes remaining. The questions to the WG are: - Is anyone else concerned? - If so, what should we do about this? I observer that there are 2 unused (reserved) bits adjacent to the MSB of RDMAP opcode field that may provide some opportunity for expansion. An example of what's possible is to plan to rework the RDMAP extensions draft to use only 1 or 2 opcodes (instead of the current 4 opcodes) by putting Request/Response and possibly Atomic/Immediate into those two bits (that'd leave 5 or 6 available opcodes and set the precedent that those 2 bits can be used as an op-sub-code). OTOH, going all the way to expanding the RDMAP opcode field to 6 bits probably involves bumping the RV (RDMA Version) field to 2, which does not seem like a good idea until we actually run out of opcodes, as we'd probably have to design a version negotiation mechanism. Comments? What do other people think? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ----------------------------------------------------