Subject: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00

From: Mukul Goyal <[email-masked]>
Date: Wed, 28 Apr 2010 12:46:26 -0500 (CDT)

Hi all

The following draft has been submitted for WG's consideration. It describes the additional mechanisms required to support P2P routing in LLNs. The draft first provides a high level description of the mechanisms and then proposes one way of realizing these mechanisms in RPL.

Regards
Mukul

----- Forwarded Message -----
From: "IETF I-D Submission Tool" <[email-masked]>
To: [email-masked]
Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada Central
Subject: New Version Notification for draft-dt-roll-p2p-rpl-00 

A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository.

Filename:	 draft-dt-roll-p2p-rpl
Revision:	 00
Title:		 Mechanisms to Support Point-to-Point Routing in Low Power and Lossy Networks
Creation_date:	 2010-04-28
WG ID:		 Independent Submission
Number_of_pages: 13

Abstract:
This draft presents mechanisms to determine the end-to-end cost of an
existing route and to discover/establish "on demand" one or more
routes between two nodes in a low power and lossy network.  This
draft also proposes functionality that would enable RPL to provide
these P2P mechanisms.

The IETF Secretariat.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 28 Apr 2010 20:17:16 +0200

Thanks Mukul. Just a minor point to avoid confusion for the WG, there  
is no P2P Design Team.

Thanks.

JP.

On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote:

> Hi all
>
> The following draft has been submitted for WG's consideration. It  
> describes the additional mechanisms required to support P2P routing  
> in LLNs. The draft first provides a high level description of the  
> mechanisms and then proposes one way of realizing these mechanisms  
> in RPL.
>
> Regards
> Mukul
>
> A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been  
> successfully submitted by Mukul Goyal and posted to the IETF  
> repository.
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Wed, 28 Apr 2010 21:13:21 +0200

Hi Charles,

On Apr 28, 2010, at 8:39 PM, Charles E. Perkins wrote:

>
> Hello JP,
>
> I think that the members of the discussion team
> do qualify as a "design team".  However, it is true
> that the design team was not an official design
> team appointed by directive of the working group.
>
> Instead, it was an independently organized design
> team.  The document doesn't claim that the design
> team has any special working group status.
>

As I said, this was a minor point, I just wanted to clarify that this
was not an official WG DT.

> Nevertheless, the working group may find the
> results to be of significant value.
>

Sure, thanks for the work.

Cheers.

JP.

> Regards,
> Charlie P.
>
>
> On 4/28/2010 11:17 AM, JP Vasseur wrote:
>> Thanks Mukul. Just a minor point to avoid confusion for the WG,  
>> there is
>> no P2P Design Team.
>>
>> Thanks.
>>
>> JP.
>>
>>> describes the additional mechanisms required to support P2P  
>>> routing in
>>> LLNs. The draft first provides a high level description of the
>>> in
>>> RPL.

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 28 Apr 2010 14:36:59 -0500 (CDT)

Hi JP,

My mistake. I forgot to make it clear - the P2P team listed in the draft does not have an official sanction. 

Thanks
Mukul

----- Original Message -----
From: "JP Vasseur" <[email-masked]>
To: [email-masked]
Cc: "Mukul Goyal" <[email-masked]>, "roll" <[email-masked]>
Sent: Wednesday, April 28, 2010 2:13:21 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00

Hi Charles,

Cheers.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 28 Apr 2010 21:38:10 +0200

again not a pb, just a minor clarification.

Looking forward to discussion on this important topic.

Cheers.

JP.

On Apr 28, 2010, at 9:36 PM, Mukul Goyal wrote:

> Hi JP,
>
> My mistake. I forgot to make it clear - the P2P team listed in the  
> draft does not have an official sanction.
>
> Thanks
> Mukul
>

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 29 Apr 2010 13:41:52 +0200

Hi,

I have found a few editorials and then a single question
to section 3.2:

The text says
"If node A had requested the discovery of a backwards (i.e. from B
to A) source-route, node B simply caches the route."

But is this true?
I would expect that some acknowledgement is needed. In an RF environment
there is a fair chance of dropping the packet somewhere along the way...
Without acknowledgements, node A would not know if it should try again -

or mark node B as unreachable (?).

Thanks,
  Anders

> -----Original Message-----
> From: Mukul Goyal [mailto:[email-masked]] 
> Sent: Wednesday, April 28, 2010 19:46
> To: roll
> Cc: Anders Brandt; robert cragie; Emmanuel; Jerald P 
> Martocci; charliep; Richard Kelsey
> Subject: Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00
> 
> Hi all
> 
> The following draft has been submitted for WG's 
> consideration. It describes the additional mechanisms 
> required to support P2P routing in LLNs. The draft first 
> provides a high level description of the mechanisms and then 
> proposes one way of realizing these mechanisms in RPL.
> 
> Regards
> Mukul
> 
> This draft presents mechanisms to determine the end-to-end 
> cost of an existing route and to discover/establish "on 
> demand" one or more routes between two nodes in a low power 
> and lossy network.  This draft also proposes functionality 
> that would enable RPL to provide these P2P mechanisms.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
> 
>

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 29 Apr 2010 07:36:32 -0500 (CDT)

Hi Anders

Good catch! This makes sense. I guess, in this case, B still needs to send a Discovery Reply message to node A acking the receipt of a "good enough" route. The Discovery Reply message would otherwise be empty. It should also be possible for node B to "aggregate" such Ack messages for each discovered route together. In other words, B should be able to send a "cumulative ack" to A saying it now has the desired number of "good enough" routes (to A), rather than acking the discovery of each such route separately.   

Thanks
Mukul

----- Original Message -----
From: "Anders Brandt" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, "roll" <[email-masked]>
Sent: Thursday, April 29, 2010 6:41:52 AM GMT -06:00 US/Canada Central
Subject: draft-dt-roll-p2p-rpl-00: Discovery of backwards source route

Hi,

The text says

But is this true?

Thanks,
  Anders

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Apr 2010 11:39:42 -0700

Hello JP,

Regards,
Charlie P.

On 4/28/2010 11:17 AM, JP Vasseur wrote:
> Thanks Mukul. Just a minor point to avoid confusion for the WG, there is
> no P2P Design Team.
>
> Thanks.
>
> JP.
>
>> describes the additional mechanisms required to support P2P routing in
>> mechanisms and then proposes one way of realizing these mechanisms in
>> RPL.
>>
>> Regards
>> Mukul

---

From: Philip Levis <[email-masked]>
Date: Thu, 29 Apr 2010 09:55:16 -0700

> team appointed by directive of the working group.

Sure -- so please try to use clear, rather than confusing, terminology. I, for example, could think that the group of us working on trickle do qualify as a "working group" in that we are a group that is working. But using such a term would hardly be considered helpful.

Phil

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Thu, 29 Apr 2010 14:48:30 -0400

Hi all!

Great to see that things are actually moving on with the point to point discussions and I think this draft is a nice in the sense that we are trying to focus on this topic :)

One confusion as I read through the draft is where the authors say in 4.1 and 4.7 that 'DIOs' can be used for discovery messages and suddenly, 4.3 indicates that DAOs are needed in some cases to support the Rout Stack option. Not that its impossible, it would be more than overwhelming to deal with both DAOs and DIOs for discovery :) 

Overall it looks like a nice high level description of what 'should/could/can/may' happen (although I thought the discussion on loose source routing was over with) but we would need to tie it harder with RPL itself. Just my 2 cents ;)

Thanks.

-John

> draft also proposes functionality that would enable RPL to provide

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 29 Apr 2010 14:02:55 -0500 (CDT)

Hi John

>One confusion as I read through the draft is where the authors say in 4.1 and 4.7 that 'DIOs' can be used for discovery messages and suddenly, 4.3 indicates that DAOs are needed in some cases to sup…

No. The draft merely points out that RPL-07 allows only a DAO to carry the Route Stack option. To support the P2P mechanisms described in the draft, RPL should allow Measurement Request and Discovery messages to carry the Route Stack option as well.

>Overall it looks like a nice high level description of what 'should/could/can/may' happen (although I thought the discussion on loose source routing was over with) but we would need to tie it harder…

Regarding loose source routing, there are good reasons to ditch it for DAG-based routing. But there are no reasons why it can not be supported for the route discovery mechanism described in the draft. Loose source routes are useful and should be supported if there are no major technical difficulties in doing so. 

Thanks
Mukul

------
JeongGil Ko (John)
Ph.D. Student

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 29 Apr 2010 14:07:45 -0500 (CDT)

Just to clarify further, the route discovery mechanism described in the draft do not prescribe any use of DAOs although when you think about it, a DAO MAY serve as the Discovery Reply message. The difference is that a DAO is restricted to travel along the DAG where as we (the draft's authors) have allowed the Discovery Reply message to travel along any route if it merely carries a source-route back to the originator of route discovery.

Regards
Mukul
   
----- Original Message -----
From: "Mukul Goyal" <[email-masked]>
To: "JeongGil Ko (John)" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Sent: Thursday, April 29, 2010 2:02:55 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00

Hi John

Thanks
Mukul

------
JeongGil Ko (John)
Ph.D. Student

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Thu, 29 Apr 2010 15:07:51 -0400

Hi Mukul

> No. The draft merely points out that RPL-07 allows only a DAO to carry the Route Stack option. To support the P2P mechanisms described in the draft, RPL should allow Measurement Request and Discove…

It would be nice if what you just said above was explicitly mentioned in 4.3 to avoid misunderstandings.

- John

------
JeongGil Ko (John)
Ph.D. Student

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 29 Apr 2010 14:11:19 -0500 (CDT)

Hi John

I will change the language of Section 4.3 as you suggested.

cheers
Mukul

----- Original Message -----
From: "JeongGil Ko (John)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Sent: Thursday, April 29, 2010 2:07:51 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00

Hi Mukul

- John

------
JeongGil Ko (John)
Ph.D. Student

---

From: Robert Cragie <[email-masked]>
Date: Thu, 29 Apr 2010 20:16:21 +0100

Please refer to http://tools.ietf.org/html/rfc1603#page-19 for the 
definitive answer. Can we now carry on with the real analysis and 
feedback on the P2P proposal?

FWIW my personal interpretation is that Charlie is right. Working groups 
seem to be much more formal.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 29 Apr 2010 22:55:25 +0200

"design team" is a rather loose term in the IETF -- contrary to "working
group".

Anyways, let's focus on discussing the content rather than on administrative
terminology ;)

Emmanuel

On Thu, Apr 29, 2010 at 6:55 PM, Philip Levis <[email-masked]> wrote:

> Sure -- so please try to use clear, rather than confusing, terminology. I,
> for example, could think that the group of us working on trickle do qualify
> as a "working group" in that we are a group that is working. But using such
> a term would hardly be considered helpful.
>
> Phil