Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments

From: Mukul Goyal <[email-masked]>
Date: Sat, 5 May 2012 12:18:03 -0500 (CDT)

> [Mukul2]
> You described two separate scenarios:
> 1) A has 15 neighbors, B has just A as the neighbor.
> 2) Both A and B have 15 neighbors including each other.
>
> In the second scenario, K=1 definitely makes sense because there are many candidate paths and one such path to B would probably be discovered even though many of B's neighbors would end up suppressing their DIOs. It is possible that the discovered route wont pass through A.
[Federico3]
I think this is the problem, the fact that the node B does not have full 
information about the status of his neighborhood. In the second scenario 
node B will use a path almost certainly worse to reach a neighbor of the 
node A.

[Mukul3]
IMHO, there is no problem. There is no need for B to know the route through each neighbor. All it needs to know is one path that meets the constraints specified by the origin. The need to avoid too many DIO transmissions is critical and K in default configuration option is set to reflect this priority.

Thanks
Mukul

---

From: Federico Consoli <[email-masked]>
Date: Sat, 05 May 2012 19:27:27 +0200

> IMHO, there is no problem. There is no need for B to know the route through each neighbor. All it needs to know is one path that meets the constraints specified by the origin. The need to avoid too…
[Federico4]
Yes but the information about the route through each neighbor is very 
important for the objective function.

> Thanks
> Mukul
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

-- 
Regards
Consoli Federico

---

From: Mukul Goyal <[email-masked]>
Date: Sat, 5 May 2012 12:44:09 -0500 (CDT)

I have no further comment to make. I think we disgree on this point.

Thanks
Mukul
----- Original Message -----
From: "Federico Consoli" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: [email-masked]
Sent: Saturday, May 5, 2012 12:27:27 PM
Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments

[Federico4]

-- 
Regards
Consoli Federico

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 6 May 2012 01:14:37 +0100

Hi,

Can I make a suggestion?

draft-ietf-roll-p2p-rpl is targeted at publication as an Experimental.

Could you enhance the text around the suggested defaults and the guidance to
expand a little on what the problems might be, and encourage specific
experimentation and reports back to the WG?

Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mukul
> Goyal
> Sent: 05 May 2012 18:44
> To: Federico Consoli
> Cc: [email-masked]
> >> In the second scenario, K=1 definitely makes sense because there are many
> candidate paths and one such path to B would probably be discovered even
> though many of B's neighbors would end up suppressing their DIOs. It is
possible
> that the discovered route wont pass through A.
> > [Federico3]
> > IMHO, there is no problem. There is no need for B to know the route through
> each neighbor. All it needs to know is one path that meets the constraints
> specified by the origin. The need to avoid too many DIO transmissions is
critical
> and K in default configuration option is set to reflect this priority.
> [Federico4]

---

From: Mukul Goyal <[email-masked]>
Date: Sat, 5 May 2012 20:33:58 -0500 (CDT)

Sure I will do that.

Thanks
Mukul

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, "Federico Consoli" <[email-masked]>
Cc: [email-masked]
Sent: Saturday, May 5, 2012 7:14:37 PM
Subject: RE: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments

Hi,

Can I make a suggestion?

Adrian

possible
critical

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 May 2012 15:28:22 -0400

adrian> Could you enhance the text around the suggested defaults and
    adrian> the guidance to expand a little on what the problems might
    adrian> be, and encourage specific experimentation and reports back
    adrian> to the WG? 

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> Sure I will do that.

I believe we are talking about section 6.1 and 9.2, correct?

My suggestion is that the "controversial" values like this SHOULD be
identified more clearly with text akin to:
     Specific consideration of this value MUST be addressed
     in applicability statement(s).

(I'd even like to put some kind of 2119-like word in about this)

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 7 May 2012 04:50:37 -0500 (CDT)

Hi Michael

>(I'd even like to put some kind of 2119-like word in about this)

You mean to say that P2P-RPL draft should require the home/building/whomsoever_cares_to_use_p2p_rpl applicability statement to address how to set P2P-RPL trickle parameters?

Thanks
Mukul

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 May 2012 09:48:14 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> Hi Michael

    >> Specific consideration of this value MUST be addressed
    Mukul> in applicability statement(s).
    >> (I'd even like to put some kind of 2119-like word in about this)

    Mukul> You mean to say that P2P-RPL draft should require the
    Mukul> home/building/whomsoever_cares_to_use_p2p_rpl applicability
    Mukul> statement to address how to set P2P-RPL trickle parameters? 

Yes, exactly.
There could be a template in the document which must be filled in.

Text something like:

  Applicability Statements that specify P2P-RPL MUST provide values for
  the following parameters: X, Y, Z.  

  Considerations for setting X.
  Considerations for setting Y.
  Considerations for setting Z.

  For example:
     The FOOBAR application scenario is a dense mesh needing fast
     repair times and having routing nodes without power limits.  
     Therefore:
     1) the X value SHOULD be set between a and b.
     2) the Y value SHOULD be no greater than c.
     3) the Z value setting is not critical.

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

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 8 May 2012 11:21:58 -0500 (CDT)

Hi Michael

>  the following parameters: X, Y, Z.  

I will add the following sentence:

Applicability Statements that specify the use of P2P-RPL MUST provide guidance for setting trickle parameters, particularly Imin and the Redundancy Constant.   

Thanks
Mukul

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
To: [email-masked]
Cc: [email-masked], "Mukul Goyal" <[email-masked]>
Sent: Monday, May 7, 2012 8:48:14 AM
Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments

    Mukul> Hi Michael

Yes, exactly.

Text something like:

  For example:

- --