Re: [Coma] Reprogramming Protocols

Ulrich Herberg <ulrich@herberg.name> Tue, 17 July 2012 16:26 UTC

Return-Path: <ulrich@herberg.name>
X-Original-To: coma@ietfa.amsl.com
Delivered-To: coma@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474E021F86B6 for <coma@ietfa.amsl.com>; Tue, 17 Jul 2012 09:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.236
X-Spam-Level:
X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
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 2CT8Vhmul9xq for <coma@ietfa.amsl.com>; Tue, 17 Jul 2012 09:26:57 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBE321F864B for <coma@ietf.org>; Tue, 17 Jul 2012 09:26:57 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so1092173pbc.31 for <coma@ietf.org>; Tue, 17 Jul 2012 09:27:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nyt1mHw3zICRKn0/afLN2q3jA041XndtLAzHohWGsiQ=; b=ynMeLkL97+XgVtKFYiUmhTV4kCzo8v4sqC7w95Z/CfeMwyvtCVYxq15Ax79wEUiAmT 0PfDO20F3BVZ9FTm+s5y7LPJ5M4nA/Hozt9zLImzK/bztfvSQSPGrQpKijb5rT1vrWNW k1c5cKoYN/WEeIk8acMiEOmM1i6I4dMa/bWZw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nyt1mHw3zICRKn0/afLN2q3jA041XndtLAzHohWGsiQ=; b=KpmcZn94yym6SX6Elc/e0CQyKmOYAJ23iGDwAZuskfYh4lM5WLU3zTC4+Z/scbjCo6 6ebVsS70Ldgsv/Lv1zdJzHhZpUl5nyT3BVv6T/rre5G1dx9Jf+d6wRlmkmhAan+VerWv d+bcO/svtc/m0pVnTJI3QyJTTFdLGt94pBg952ZMKmYbsp8v/f/pCtuat8nMdGtVjIms JH0czU3WyG1DgHMsLZZ/0SxmN9SjxvAJ8kVsgaARkUEhOq4dRjyV5FwQkHT+WPv8g75K ZJD8p6a0s/sLesW3QBQpAXh9v3ryniEsLbbRT39mWvc/jssHJ/FOBW52gDZyMLOuH9ME KMzQ==
MIME-Version: 1.0
Received: by 10.68.200.104 with SMTP id jr8mr208178pbc.9.1342542464751; Tue, 17 Jul 2012 09:27:44 -0700 (PDT)
Received: by 10.66.26.207 with HTTP; Tue, 17 Jul 2012 09:27:44 -0700 (PDT)
In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640405EBA2@DEMUEXC006.nsn-intra.net>
References: <83C941F7F59F3F42AC017AD1E650546206BFB090@GDUKADH850.uk1.r-org.net> <80A0822C5E9A4440A5117C2F4CD36A6403DFB8BD@DEMUEXC006.nsn-intra.net> <E045AECD98228444A58C61C200AE1BD807D3AA4C@xmb-rcd-x01.cisco.com> <80A0822C5E9A4440A5117C2F4CD36A640405EBA2@DEMUEXC006.nsn-intra.net>
Date: Tue, 17 Jul 2012 09:27:44 -0700
Message-ID: <CAK=bVC9biLGjUdsXJGY=6zfCHPP-GD0oL0x1_TgYY3-SWXWXAg@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
Content-Type: multipart/alternative; boundary=047d7b10cff3b5168804c50906f8
X-Gm-Message-State: ALoCoQlXA9P5kCM5DyHXnVTvWEyB0+NOLF3VbWPMUAM2MxomvZPDD/U0XjH7Yxf4jfewZBr+PelR
Cc: Jonathan.Hansford@generaldynamics.uk.com, "ext Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, coma@ietf.org
Subject: Re: [Coma] Reprogramming Protocols
X-BeenThere: coma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Management of Constrained Networks and Devices <coma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/coma>, <mailto:coma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/coma>
List-Post: <mailto:coma@ietf.org>
List-Help: <mailto:coma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/coma>, <mailto:coma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2012 16:26:58 -0000

Hi,

I agree with Mehmet. I don't see how this is related to management of
networks and devices. RPL is a routing protocol, not a network management
protocol.

Best
Ulrich

On Tue, Jul 17, 2012 at 3:09 AM, Ersue, Mehmet (NSN - DE/Munich) <
mehmet.ersue@nsn.com> wrote:

> Dear Pascal,****
>
> ** **
>
> I am wondering whether this has to do with network management. I think we
> should differentiate between the management and operation of the network.*
> ***
>
> ** **
>
> A programmable routing functionality which improves the operational
> behavior might be useful but not in our focus. Coma(n) especially raises
> the questions on and discusses the use cases and requirements for the
> management of networks with constrained devices.****
>
> ** **
>
> I can imagine policy management as a requirement on the management of
> networks with constrained devices. If you think so, please formulate it and
> describe the use case from the application pov. However, I think optimizing
> routing functionality is on another level.****
>
> ** **
>
> Please read also the problem statement in -01 draft which hopefully
> describes the focus of Coma(n):
> http://tools.ietf.org/html/draft-ersue-constrained-mgmt-01 ****
>
> Comments are welcome.****
>
> ** **
>
> Cheers,
> Mehmet ****
>
> ** **
>
> *From:* ext Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> *Sent:* Tuesday, July 17, 2012 8:48 AM
> *To:* Ersue, Mehmet (NSN - DE/Munich);
> Jonathan.Hansford@generaldynamics.uk.com; coma@ietf.org
> *Subject:* RE: [Coma] Reprogramming Protocols****
>
> ** **
>
> Hum… I do not necessarily agree.****
>
> ** **
>
> RPL, which is probably a protocol of choice for such environment, defines
> Objective functions that handle metric interpretation and some logic to tie
> multiple metrics and policies together. ****
>
> I’d think that as long as we stay at the abstract (interface) level we can
> push some hints to an existing OF to twist its behavior, and tell RPL to
> support a new instance based on a new OF that needs to be installed.****
>
> ** **
>
> There is probably a way to define:****
>
> - an abstract interface between RPL and the OF so that we can dynamically
> plug an OF in.****
>
> - abstract behavior specifications on which metric are supported and how
> they are handled (eg additive, weighted, etc) by an existing OF so we can
> tune the graph generation.****
>
> - abstract policies specifications so we can control peering, size, power,
> you name it.****
>
> ** **
>
> What do you think?****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* coma-bounces@ietf.org [mailto:coma-bounces@ietf.org<coma-bounces@ietf.org>]
> *On Behalf Of *Ersue, Mehmet (NSN - DE/Munich)
> *Sent:* vendredi 8 juin 2012 15:02
> *To:* Jonathan.Hansford@generaldynamics.uk.com; coma@ietf.org
> *Subject:* Re: [Coma] Reprogramming Protocols****
>
> ** **
>
> Hi Jonathan,****
>
> ** **
>
> this could be seen under the SW/firmware distribution, however
> reprogramming protocol code is a device specific logic and not a management
> task.****
>
> ** **
>
> Cheers,
> Mehmet ****
>
> ** **
>
> *From:* coma-bounces@ietf.org [mailto:coma-bounces@ietf.org] *On Behalf
> Of *ext Jonathan.Hansford@generaldynamics.uk.com
> *Sent:* Friday, June 08, 2012 2:38 PM
> *To:* coma@ietf.org
> *Subject:* [Coma] Reprogramming Protocols****
>
> ** **
>
> Hi,****
>
> ** **
>
> One thing that hasn’t yet been mentioned (unless I missed it) is the issue
> or reprogramming protocols for adding new applications or
> modifying/patching existing applications/firmware. I imagine this is of
> particular interest in Sensor Nets but may also be beneficial in other
> scenarios. Will this also be considered within coma?****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Jonathan****
>
> ** **
> ------------------------------
>
> This email and any files attached are intended for the addressee and may
> contain information of a confidential nature. If you are not the intended
> recipient, be aware that this email was sent to you in error and you should
> not disclose, distribute, print, copy or make other use of this email or
> its attachments. Such actions, in fact, may be unlawful. In compliance with
> the various Regulations and Acts, General Dynamics United Kingdom Limited
> reserves the right to monitor (and examine for viruses) all emails and
> email attachments, both inbound and outbound. Email communications and
> their attachments may not be secure or error- or virus-free and the company
> does not accept liability or responsibility for such matters or the
> consequences thereof. General Dynamics United Kingdom Limited, Registered
> Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and
> Wales No: 1911653. ****
>
> _______________________________________________
> Coma mailing list
> Coma@ietf.org
> https://www.ietf.org/mailman/listinfo/coma
>
>