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

Dario Tedeschi <dat@exegin.com> Thu, 08 November 2012 20:03 UTC

Return-Path: <dat@exegin.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 D782F21F85B2 for <roll@ietfa.amsl.com>; Thu, 8 Nov 2012 12:03:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Level:
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 T7L4LCielzkq for <roll@ietfa.amsl.com>; Thu, 8 Nov 2012 12:03:53 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D863021F868D for <roll@ietf.org>; Thu, 8 Nov 2012 12:03:52 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id ro8so2431511pbb.31 for <roll@ietf.org>; Thu, 08 Nov 2012 12:03:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=HxdzTQ1bs/zVPqxNevNg7hOYqp5E69orKBAmlKninxo=; b=TKpTEuN6rytcKzrCUPT+SsN4rgYUhgZDJmvSeis+MfwGIOf6f6shVrxCmqYnKt5E4v VeVEeBD8nbgfJnevq+//h3TAVdkEPXKNlklpXwP/IH0+aLFnu/3rQ9jlrR5YmkcXu5Mo t/5yJAiYHAtStNASsBC80+vgwl+3kLO5j8uYhPBPWx6pOOlxbtYZjbq7Xl+Y2W88hJFa TkbhfKbBMIP3pSQ/4WlCz89Ekj/xisUNykFC7zYtUCAVL1Zi6iVho7T5WDYAQSsdMVZx FNqN6p620N4vAyNuevFku4lg0DRolG9VU8zff3cFtojRmdwMCaWMD/Pyowku57cybyeO wGQQ==
Received: by 10.68.253.102 with SMTP id zz6mr26940166pbc.99.1352405032566; Thu, 08 Nov 2012 12:03:52 -0800 (PST)
Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id pv8sm6312950pbc.26.2012.11.08.12.03.50 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 12:03:51 -0800 (PST)
Message-ID: <509C1037.8030506@exegin.com>
Date: Thu, 08 Nov 2012 12:04:07 -0800
From: Dario Tedeschi <dat@exegin.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: "Jonathan Hui (johui)" <johui@cisco.com>
References: <CCB50B52.1B637%d.sturek@att.net> <B50D0F163D52B74DA572DD345D5044AF0F6E519E@xmb-rcd-x04.cisco.com> <b4475c01a2da3a733b3fae9fccab42a7@xs4all.nl> <B50D0F163D52B74DA572DD345D5044AF0F6E9646@xmb-rcd-x04.cisco.com> <5091B2A3.1090205@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F6ECE93@xmb-rcd-x04.cisco.com> <c04faf7dd80fa0cc01bc2c5123da0c7b@xs4all.nl> <404.1351779310@obiwan.sandelman.ca> <21d5e8c9a5f4a517a8fa421497f37c8a@xs4all.nl> <19755.1351900015@sandelman.ca> <7a5d49da82e9b77ea808b389792ccdeb@xs4all.nl> <B50D0F163D52B74DA572DD345D5044AF0F702989@xmb-rcd-x04.cisco.com>
In-Reply-To: <B50D0F163D52B74DA572DD345D5044AF0F702989@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlfw44er7GIl7XKodrUqbr1S/Esicj65lSzwqfL1ecmUVk2klWJRAm5vDUsF31K2/2XnkAq
Cc: "roll@ietf.org WG" <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: Thu, 08 Nov 2012 20:03:54 -0000

On 05/11/2012 5:27 AM, Jonathan Hui (johui) wrote:
> Hi Peter,
>
> To reiterate my thoughts - this works because the IPv6 multicast address identifying the endpoints also identifies the MPL domain.

This depends on how one defines "MPL domain". Is it defined like a 
"routing domain", where a "routing domain"  is a collection of networked 
systems that operate a common routing protocol? Or is it defined as the 
area an mc address will cover. I think it should be the former, in which 
case FF02::MPL would identify the "MPL domain", since any router 
listening on FF02::MPL would be participating in the MPL protocol.


>    How would you limit the scope of disseminating a message sent to a well-known IPv6 multicast address?  Or is the answer (i) we don't support anything other than unicast-prefix-based multicast addresses or (ii) we don't limit the dissemination scope sent to anything else?

That is determined by routing information, and I'm not sure MPL should 
be trying to answer that question. MPL is not really a routing protocol, 
because it does not disseminate routing information. It's more a means 
of propagation. Routing information (implied or explicit) has to come 
from somewhere, though. And since I think MPL was written to support 
RPL's non-storing mode of operation, I think RPL should be responsible 
for providing that information. An example of implied routing 
information could be the prefix in a PIO used for address auto-config (a 
'la unicast-prefixed-based mc), while an example of explicit routing 
information might be a mc prefix in a RIO. If someone wants to use MPL 
without RPL, then routers have to either forward packets based on 
mc-scope alone or they'd have to define some means of disseminating 
routing information.


>
> The options I see:
>
> 1) Use the same IPv6 multicast address for identifying both endpoints and MPL domain.
> 1a) MPL is not used to disseminate packets destined to other IPv6 multicast addresses.
> 1b) MPL may be used to disseminate packets destined to other IPv6 multicast addresses, but will disseminate across any connected region of MPL forwarders.
>
> In supporting the cases above, a well-known link-local multicast address is used in the outer IPv6 header when encapsulation is used.  The outer header's MPL Option and the inner header's IPv6 destination address is used to determine whether to (i) pass up to higher layers and (ii) forward the packet.
>
> If we decide to support inclusion of the MPL Option without encapsulation, then a forwarder needs to understand that the MPL Option and IPv6 destination address in the same IPv6 header are used to determine (i) pass up to higher layers and (ii) forward the packet.
>
> 2) Decouple the concept of MPL domain and application endpoint identifiers.
> 2a) Identify MPL domain using outer header's IPv6 destination address.
> 2b) Identify MPL domain using "instance" field in MPL Option.
>
> Both cases above would allow limiting the dissemination scope of any arbitrary IPv6 multicast address, including well-known addresses.  Furthermore, the forwarding decision is made using only information contained in a single IPv6 header - option 2a relies on the MPL Option and the IPv6 destination address of the outer header, option 2b relies only on information contained in the MPL Option.
>
> Both options 1 and 2 require managing another identifier space.  Option 1 requires configuring the devices with a prefix.  Option 2a requires configuring devices with a multicast group.  Option 2b requires configuring devices with an MPL instance.
>
> Option 1 avoids the need to carry a separate MPL domain identifier since it requires the IPv6 multicast addresses to use the same prefix that identifies the MPL domain.
>
> Comments/thoughts?
>
> --
> Jonatan Hui
>
> On Nov 5, 2012, at 7:23 AM, peter van der Stok<stokcons@xs4all.nl>  wrote:
>
>> Hi Michael,
>>
>> The answer to your question is given by the scenario of Dario that I reproduced below.
>>
>> Actions  4 and 5 describe what I intended to limit the forwarding.
>>
>> In addition I like to mention that when a multicast is intended for a group with members in N2 and N1
>> the multicast address could have a prefix that is a prefix to Fd01::/64 and Fd02::/64.
>> For example the MC address is then FF35:0040:FD0::1.
>> In accordance, I suggest that all forwarders in N1 and in N2 accept and forward the message.
>>
>>
>> As an aside I like to mention that BR1 and BR2 use the same channel for 802.15.4 because often there are many physical and organisational constraints who may dictate such an alocation.
>>
>> Greetings,
>>
>> Peter
>>
>> -------- DArio scenario     -------
>>
>> Example: Two border routers (BR1 and BR2) each forming a network:
>>
>> --- Network 1 (BR1) ---
>> Unicast prefix: FD01::/64
>> Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96
>>
>> --- Network 2 (BR2) ---
>> Unicast prefix: FD02::/64
>> Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96
>> 1.	A non-MPL aware node in network 1 wishes to send a multicast to all nodes in network 1.
>> 2.	It sends to multicast address FF35:0040:FD01::1, un-encapsulated.
>> 3.	The packet is received by a MPL router in network 2 (N2R1).
>> 4.	N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, therefore, does not pass the packet up.
>> 5.	N2R1 finds no matching routing information for FF35:0040:FD01::1 and does not forward the packet. The packet is, therefore, discarded.
>> 6.	The packet is also received by a MPL router in network 1 (N1R1).
>> 7.	N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the packet up. Note: This would depend on whether or not any higher layers were actually interested in the mc group. Also, this step is not a prerequisite for the next step to occur.
>> 8.	N1R1 finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64
>> 9.	N1R1 encapsulates the packet with a MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
>> 10.	N1R1 transmits the new resulting packet.
>> 11.	The packet is received by another MPL router in network 1 (N1R2).
>> 12.	Seeing that the destination address is FF02::MPL, N1R2 decapsulates the packet (i.e. the original packet exits the tunnel).
>> 13.	N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the inner packet up. Note: This step is not a prerequisite for the next step to occur.
>> 14.	N1R2 also finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64.
>> 15.	N1R2 re-encapsulates the packet with the *original* MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
>> 16.	N1R2 transmits the resulting packet.
>> 17.	The packet is received by yet another MPL router in network 2 (N2R2).
>> 18.	Seeing that the destination address is FF02::MPL, N2R2 decapsulates the packet (i.e. the original packet exits the tunnel).
>> 19.	N2R2 finds no matching routing information or listener for FF35:0040:FD01::1 and, therefore, discards the packet.
>>
>> ----- end Dario scenario -------
>>
>> Michael Richardson schreef op 2012-11-03 00:46:
>>> see inline
>>>
>>> peter van der Stok<stokcons@xs4all.nl>  wrote:
>>>     peter>  It is related to the scope of the multicast, but not in the
>>>     peter>  administrative sense, but in an operational sense when
>>>     peter>  wireless forwarders receive MPL messages and they should be
>>>     peter>  able to filter only those messages that are targeted to the
>>>     peter>  subnet of which they are part.
>>>
>>> Is this about configuring multicast (hardware) filters so that the wrong
>>> nodes aren't woken up?
>>> Is the case you speak up articulated by one of Robert's diagrams?
>>>
>>>     peter>  I explained the case earlier with an example.
>>>
>>> Yes, I had asked a question about that too.  I didn't understand how
>>> the two networks overlapped.  Do they share the same 15.4 key material?
>>> Do they have the same beacons?
>>>
>>> My feeling is that you are solving a problem which exists on paper, but
>>> not in a real 15.4 network.  But, I could be completely wrong.
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll