Re: [Roll] IPv6 multicast scope 0x03 in trickle-mcast

Kerry Lynn <kerlyn@ieee.org> Wed, 13 March 2013 14:35 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 9013F21F8C83 for <roll@ietfa.amsl.com>; Wed, 13 Mar 2013 07:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level:
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 AUyULZu5wOhF for <roll@ietfa.amsl.com>; Wed, 13 Mar 2013 07:35:02 -0700 (PDT)
Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id A89D921F8C5C for <roll@ietf.org>; Wed, 13 Mar 2013 07:35:02 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id l20so1166533oag.9 for <roll@ietf.org>; Wed, 13 Mar 2013 07:35:02 -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:cc:content-type; bh=BrspiF9dP8AUyvn8gFLKR9KoRMuZbk0UzwWBNLJPtmM=; b=y9zThpoF3Aa8OVJDmGF8wWH+NiIYlCg3Vlk2Eu29wrWrf4/NRNe4o8vSh9mPE5FR2d 1LLumnE5DEVxnwQH2JWRE+u+9SikBpnyoAjRScFooaNrBUkafHCFcPvZid05gZ9f+xge EDSTFfORN+NsKJkb+SAOpIHWtGwRIOg0T9379+W4atqK/Q/paJeZfv1ItmxHxbqamw/a 0D8Gb99telRJJ5FHjOaUKFsbhccLMGXDpg7TSn+RTcWAy8ZwvbIVQE/Ox8URQV1vLMKK w2E0NsWQ6quLPucXwafM+9eE1EJ9MGHyWEpFCQJFCvzbRz51wPYiiuGIJ9oZuH4EGDtL 4z0g==
MIME-Version: 1.0
X-Received: by 10.182.98.109 with SMTP id eh13mr16047856obb.50.1363185302299; Wed, 13 Mar 2013 07:35:02 -0700 (PDT)
Sender: kerlyn2001@gmail.com
Received: by 10.60.4.233 with HTTP; Wed, 13 Mar 2013 07:35:02 -0700 (PDT)
In-Reply-To: <0CD48245-8B5B-416B-AE6B-F780CB44B89E@gmail.com>
References: <0CD48245-8B5B-416B-AE6B-F780CB44B89E@gmail.com>
Date: Wed, 13 Mar 2013 10:35:02 -0400
X-Google-Sender-Auth: iwmC0FLemQoBDsbi3rmLHs543hU
Message-ID: <CABOxzu35XiM1HSPO0=hfFmOV7uCjzcR_dNDHH-roXybMON-atg@mail.gmail.com>
From: Kerry Lynn <kerlyn@ieee.org>
To: Ralph Droms <rdroms.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=14dae93a15c3b4ea8004d7cf4fa3
Cc: "6man-chairs@tools.ietf.org Chairs" <6man-chairs@tools.ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "roll@ietf.org" <roll@ietf.org>, "roll-chairs@tools.ietf.org" <roll-chairs@tools.ietf.org>
Subject: Re: [Roll] IPv6 multicast scope 0x03 in trickle-mcast
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 13 Mar 2013 14:35:03 -0000

On Wed, Mar 13, 2013 at 9:33 AM, Ralph Droms <rdroms.ietf@gmail.com>; wrote:

> WG - To help move the trickle multicast spec along for ZigBee, I applied
> to IANA for the well-known multicast address for ALL_MPL_FORWARDERS.
>
> As part of the review, Stig Venaas (designated expert) pointed out that
> draft-ietf-roll-trickle-mcast specifies the use of IPv6 multicast scope
> 0x03, which is currently "reserved" [RFC4291].  Turns out it was never
> officially defined as "subnet-local scope" in an RFC, although it was
> identified as such in early IPv6 addressing architecture I-Ds.  So,
> something has to be done to allow MPL to use scope 0x03.
>
> Stig, the Internet ADs, 6man co-chairs, roll co-chairs and I discussed the
> issue, and devised a plan to redefine scope 0x03 to be "unassigned" (like
> the other unused scope values), and then identify scope 0x03 in
> draft-ietf-roll-trickle-mcast as a special-purpose use for "trickle
> multicast networks" (rather than a "subnet").
>
> draft-ietf-roll-trickle-mcast-04 will need to be edited a little, but
> otherwise I think this plan should meet ZA's requirements.  Also, I'll need
> to publish a 1-paragraph RFC with the new definition of scope 0x03, but
> that will be a very quick process.
>
> The next revision of draft-ietf-roll-trickle-mcast will include the
> necessary edits.  I'll start the process to publish the RFC to redefine
> scope 0x03 next week.
>
> - Ralph
>
> I don't mean to hijack this thread, but I mentioned in the ROLL meeting
yesterday that
I'd have comments/questions regarding draft-ietf-roll-trickle-mcast-04
(MPL) and I think
they're relevant to this proposed definition of IPv6 multicast scope 0x03.

My interest is in using MPL in networks of heterogeneous links, e.g.
homenet.  My
original thinking was that when Proactive Forwarding is employed it might
be useful
to identify links that have no hidden nodes (e.g. ethernets) and suppress
repeating MPL
Data Messages on links that have this property if the message was received
on that link
(flooding bridges work this way).

In further conversation with Jonathan, it seemed that e.g. a site-scoped
message could
be propagated by MPL through a heterogeneous network using link-local
(0x02) multicast
scope and without any changes to the document.  For example, assuming a
site-scoped
multicast message originates in the 6LoWPAN it would be decapsulated at the
6LBR.
The MPL Option header could be re-written with the original packet's source
address
now included as the seed-id.  The packet is then encapsulated with
link-local multicast
scope.  Crucially, reactive forwarding is used on ethernet or other BMA
links to avoid
unnecessary traffic.  (Would this all work as I think?)

If I understand the proposed use of multicast scope 0x03, there would no
longer be a
scope boundary at the 6LBR.  Any router acting as a MPL forwarder would
presumably
treat all its ports as being in multicast scope 0x03 by default, modulo
site-boundary detection.
I think it would be useful in this context to assign proactive/reactive
forwarding behavior
on a port-by-port basis with ports on BMA (e.g. ethernet) links defaulting
to "reactive".

Thoughts?

-K-