Re: [smartpowerdir] SmartGrid Status Update Please

Fred Baker <fred@cisco.com> Thu, 05 May 2011 17:31 UTC

Return-Path: <fred@cisco.com>
X-Original-To: smartpowerdir@ietfa.amsl.com
Delivered-To: smartpowerdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B07E08F4; Thu, 5 May 2011 10:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.569
X-Spam-Level:
X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMORwAKhqfka; Thu, 5 May 2011 10:31:44 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id CAC93E08F1; Thu, 5 May 2011 10:31:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3559; q=dns/txt; s=iport; t=1304616704; x=1305826304; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=e/9IZfL7D37AJaJRTvywXVnZjY6vx2bJZVLiUehLvJc=; b=gNJEzgBZH3/TabNKGkYMtOKkt1JTzl+pBXTD9P6YwQMPHUQtVLthBFOe 3o6z+IRucGAfBAGmqZC4iQGTBqKrR/zQcV26hyrSqfiBNo7C+MOLmWA8V 6PUsmlxCR2rHjYmr8Ri/AjVVuraaawVz/D+DHuxfiAsnTj2Jhcz8mPM99 4=;
X-IronPort-AV: E=Sophos;i="4.64,321,1301875200"; d="scan'208";a="351169263"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 05 May 2011 17:31:43 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p45HVb1V012895; Thu, 5 May 2011 17:31:42 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Thu, 05 May 2011 10:31:43 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Thu, 05 May 2011 10:31:43 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <4DC232ED.90106@piuha.net>
Date: Thu, 05 May 2011 10:31:25 -0700
Message-Id: <712A9779-5B09-4B95-B67E-E4DD4A47159A@cisco.com>
References: <AB464FFF-134F-4EA3-A59A-23E2FBC14705@vigilsec.com> <53A33168-135E-4114-9EEE-D4E17F847FB2@cisco.com> <4DC232ED.90106@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: IETF SmartPower Directorate <smartpowerdir@ietf.org>, IESG IESG <iesg@ietf.org>
Subject: Re: [smartpowerdir] SmartGrid Status Update Please
X-BeenThere: smartpowerdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Members of the Smart Power Directorate <smartpowerdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartpowerdir>
List-Post: <mailto:smartpowerdir@ietf.org>
List-Help: <mailto:smartpowerdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 May 2011 17:31:44 -0000

On May 4, 2011, at 10:17 PM, Jari Arkko wrote:

> This is helpful, but I would also be interested in the other direction. That is, what is SGIP doing (have they gone for IP? IPv6? What are they focusing on now? What are their primary unfulfilled requirements?)

The SGIP is in the process of describing the standards that are important in the grid. Part of that means "today" and part means "tomorrow".

They have generally gone for IP, and for IPv6. Sliding IPv6 in wherever IPv4 is in use now means updating a broad array of existing standards, mostly from the IEC. I personally don't plan to do that; help from any interested quarter would be appreciated.

The SGIP, however, also feels that the ANSI C12 series of standards has present commercial importance. There are a number of issues with that, not the least of which is that US NIST has not certified the security profile for use in communication with the US government; any nuclear facility has to talk with Department of Energy, and there are important ties to Department of Commerce and other areas. From my perspective, the biggest worry is that ANSI C12.19 (a MIB by any other name, but one in which three tables have to be read and understood before one can interpret the remainder; for example, the choice of big-endian, little-endian, or BCD representation is a per-meter option) is hopelessly complex and doesn't quite interoperate with IEC TC 57's CIM. I am also disturbed by it being an OSI ACES/ROSE application layer network that uses UDP/IPv[46] or TCP/IPv[46] as one of a number of underlying networking options.

Another huge issue is embedded in Zigbee. Various factions, including important vendors, the UK, and the Texas Public Utility Commission, have adopted and started to deploy Zigbee Secure Energy Profile (SEP) 1, which presumes a link layer network and an application layer gateway at the Energy Services Interface (ESI). SEP 1 is essentially proprietary; different implementations don't necessarily talk with each other, security has been handed to Certicom with attendant commercial issues, and there are other problems. SEP 2 is an IPv6 network using 6lowpan and RPL, with yet-another-CIM that kinda-sorta interoperates with ANSI C12 or IEC TC 57's CIM, but not quite, and which uses draft-mcgrew-tls-aes-ccm-ecc to bypass Certicom. SEP 2 is nominally link layer independent, which means that it could run over a variety of technologies: IEEE 802.15.1 Bluetooth, IEEE 802.15.4, 802.15.4g, IEEE 1901 Homeplug, ITU G.9955/G.9956 Powerline Communications, and hybrid networks that route between 802.3, 802.11, and the others. However, Zigbee remains wedded strongly to IEEE 802.15.4, so rumor has it (and yes, it's just rumor) that the WiFi Alliance and the Homeplug consortium are having internal discussions about possibly adapting and changing SEP 2 independently to use their link layers. I don't know what the implications would be if that happened, but if I were the AD over the relevant IETF work groups I would want to understand the implications for 6lowpan, RPL, and COAP. Speaking strictly for myself, with the exception of Bluetooth (which probably becomes a local interface to an application) I would prefer to see those simply become IPv6 networks, as most of them can handle a 1500+ byte frame. That story - if it's anything more than a rumor, which at this point I don't know - remains to be told.