Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local

["roll issue tracker" <[e-mail]>]

#132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local


Comment (by [e-mail]):

 From: peter van der Stok <stokcons at xs4all.nl>
 Date: Thu, 17 Oct 2013 14:21:51 +0200

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

 "Looking at the discussion there seem to be two issues:


 -1 tunnelling MC messages through MPL domain


 -2 Sending multicast to all members of a mesh




 I suggest to separate them to make the progress of MPL draft independent
 of 0x3 scope definition


 Ad 1)



 I understand that on reception by a seed of a MC message without MPL
 option, the wish is to encapsulate the message with a header which
 contains the MPL option to distribute the message over the mesh using MPL.
 At reception of the message each receiver still needs to check whether the
 MC address in the original message is destined to the receiving node.
 Therefore I think that the encapsulating header does not need the
 ALL_MPL_FORWARDERS multicast address but can be equal to the MC address of
 the original message. This means that receiving nodes need to enable their
 interfaces to the MC-address stored in the header of the original message.
 Given that the node needs to know this address anyway, I don't think this
 complicates the use of MPL.
 This also works for a message leaving the MPL domain.


 Any mistakes in my reasoning? Putting this text in section 5.1, and
 removing the text in section 4.1 can help the progress of MPL draft.


 Ad 2)



 There is a clear wish to distribute a MC message to all members of a mesh
 network, for example to distribute mdns messages or to learn lowpan start-
 up information like address of border router. Making that the subject of
 IP_over_Foo drafts seems very reasonable to me. The 6lo WG can provide an
 addendum to the 6lowpan RFC to provide an algorithm that makes it possible
 that all mesh members learn the same 0x3 scope address, and enable the
 address. Although MPL forwarders need to forward the message, the
 destinations are not necessarily MPL forwarders. Identifying the MC
 address with the PAN-ID (given the PAN-ID does not change in spite of
 coordinator failures) of the mesh seems logical for IEEE802.15.4.




 Sending a multicast to all members to a heterogeneous multi-link network
 looks like a different problem to me.


 Hope this may help."

-- 
---------------------------------------+------------------------------
 Reporter:  [e-mail]  |       Owner:  [e-mail]
     Type:  defect                     |      Status:  reopened
 Priority:  major                      |   Milestone:
Component:  trickle-mcast              |     Version:
 Severity:  In WG Last Call            |  Resolution:
 Keywords:                             |
---------------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:10>
roll <http://tools.ietf.org/wg/roll/>