Subject: [Roll] trickle-mcast-05 - Need to explain role of Hop Limit field in Data Messages?

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 5 Sep 2013 10:40:53 +0000

Dear all,

reviewing the new trickle-mcast-05 draft, I wondered if there is a need to explain a little more about the role/value of the Hop Limit field to be used in MPL Data Messages.

Section 4 states delivery to *all* interfaces:
  The goal of MPL is to deliver multicast messages to all interfaces
   that subscribe to the multicast messages' destination address within
   an MPL Domain.

I assume this can only be achieved with Hop Limit set sufficiently high (*) by the Seed in a newly generated Data Message. However, how to set Hop Limit is not mentioned for Data Messages (only for Control Messages). So do we need mention setting Hop Limit "high enough" for the specific MPL Domain? Also I assume that by setting Hop Limit to a low value the effect can be achieved that an MPL Data Message is only disseminated to a subset of an MPL Domain.

For me the reason to bring this up is that dealing with Hop Limit seems not a trivial matter (considering e.g. the extensive prior discussion and diagrams http://www.ietf.org/mail-archive/web/roll/current/msg07552.html)

best regards,

Esko

(*) assuming the Hop Limit field in the (outer, non-encapsulated) IPv6 header is decremented by each successive MPL Forwarder

________________________________
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: Michael Richardson <[email-masked]>
Date: Thu, 05 Sep 2013 08:49:16 -0400

> I assume this can only be achieved with Hop Limit set sufficiently high
    > (*) by the Seed in a newly generated Data Message. However, how to set
    > Hop Limit is not mentioned for Data Messages (only for Control

Given that the MPL document can not predict the maximum rank of a deployed
topology, whereas the applicability statements authors *can*, would it make
sense to include a "Hop Limit range" question into the applicability
statement for deployments that use MPL?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 5 Sep 2013 13:17:53 +0000

> Given that the MPL document can not predict the maximum rank of a deployed topology, whereas the applicability statements authors *can*, would it make sense to include a "Hop Limit range"
> question into the applicability statement for deployments that use MPL?

Yes, I think so. It can also be advised to choose Hop Limit by default as high as possible (255) to ensure propagation of the message throughout the MPL domain. Lower Hop Limit values can then still be specified, but would need good arguments in the applicability statement why that is necessary/beneficial.

The fact that Hop Limit can be chosen/tuned should be mentioned though in the MPL I-D.

Esko

---

From: Robert Cragie <[email-masked]>
Date: Thu, 05 Sep 2013 17:21:47 +0100

I would suggest what might be appropriate is to leave the draft as is 
but to consider drafting a template or specific applicability statement 
for MPL, which will make it clear what needs to be in an applicability 
statement.

Robert

On 05/09/2013 14:17, Dijk, Esko wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Sun, 8 Sep 2013 12:15:37 +0000

That seems to be a perfectly fine idea indeed.

On Sep 5, 2013, at 6:21 PM, Robert Cragie <[email-masked]> wrote:

> I would suggest what might be appropriate is to leave the draft as is but to consider drafting a template or specific applicability statement for MPL, which will make it clear what needs to be in an applicability statement.
> 
> Robert
>

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 10 Sep 2013 11:46:22 +0000

That's ok for me -  MPL and P2P-RPL are currently targeted to be in the ROLL applicability statements.
(See Michael's statement http://www.ietf.org/mail-archive/web/roll/current/msg07816.html ; and practical use example in http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-01#section-4.3.3 )

The template could still be updated to reflect MPL and P2P-RPL; however the main action is to include a hop limit consideration into draft-ietf-roll-applicability-home-building, right?

Esko

---

From: peter van der Stok <[email-masked]>
Date: Tue, 10 Sep 2013 14:24:09 +0200

HI Esko,

A statement about the applicability of hop limit will be put in 
home-building-01. This will be dome in relation to the existence of the 
MPL domain which often limits the transmission (reception) of the MPL 
messages.

Peter

Dijk, Esko schreef op 2013-09-10 13:46:
> (See Michael's statement
> http://www.ietf.org/mail-archive/web/roll/current/msg07816.html ; and
> practical use example in
> http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-01#section-4.3.3
> )
> 
> The template could still be updated to reflect MPL and P2P-RPL;
> however the main action is to include a hop limit consideration into
> draft-ietf-roll-applicability-home-building, right?
> 
> Esko
> 
> Given that the MPL document can not predict the maximum rank of a 
> deployed topology, whereas the applicability statements authors *can*, 
> would it make sense to include a "Hop Limit range"
> Yes, I think so. It can also be advised to choose Hop Limit by default 
> as high as possible (255) to ensure propagation of the message 
> throughout the MPL domain. Lower Hop Limit values can then still be 
> specified, but would need good arguments in the applicability statement 
> why that is necessary/beneficial.
> 
> 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: Michael Richardson <[email-masked]>
Date: Tue, 17 Sep 2013 11:44:11 -0400

Dijk, Esko <[email-masked]> wrote:
    > That's ok for me - MPL and P2P-RPL are currently targeted to be in the
    > ROLL applicability statements.  (See Michael's statement

    > The template could still be updated to reflect MPL and P2P-RPL; however
    > the main action is to include a hop limit consideration into

The template is updated with some questions.
Getting something concrete into home-building is the goal.

Would it be useful to go through the applicability statements in Vancouver,
addressing how well each document deals with the questions?  We would do this
section/question by question, across all the documents at the same time.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/