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-