Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

Robert Cragie <robert.cragie@gridmerge.com> Tue, 15 January 2013 08:13 UTC

Return-Path: <robert.cragie@gridmerge.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 A52AA21F8840 for <roll@ietfa.amsl.com>; Tue, 15 Jan 2013 00:13:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 hhv6-QjOOhmB for <roll@ietfa.amsl.com>; Tue, 15 Jan 2013 00:13:22 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6297F21F883F for <roll@ietf.org>; Tue, 15 Jan 2013 00:13:17 -0800 (PST)
Received: from client-86-23-89-86.brhm.adsl.virginmedia.com ([86.23.89.86] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1Tv1e0-0006k8-3s for roll@ietf.org; Tue, 15 Jan 2013 08:13:16 +0000
Message-ID: <50F51018.9090705@gridmerge.com>
Date: Tue, 15 Jan 2013 08:15:20 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: roll@ietf.org
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <B50D0F163D52B74DA572DD345D5044AF0F6EFA99@xmb-rcd-x04.cisco.com> <50932647.3050509@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F6F2837@xmb-rcd-x04.cisco.com> <5094202F.4010805@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F6F874A@xmb-rcd-x04.cisco.com> <509C03C2.50809@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F714CBF@xmb-rcd-x04.cisco.com> <509C5F00.2050204@exegin.com> <509D5AF5.4040304@exegin.com> <509DAFEF.5020504@exegin.com> <9143.1352758442@sandelman.ca> <50A382DA.9030706@gridmerge.com> <2150.1352927633@obiwan.sandelman.ca> <50A505AC.2000200@gridmerge.com> <21507.1356119684@sandelman.ca>
In-Reply-To: <21507.1356119684@sandelman.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms020205030307000706040104"
X-Authenticated-As: robert.cragie@gridmerge.com
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
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, 15 Jan 2013 08:13:23 -0000

Hi Michael,

There isn't really a need for both #3 (subnet-local mc address) and #4 
(link-local mc address) as they are both mechanisms for encapsulating a 
mc message originating from or destined for outside the MPL Domain. I 
think the original aim was to keep the specification flexible for 
implementation choice. The latest draft will only specify #3.

Robert

On 21/12/2012 7:54 PM, Michael Richardson wrote:
> (It has come to my attention that additional spam filtering @ietf.org
> was dropping many of my emails, this is a resend)
>
>>>>>> "Robert" == Robert Cragie <robert.cragie@gridmerge.com> writes:
>      Robert> <RCC> Almost there. In the case of forwarding using MPL
>      Robert> domain (subnet-local) mc address, the inner packet is
>      Robert> strictly tunnelled, i.e. there will be no hop count
>      Robert> decrementing per hop. I discussed this offline with Jonathan
>
> okay, and this is because the packet is in a tunnel, which is not
> addressed to the "link", so in effect, it is not a local packet.
>
> I can buy this, and so #3 does not decrement, while #4 does.
>
> What is the use case for #3 and what is the use case for #4?
> What I'm trying to get at here is: what is the argument to have both?
>
> Who is going to need each one?
>
> On 14/11/2012 9:13 PM, Michael Richardson wrote:
>> Robert, has written 3 rules about when to encapsulate, and how to
>> recognize the MPL domain.  With two options #3 and #4.
>>
>> the difference is  (#3):
>>
>>>      2. Outer header will have subnet-local mc address (e.g.
>>>         FF03-based). This can be used to control propagation in
>>>         conjunction with the MPL option.
>> vs (#4)
>>
>> <    2. Outer header will have link-local mc address (e.g. FF02-based).
>> <       This cannot be used to control propagation as it only goes one
>> <       hop; the MPL option is used alone
>>
>> and as far as I can understand in both cases MPL forwarders will
>> decapsulate and re-encapsulate, thus decrementing the inner TTL each
>> time.   Or did I misunderstand here?
>
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll