Re: [Roll] [6tsch] draft agenda for call on April 12

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 12 April 2013 16:58 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5116D21F8640; Fri, 12 Apr 2013 09:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 pbUwZxwU42ed; Fri, 12 Apr 2013 09:58:14 -0700 (PDT)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 58D4A21F8617; Fri, 12 Apr 2013 09:58:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 781222016E; Fri, 12 Apr 2013 13:07:59 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 016EC638F7; Fri, 12 Apr 2013 12:57:51 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E3B75638E8; Fri, 12 Apr 2013 12:57:51 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
In-Reply-To: <CADJ9OA-oSa50iRyoxEXmrQXR1+zvqNbgd1ZvbqTVg6DvLeoOZQ@mail.gmail.com>
References: <E045AECD98228444A58C61C200AE1BD835D34A06@xmb-rcd-x01.cisco.com> <CADJ9OA9gWyMV9kdobnZL8bEDgv5bnfRHFRdBU5x-Hzbh7nihOw@mail.gmail.com> <19846.1365772913@sandelman.ca> <CADJ9OA-oSa50iRyoxEXmrQXR1+zvqNbgd1ZvbqTVg6DvLeoOZQ@mail.gmail.com>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Fri, 12 Apr 2013 12:57:51 -0400
Message-ID: <2264.1365785871@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: IETF 6TSCH <6tsch@ietf.org>
Subject: Re: [Roll] [6tsch] draft agenda for call on April 12
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2013 16:58:15 -0000

On the 6tsch I wrote:

** Given the apparent dependancy that
   draft-ietf-roll-rpl-industrial-applicability-00 
   has on the 6tsch work, I wonder if this "BOF" effort would like to
   suggest text changes to the charter of the ROLL WG to the IESG.

** Would the 6tsch WG/BOF like to adopt the above work item?

In further thinking this morning while unblock the shower drain, I
realized that there are a number of additional options.


From draft-ietf-roll-rpl-industrial-applicability-00:

>   It appears from the above sections that whether and the way RPL can
>   be applied for a given flow depends both on the deployment scenario
>   and on the class of application / traffic.  At a high level, this can
>   be summarized by the following matrix:
>
>
>+---------------------+------------------------------------------------+
>|   Phase \  Class    |   0       1       2       3       4       5    |
>+=====================+================================================+
>|   Construction      |                   X       X       X       X    |
>+---------------------+------------------------------------------------+
>|   Planned startup   |                   X       X       X       X    |
>+---------------------+------------------------------------------------+
>|   Normal operation  |                           ?       ?       ?    |
>+---------------------+------------------------------------------------+
>|   Planned shutdown  |                   X       X       X       X    |
>+---------------------+------------------------------------------------+
>|Plant decommissioning|                   X       X       X       X    |
>+---------------------+------------------------------------------------+
>| Recovery and repair |   X       X       X       X       X       X    |
>+---------------------+------------------------------------------------+
>
> ? : typically usable for all but higher-rate classes 0,1 PS traffic
>
>                    Figure 1: RPL applicability matrix

my understanding is that "Normal Operation" is when the 6tsch schedules
are really necessary.  The rest of the time a non-timeslotted system
might be perfectedly acceptable.

So additional options would be for 
   draft-ietf-roll-rpl-industrial-applicability
to become
   draft-ietf-roll-rpl-industrial-nonnormal-applicability

and for a new document:
   draft-ietf-6tsch-rpl-industrial-normal-applicability

to come to exist.

This would mean that the current document would essentially declare
normal operation to be out of scope (punt at 6tsch for this), and for
the document to get finished.

That would remove 6tsch as a blocker for this document.
It's not the only option on how to do things.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [