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

Don Sturek <d.sturek@att.net> Tue, 30 October 2012 17:32 UTC

Return-Path: <d.sturek@att.net>
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 127A321F8734 for <roll@ietfa.amsl.com>; Tue, 30 Oct 2012 10:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Level:
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=3.100, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MG+uKSjxrwF for <roll@ietfa.amsl.com>; Tue, 30 Oct 2012 10:32:10 -0700 (PDT)
Received: from nm14-vm0.access.bullet.mail.mud.yahoo.com (nm14-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7D521F85E6 for <roll@ietf.org>; Tue, 30 Oct 2012 10:32:10 -0700 (PDT)
Received: from [66.94.237.127] by nm14.access.bullet.mail.mud.yahoo.com with NNFMP; 30 Oct 2012 17:32:09 -0000
Received: from [98.139.244.50] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 30 Oct 2012 17:32:09 -0000
Received: from [127.0.0.1] by smtp112.sbc.mail.bf1.yahoo.com with NNFMP; 30 Oct 2012 17:32:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1351618329; bh=bZayPGRH03iEGxGZusUTcKHTTTpB7BmJKMqFipmCRiQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=nQHe11mCJuqgzz6CP9pQ5UPvDLnKUKSFTGT9+AQvoj4zb6NLFv6AV7v20hPfK4M6iQshsyvYE7/5LISh8wifQyo7ls/oCAhIVqcjRvW4iEpMHHvk8hmr734+XAYb2L4eWwI2rtxIKKwA87yO6Qd1KRc4CRo4bNfjTnbIWmoxNcQ=
X-Yahoo-Newman-Id: 678060.78394.bm@smtp112.sbc.mail.bf1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: OHYwgksVM1leKz0L3BH5TiLWIktkNO5ZZ37MdcZn2ffQOS6 cczVgcv_BDqg75zi8iARYgJNwkgIlhuVB2bOqadj0GIMptzOGa1TR5N5kVS8 Kb9ringi6305KYOSdF6Sv4jujikSDq.KohPzkyBzA.9oCeV6MDDO1kn8YU98 myv8MjGwG062wYdAs8oUbT7yvzqBs6QK5SJp9HMmPjjvq.LUFwl055Reo5Ep jpvRPBqapwYe38CQ7uu.wJEm7qsa1sqtzybbTJjRlnVUOXMh9HtjtGbTGmKK 8jticUFNH7aXOxtTjqoHC0OSzfwhtKY5yVUd.RD8jpt8cgrSI5moQ74rZ1J0 NY_hkvxeUanWuHdJnB4STKmB7p34pR0C.Yq3bqxtDJA1vlGcBplP04902G9Z wuUMfGFDZj8Oaoz0YfN9bUGY2kGDl81paY93plORqs7kjkILeCahUBxFntjx k.MLHtMtf23Rn9Hum
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
Received: from [10.1.1.135] (d.sturek@66.27.60.174 with login) by smtp112.sbc.mail.bf1.yahoo.com with SMTP; 30 Oct 2012 10:32:09 -0700 PDT
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Tue, 30 Oct 2012 10:31:58 -0700
From: Don Sturek <d.sturek@att.net>
To: Jonathan Hui <jonhui@gmail.com>
Message-ID: <CCB55B3A.1B690%d.sturek@att.net>
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
In-Reply-To: <43B84D3E-3B20-4FBC-8AFE-A02FFCB913CE@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: roll@ietf.org
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
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: Tue, 30 Oct 2012 17:32:12 -0000

Hi Jonathan,

What you wrote below sounds correct.

For applications like Peter's that are sensitive to packet length and who
may want to have application behavior similar to sending multicast
requests from outside the multi-link subnet, they could utilize an
application on the border router to ensure that IP in IP tunneling is not
used (the application can support unicast commands to it targeting a
collection of lamps or devices then the application can generate the MPL
multicast locally to the multi-link subnet devices)

Don


On 10/30/12 10:15 AM, "Jonathan Hui" <jonhui@gmail.com> wrote:

>
>Yes, a goal of the current draft is to support both cases (use of
>IPv6-in-IPv6 encapsulation or not).
>
>The intent is as follows:
>
>1) If the source of the multicast packet is within the MPL forwarding
>domain and the destination has a scope equal to or smaller than the MPL
>multicast scope, then no IPv6-in-IPv6 encapsulation is required.
>
>2) If the source of the multicast packet is outside the MPL forwarding
>domain or the destination has scope greater than the MPL multicast scope,
>then IPv6-in-IPv6 encapsulation is required.  When using IPv6-in-IPv6
>encapsulation, then the all MPL forwarders multicast address with scope =
>MPL multicast scope is used as the destination address in the outer
>header.
>
>Thoughts?
>
>--
>Jonathan Hui
>
>On Oct 30, 2012, at 4:46 AM, Don Sturek <d.sturek@att.net> wrote:
>
>> Hi Peter,
>> 
>> I still need to read the latest draft so take what I say here with that
>>in
>> mind......
>> 
>> I was hoping that we could support not using IP in IP tunneling if the
>> scope of the multicast transmission was only within the multi-link
>>subnet
>> managed by the border router.   I was hoping that only transmission
>> emanating from outside the multi-link subnet, received at the border
>> router, with scope that includes the devices in the multi-link subnet
>> would require IP in IP tunneling (and vice versa in terms of multicasts
>> generated in the multi-link subnet with scope outside).  I haven't yet
>> read the draft carefully to know if this is possible.
>> 
>> Don
>> 
>> 
>> On 10/30/12 1:34 AM, "peter van der Stok" <stokcons@xs4all.nl> wrote:
>> 
>>> Hi Don,
>>> 
>>> and more specifically under which conditions. That gives the
>>> possibility to choose the conditions such that the encapsulation is not
>>> needed.
>>> 
>>> Don Sturek schreef op 2012-10-29 16:56:
>>>> Hi Peter,
>>>> 
>>>> I think your suggested changes to the Trickle Multicast draft point
>>>> out
>>>> why IP in IP tunneling is needed.
>>>> 
>>>> Don
>>>> 
>>>> 
>>>> 
>>>> On 10/29/12 3:44 AM, "peter van der Stok" <stokcons@xs4all.nl> wrote:
>>>> 
>>>>> 
>>>>> Dear WG,
>>>>> 
>>>>> 
>>>>> Attached my suggestions for text modifications including some nits. I
>>>>> used the facilities of word to edit and comment text with traces.
>>>>> 
>>>>> When writing text about MC scope and MC domain, I was puzzled by the
>>>>> all MPL forwarders multicast address which removes the possibility to
>>>>> address a given multicast group. We expect multiple (possibly
>>>>> disjunct)
>>>>> MC groups in our wireless networks.
>>>>> Also I failed to understand why encapsulation was necessary once the
>>>>> message was received by the seed.
>>>>> To make it possible to configure the interface with one MC scope I
>>>>> added the possibility to use Unicast-Prefix-based IPv6 Multicast
>>>>> Addresses (RFC 3306).
>>>>> 
>>>>> 
>>>>> Probably, I overlooked many aspects which make the suggestions
>>>>> impractical, but I hope that the intention is clear.
>>>>> 
>>>>> Peter van der Stok
>>>>> 
>>>>> Michael Richardson schreef op 2012-10-25 23:30:
>>>>>> I suggest that you propose specific text to the list to modify the
>>>>>> document.
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> Roll@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/roll
>>> 
>> 
>> 
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>