Re: [6lowapp] Architecture Sketch in Charter

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Sun, 01 November 2009 08:51 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8E93A683E for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 01:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level:
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aspYON2t6ypz for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 01:51:21 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 794003A683A for <6lowapp@ietf.org>; Sun, 1 Nov 2009 01:51:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,661,1249272000"; d="scan'208";a="188791785"
Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Nov 2009 03:51:39 -0500
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Nov 2009 03:51:38 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 1 Nov 2009 09:50:54 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401B86A57@307622ANEX5.global.avaya.com>
In-Reply-To: <D53A5549-FE08-460B-91D9-673DB9C81720@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [6lowapp] Architecture Sketch in Charter
Thread-Index: AcpaUXtuZ4UwOgsCQDaetxlZcNN6twAfRjoA
References: <D53A5549-FE08-460B-91D9-673DB9C81720@cisco.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Cullen Jennings" <fluffy@cisco.com>, <6lowapp@ietf.org>
Subject: Re: [6lowapp] Architecture Sketch in Charter
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Nov 2009 08:51:22 -0000

 

> -----Original Message-----
> From: 6lowapp-bounces@ietf.org 
> [mailto:6lowapp-bounces@ietf.org] On Behalf Of Cullen Jennings

> 
> 4) The OAM folks must be thinking, so how is this different 
> from what we do every single day?
> 

I prefer the term 'OPS folks' :-) OAM is just one of the tools in our
kit. 

This is not completely new stuff for OPS. Actually we have already seen
similar work done in other SDOs for various 'low-xxx' devices attached
to networks. The typical challenges are the low resources on the device,
the mapping and sometimes optimization of protocols on specific
transports and the security model which usually offers less at the lower
level than management or OAM protocols are used to. Solutions exist and
they are not rocket science, but it is important to think about the
operational model and about the way the network will be managed from the
start. When operational and manageability aspects are left for a later
stage there is always the risk that the management solution will be to
expensive to implement and deploy, and this will impact interoperability
and scalability of the overall technology. From this point of view I am
concerned to see the item 'Mar 2012 - Ops & Management advice to IESG as
Info' showing up almost two years later than the architecture
requirements in the charter proposal. I think this item should be
synchronized or come just a short delay after the core protocol
requirements in the proposed WG scheduled.