Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04

Kerry Lynn <kerlyn@ieee.org> Fri, 29 March 2013 15:08 UTC

Return-Path: <kerlyn2001@gmail.com>
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 D091F21F8D2D for <roll@ietfa.amsl.com>; Fri, 29 Mar 2013 08:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level:
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 qHBxAR+tVKMt for <roll@ietfa.amsl.com>; Fri, 29 Mar 2013 08:08:08 -0700 (PDT)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 556AA21F8673 for <roll@ietf.org>; Fri, 29 Mar 2013 08:08:08 -0700 (PDT)
Received: by mail-ob0-f181.google.com with SMTP id ni5so462780obc.26 for <roll@ietf.org>; Fri, 29 Mar 2013 08:08:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=4HnRAfyXLKmN+z7W4NIOwbOsrn4UNUyhfslSyMxan5U=; b=kZv3jrOsP9wW4fgU2YlUGpfEHFVxW1clko5r/svHPGJAvggd/dbmfoXtOJKNF28abl aHSMjpxwSCkycTyP8NwAnCz+tHj78t9KDGtOQrLXfanrVd4/1i5w/n6yV3U0xI8EJe+/ QFswPVLBmfgYQPyNap2vavzT5rT9YW2bC/PZ8VVesS37OmKbVX9ktnvGPORbNkiYsg3X 492adWZo7IQh5Mv9tKRYXX3GGB5Vgkwnh8JkdcSTsKWF8e/7G3sErEQaJrpOVIv2/9FN jCh4JojE/Bf4FwYX+7lO0SPstNEfEeITz39r1tmhh4RpYJQnYkUy9arVc2HWn3UGcHm+ QUnA==
MIME-Version: 1.0
X-Received: by 10.60.169.231 with SMTP id ah7mr918270oec.142.1364569687894; Fri, 29 Mar 2013 08:08:07 -0700 (PDT)
Sender: kerlyn2001@gmail.com
Received: by 10.60.33.74 with HTTP; Fri, 29 Mar 2013 08:08:07 -0700 (PDT)
In-Reply-To: <CD7AF44A.1F88D%d.sturek@att.net>
References: <CABOxzu0mqVFZw5wQUZ0Lm_B7AjrtNH140Nxq3wxRhyrWSNF6qw@mail.gmail.com> <CD7AF44A.1F88D%d.sturek@att.net>
Date: Fri, 29 Mar 2013 11:08:07 -0400
X-Google-Sender-Auth: 9-E5yLY4gteZWzdD9M1eWxlI2aY
Message-ID: <CABOxzu1n8uLnzbWApei1De+5evaOJW9KwfDZZpCz1rujQJMPJA@mail.gmail.com>
From: Kerry Lynn <kerlyn@ieee.org>
To: roll@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
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, 29 Mar 2013 15:08:08 -0000

On Fri, Mar 29, 2013 at 10:37 AM, Don Sturek <d.sturek@att.net> wrote:
> Hi Kerry,
>
> The problem that  draft-ietf-roll-trickle-mcast-04 addresses really only
> occurs in route-over mesh routing.  I don't believe Homenet has such
> routing solutions in their charter.  It is possible to see how a group
> like Manet might use the draft but the only concrete forwarding solution
> proposed is over ROLL RPL instances (certainly, provision was left in for
> other multicast address usage and attendant forwarding rules but those
> were out of scope for this draft).
>
I don't think this opinion reflects on the validity of my comments for even
the restricted ROLL use and I'd be interested in feedback from the authors.

In addition to the comments I made previously, I am concerned that the
default for Imax (== Imin) prevents the Trickle timer interval I from ever
doubling.  Combined with a high k, this leads to aggressive Trickle forwarding
in dense parts of the mesh that may inhibit (by interfering with) unicast
responses in transit to the original sender.  Is there a reason for not
relaxing DATA_MESSAGE_IMAX to e.g.
DATA_MESSAGE_TIMER_EXPIRATIONS?

-K-

> I would propose that we move forward with the draft, within ROLL, and not
> wait for input from other groups since the scope of the initial draft
> (absent extensions that other groups could propose in the future) is
> focused on ROLL RPL.
>
> Don
>