[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
----------------------------------------------------