Subject: Re: [Roll] [roll] #128: Trickle multicast could be considered in other applications?

From: Michael Richardson <[email-masked]>
Date: Sat, 17 Aug 2013 16:50:12 -0400

{answering some old emails, and trying to bring about some consensus to
close this ticket} 

>>>>> "lynn" == roll issue tracker <[email-masked]> writes:
    lynn>  Apart from the fact that this draft is introduced in ROLL to
    lynn> address a problem inherent in multi-link subnets, I see
    lynn> nothing in the proposal that limits it to such networks.  It
    lynn> seems to me that trickle multicast could be considered in
    lynn> other applications, e.g. homenet, if it compares favorably
    lynn> with PIM-xM in complexity.

I agree that it could be used elsewhere, and I think it's important to
remember that it's going to run over all sorts of media, as ROLL runs
over all sorts of links.

    adrian>  From Adrian Farrel about section 3 Applicability Statement

    adrian>  - can this be run over a wired (non-lossy, non-constrained
    adrian> environment) - should this be contained at the LBR,  

Yes, it can be gatewayed at the LBR, the because the LBR is the edge of
the LLN, not necessarily the edge of the DODAG.    The DODAG may be
extended across one or more wired segments to link(*) different parts of
the LLN together. 

(*) (I wrote "bridge" initially, and that's meaningful in a colloquial
    term, but I don't want to confuse people into thinking it's related
    to 802 concepts)
	
    adrian> and if
    adrian> so, can mcast traffic be gatewayed into the Internet

define "Internet" :-)
If you are asking if it can escape into an ISP uplink due to
misconfiguration of scope-3 interfaces, yes it could do that.  
At which point, it would face non-MPL routers, and traffic would die.
I can see a potential risk on cable networks where it some combination
of misconfigured home gateways might permit MPL traffic from one home to
enter another home's network. 

If you are asking if mcast traffic could be gatewayed into the PIM
multicast space, I supposed with the emission of the right IGMPs onto
the link with the PIM routers, and then decapsulation/encapsulation of
the packets, such a thing could occur. I don't see it as desireable.
The inner packets are expected to scope-2 (link) packets, so really, no 
compliant PIM router would do anything with them.

Are you asking for some Security Considerations here?

    adrian> - can
    adrian> MPL operate in a mixed environment where not all routers are
    adrian> MPL capable?  

No, I don't think so.  Non-MPL routers will not forward things.

    adrian> - do the hosts need to be in any way aware
    adrian> that their mcast is supported by MPL?

At some point the answer has been yes and at other points it has been
no, and I guess I have to back to the document to remember what we
concluded.

-- 
Michael Richardson
-on the road-

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 21 Aug 2013 12:50:00 +0000

> At some point the answer has been yes and at other points it has been no, and I guess I have to back to the document to remember what we concluded.

I believe that MPL-04 does not answer this, and perhaps even cannot, because it is out of scope in the current text.
It is not described how a non-MPL host can 'inject' its multicast packet into an MPL domain, or how an MPL Forwarder should 'demux' a multicast packet out from the MPL Domain so that nearby listening non-MPL hosts can receive the multicast.

Solutions for this exist that require a host to be aware of MPL, and solutions exist as well that don't require this.

If Section 3 (Applicability Statement) could just mention this, plus the other questions from ticket #128 that are now answered, I believe the ticket can be closed.

regards,
Esko

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Don Sturek <[email-masked]>
Date: Wed, 21 Aug 2013 07:04:00 -0700

Hi Esko,

Not quite sure about this statement:    "It is not described how a non-MPL
host can 'inject' its multicast packet into an MPL domain, or how an MPL
Forwarder should 'demux' a multicast packet out from the MPL Domain so
that nearby listening non-MPL hosts can receive the multicast."

The scope of a multicast message arriving at a MPL capable border router
determines whether it is injected into the MPL domain or not (and it would
then be encapsulated) and, again, the scope of any generated multicast
within a MPL domain determines whether it exits the MPL domain
(encapsulated on generation in the MPL domain and de-encapsulated at the
MPL border and forwarded if necessary based on the addressing scope of the
interface).

For our use case (ZigBee IP), we use 0x03 (realm-specific scope) for
forwarding in the MPL domain (FF03::FC) and then we encapsulate our (at
least our discovery messages) as site specific (FF05::FB).  That said, it
would be easy to add other applications with different address scope.

I think it is really up to the application to determine the scope of the
messages that are sent and then the rest of the addressing architecture
simply ensures the messages are forwarded to all potential group members.

Don

On 8/21/13 5:50 AM, "Dijk, Esko" <[email-masked]> wrote:

>I believe that MPL-04 does not answer this, and perhaps even cannot,
>because it is out of scope in the current text.
>It is not described how a non-MPL host can 'inject' its multicast packet
>into an MPL domain, or how an MPL Forwarder should 'demux' a multicast
>packet out from the MPL Domain so that nearby listening non-MPL hosts can
>receive the multicast.
>
>Solutions for this exist that require a host to be aware of MPL, and
>solutions exist as well that don't require this.
>
>If Section 3 (Applicability Statement) could just mention this, plus the
>other questions from ticket #128 that are now answered, I believe the
>ticket can be closed.
>
>regards,
>Esko
>
>
>The information contained in this message may be confidential and legally
>protected under applicable law. The message is intended solely for the
>addressee(s). If you are not the intended recipient, you are hereby
>notified that any use, forwarding, dissemination, or reproduction of this
>message is strictly prohibited and may be unlawful. If you are not the
>intended recipient, please contact the sender by return e-mail and
>destroy all copies of the original message.
>
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 21 Aug 2013 15:12:09 +0000

Don,

I agree with you on the role of the multicast scope. MPL is defined well enough for this aspect. However I was referring to a different situation than you had in mind, most likely.

The situation I have in mind is a LLN mesh network where 'hosts' (IP hosts) can reside at any position in the network. For example, a mesh network where 50% of nodes are MPL Forwarders (together constituting a single MPL domain) and 50% of nodes are hosts that don't know anything about MPL. Suppose one of these hosts, host A, sends out an IP multicast packet and three nearby MPL Forwarder nodes receive this multicast. Then, MPL-04 does not describe whether these MPL forwarders, or which of these, are required to "inject" the multicast packet into the MPL domain. MPL-04 does say that an MPL Forwarder may "inject" such a packet, acting as an MPL Seed.
Similarly there's also no specification how a host B that is 5 hops away from host A, could ever receive this multicast packet. (This won't happen automatically since host B does not listen to the ALL_MPL_FORWARDERS address - it doesn't know about MPL. There's no requirement that every MPL Forwarder "decapsulates" the received packets and resends them unencapsulated for the benefit of hosts.)

I think Section 3 could just mention that additional mechanisms for the above are out of scope.

regards,
Esko

---

From: Robert Cragie <[email-masked]>
Date: Wed, 21 Aug 2013 17:27:01 +0100

Hi Esko,

I agree some of the description in earlier drafts seems to have gone 
away (02->03), resulting in that, as you say, it becomes down to 
configuration whether a MPL Forwarder would actually do this or not in 
both the cases you describe. How it is configured would probably depend 
on scope rules.

Robert

---

From: Robert Cragie <[email-masked]>
Date: Wed, 21 Aug 2013 18:14:34 +0100

Actually Ralph answered this point earlier in the thread - the
configuration information goes in the applicability statement.

Robert
On 21 Aug 2013 17:27, "Robert Cragie" <[email-masked]> wrote:

> Hi Esko,
>
> I agree some of the description in earlier drafts seems to have gone away
> (02->03), resulting in that, as you say, it becomes down to configuration
> whether a MPL Forwarder would actually do this or not in both the cases you
> describe. How it is configured would probably depend on scope rules.
>
> Robert
>
>> I agree with you on the role of the multicast scope. MPL is defined well
>> enough for this aspect. However I was referring to a different situation
>> than you had in mind, most likely.
>>
>> The situation I have in mind is a LLN mesh network where 'hosts' (IP
>> hosts) can reside at any position in the network. For example, a mesh
>> network where 50% of nodes are MPL Forwarders (together constituting a
>> single MPL domain) and 50% of nodes are hosts that don't know anything
>> about MPL. Suppose one of these hosts, host A, sends out an IP multicast
>> packet and three nearby MPL Forwarder nodes receive this multicast. Then,
>> MPL-04 does not describe whether these MPL forwarders, or which of these,
>> are required to "inject" the multicast packet into the MPL domain. MPL-04
>> does say that an MPL Forwarder may "inject" such a packet, acting as an MPL
>> Seed.
>> Similarly there's also no specification how a host B that is 5 hops away
>> from host A, could ever receive this multicast packet. (This won't happen
>> automatically since host B does not listen to the ALL_MPL_FORWARDERS
>> address - it doesn't know about MPL. There's no requirement that every MPL
>> Forwarder "decapsulates" the received packets and resends them
>> unencapsulated for the benefit of hosts.)
>>
>> ______________________________**__
>> intended recipient, please contact the sender by return e-mail and destroy
>> all copies of the original message.
>>
>> ______________________________**_________________
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/roll<https://www.ietf.org/mailman/listinfo/roll>
>>
>>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 25 Aug 2013 21:22:17 -0400

Dijk, Esko <[email-masked]> wrote:
    > about MPL. Suppose one of these hosts, host A, sends out an IP

I really wonder about these MPL-ignorant nodes which are part of an LLN mesh
(and therefore, I think), speak RPL.

Can you tell me more about them so that I am less skeptical about them being
mythical.

-- 
Michael Richardson
-on the road-

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 26 Aug 2013 14:57:22 +0000

> I really wonder about these MPL-ignorant nodes which are part of an LLN mesh (and therefore, I think), speak RPL.
> Can you tell me more about them so that I am less skeptical about them being mythical.

Nodes that are fully MPL-ignorant could be rightfully called mythical, at least I haven't seen an implementation or specification of such nodes within an MPL-enabled LLN mesh. I'm just considering the option that there could be Hosts that are unaware of the forwarding protocol used, whose multicast traffic needs to be interfaced to the MPL domain. If that is an option that no implementer would ever go for anyway, we can safely stop this discussion I think.

Background: A similar situation can be found in the ZigBee-IP specification, that defines "ZIP hosts" in the LLN mesh which do not implement the RPL routing protocol. These hosts send their IP packets to their parent "ZIP router" which further handles the packet using RPL. Sleepy Nodes are for example always ZIP hosts and never ZIP routers. In ZigBee-IP these Hosts are RPL-ignorant, but not MPL-ignorant.  My idea was that there could be another specification X that would define the Hosts also to be MPL-ignorant, for example to save energy in Sleepy Nodes.

regards,
Esko

---

From: Don Sturek <[email-masked]>
Date: Mon, 26 Aug 2013 08:14:06 -0700

Hi Esko,

I believe the reason that the ZIP specification provides for these host
only devices is:
1)  The RPL specification allows for RPL unaware leaf nodes.
2)   However, for the sake of MPL forwarding, I believe the RPL unaware
leaf nodes then do not receive MPL multicasts (which makes sense given
many of these devices are sleepy hosts which would likely not be
guaranteed to receive the transmission anyway).

The implied model used in ZIP is that sleepy host only devices are clients
which initiate actions (and would stay awake long enough to receive any
expected responses) but don't act as servers.

Don

On 8/26/13 7:57 AM, "Dijk, Esko" <[email-masked]> wrote:

>> I really wonder about these MPL-ignorant nodes which are part of an LLN
>>mesh (and therefore, I think), speak RPL.
>Nodes that are fully MPL-ignorant could be rightfully called mythical, at
>least I haven't seen an implementation or specification of such nodes
>within an MPL-enabled LLN mesh. I'm just considering the option that
>there could be Hosts that are unaware of the forwarding protocol used,
>whose multicast traffic needs to be interfaced to the MPL domain. If that
>is an option that no implementer would ever go for anyway, we can safely
>stop this discussion I think.
>
>Background: A similar situation can be found in the ZigBee-IP
>specification, that defines "ZIP hosts" in the LLN mesh which do not
>implement the RPL routing protocol. These hosts send their IP packets to
>their parent "ZIP router" which further handles the packet using RPL.
>Sleepy Nodes are for example always ZIP hosts and never ZIP routers. In
>ZigBee-IP these Hosts are RPL-ignorant, but not MPL-ignorant.  My idea
>was that there could be another specification X that would define the
>Hosts also to be MPL-ignorant, for example to save energy in Sleepy Nodes.
>
>regards,
>Esko
>

---

From: "roll issue tracker" <[email-masked]>
Date: Thu, 29 Aug 2013 23:28:51 -0000

#128: Trickle multicast could be considered in other applications?

Comment (by [email-masked]):

 Date: Thu, 29 Aug 2013 14:34:38 +0000
 From: "Jonathan Hui (johui)" <[email-masked]>
 Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-05.txt

 "This update attempts to address all of the open tickets.  A summary of
 changes is below.  Please provide feedback on these changes.
 Thanks.[[BR]]
 ...[[BR]]
 128:
 - Updated Applicability Statement to indicate that (i) MPL may be used
 over LLN and non-LLN networks, (ii) scope is administratively defined, and
 (iii) hosts need not be aware of MPL but can be if they choose to. "

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08103.html

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg07946.html

-- 
---------------------------------------+------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  enhancement                |      Status:  new
 Priority:  minor                      |   Milestone:
Component:  trickle-mcast              |     Version:
 Severity:  In WG Last Call            |  Resolution:
 Keywords:                             |
---------------------------------------+------------------------------

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/128#comment:4>
roll <http://tools.ietf.org/wg/roll/>