Subject: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones

From: "roll issue tracker" <[email-masked]>
Date: Thu, 01 Nov 2012 14:47:19 -0000

#110: trickle-mcast: do applications receive all multicast, or just MPL
encapsulated ones

 There's still the case that multicasts from non-MPL nodes are received by
 MPL-forwarder-nodes
 (presumably). Should there be guidelines here? Example: if an application
 on my MPL-forwarder node
 joins multicast group FF05::1234, will the application then receive IP
 multicasts sent
 with destination FF05::1234, or will it only receive those IP multicasts
 to FF05::1234
 that were delivered encapsulated in an FF0X::MPL packet ?

 That decision could be out of scope; but on the other hand may lead to
 different
 implementers making different choices here.

-- 
-----------------------------+---------------------------------------------
 Reporter:  mcr@…            |      Owner:  draft-ietf-roll-trickle-mcast@…
     Type:  enhancement      |     Status:  new
 Priority:  major            |  Milestone:
Component:  trickle-mcast    |    Version:
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+---------------------------------------------

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/110>
roll <http://tools.ietf.org/wg/roll/>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 1 Nov 2012 16:08:42 +0000

The FF0X::MPL multicast address serves to identify a group of MPL forwarders within an MPL domain.

I think if any device sends a packet to FF0X::MPL, it should be delivered to and processed by all devices subscribed to that address.

Thoughts from others?

--
Jonathan Hui

---

From: Robert Cragie <[email-masked]>
Date: Thu, 01 Nov 2012 18:21:24 +0000

We could say that address has to be subscribed to by all MPL forwarders 
and SHOULD (MUST?) be used with a MPL Option. If the language in the 
draft were tightened up a bit regarding packet types, this would mean 
that if for some reason a packet to FF0X::MPL was originated without a 
MPL Option, it would be harmlessly (but wastefully) encapsulated and the 
chances are anything beyond the MPL domain would not be subscribed so 
would be ignored for that reason. Of course, if used with a MPL Option, 
no encapsulation is needed, there is a one-to-one mapping between the 
MPL domain and the address scope and it would not be forwarded on 
interfaces which don't understand MPL.

Robert

On 01/11/2012 4:08 PM, Jonathan Hui (johui) wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 1 Nov 2012 18:51:46 +0000

HI Robert,

I'm not sure I follow you.  If we require MPL forwarders to drop packets sent to FF0X::MPL and do not contain an MPL Option, how do we expect one to encapsulate it for forwarding within the MPL domain?

I suggested in another email that encapsulation be required unless the IPv6 Destination Address be equal to FF0X::MPL.  If it is anything else, then encapsulation is required.

Also, since Peter would like to use unicast prefix-based multicast addresses, there is a one-to-one mapping between the MPL domain and the (address scope, group identifier) tuple.

--
Jonathan Hui

On Nov 1, 2012, at 11:21 AM, Robert Cragie <[email-masked]> wrote:

> We could say that address has to be subscribed to by all MPL forwarders and SHOULD (MUST?) be used with a MPL Option. If the language in the draft were tightened up a bit regarding packet types, this would mean that if for some reason a packet to FF0X::MPL was originated without a MPL Option, it would be harmlessly (but wastefully) encapsulated and the chances are anything beyond the MPL domain would not be subscribed so would be ignored for that reason. Of course, if used with a MPL Option, no encapsulation is needed, there is a one-to-one mapping between the MPL domain and the address scope and it would not be forwarded on interfaces which don't understand MPL.
> 
> Robert
> 
>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 02 Nov 2012 01:04:43 +0000

Hi Jonathan,

Comments inline.

Robert

> I'm not sure I follow you.  If we require MPL forwarders to drop packets sent to FF0X::MPL and do not contain an MPL Option, how do we expect one to encapsulate it for forwarding within the MPL dom…
<RCC>I wasn't suggesting that. If you look at the definitions I 
suggested, any original non-MPL multicast packet is always encapsulated, 
not dropped, irrespective of its destination address (unless link local, 
which is never likely to happen).</RCC>
> I suggested in another email that encapsulation be required unless the IPv6 Destination Address be equal to FF0X::MPL.  If it is anything else, then encapsulation is required.
<RCC>I was saying that the FF0X::MPL address should also have an 
accompanying MPL option otherwise if a MPL forwarder encountered an 
original non-MPL multicast packet with destination address FF0X::MPL, it 
would (probably) end up encapsulating it.</RCC>
> Also, since Peter would like to use unicast prefix-based multicast addresses, there is a one-to-one mapping between the MPL domain and the (address scope, group identifier) tuple.
<RCC>That seems to make sense but I would like to see some more details 
on that proposal</RCC>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Fri, 2 Nov 2012 03:18:25 +0000

Hi Robert,

On Nov 1, 2012, at 6:04 PM, Robert Cragie <[email-masked]> wrote:

> <RCC>I wasn't suggesting that. If you look at the definitions I suggested, any original non-MPL multicast packet is always encapsulated, not dropped, irrespective of its destination address (unless link local, which is never likely to happen).</RCC>

Ah, OK.  I believe we are in agreement.  That is consistent with what I meant in my original statement: "if any device sends a packet to FF0X::MPL, it should be delivered to and processed by all devices subscribed to that address."  And to further clarify my statement, the delivery occurs with encapsulation if the source did not include an MPL Option.

> <RCC>I was saying that the FF0X::MPL address should also have an accompanying MPL option otherwise if a MPL forwarder encountered an original non-MPL multicast packet with destination address FF0X::MPL, it would (probably) end up encapsulating it.</RCC>

In agreement here as well.

> <RCC>That seems to make sense but I would like to see some more details on that proposal</RCC>

How about defining an MPL domain in this manner:

1) MPL multicast address: An IPv6 multicast address of arbitrary scope used by MPL forwarders to communicate with other MPL forwarders in the same scope zone of the IPv6 multicast address.

2) MPL domain: A connected set of interfaces subscribed to the same MPL multicast address within the scope zone of that IPv6 multicast address.

Comments/suggestions?

--
Jonathan Hui