Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00

From: Mukul Goyal <[email-masked]>
Date: Mon, 31 May 2010 03:23:25 -0500 (CDT)

Hi Jonathan

>From section 3 in the draft:
"When
   processing the Type 4 Routing header, a router MUST drop the packet
   if the next entry is not a neighboring node and SHOULD send an ICMP
   Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set
   to 7 (to be confirmed by IANA) to the packet's Source Address."

I don't think even a storing node would always know if a particular address is not a neighbor. Highly constrained nodes (storing or non-storing) may have very small neighbor table or no neighbor table at all, so they are very likely to not know. I think that the text quoted above should be removed from the draft. 

Thanks
Mukul

----- Original Message -----
From: "Jonathan Hui" <[email-masked]>
To: "Yoav Ben-Yehezkel" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Sent: Thursday, May 27, 2010 11:56:35 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00

On May 27, 2010, at 9:47 AM, Yoav Ben-Yehezkel wrote:

> Two small questions/comments about the following text (on page 6)
>
> else if Address[i] is not an neighboring node {
>              send an ICMP Destination Unreachable, Code 3, message to
>              the Source Address and discard the packet
>
> 1) How does a non-storing device knows Address[i] is not an  
> neighboring
> node? It is non storing...

Non-storing means that it doesn't store routes for the destination.  A  
node presumably needs to maintain some notion of neighbors, whether  
that's through ND or something similar.  At the very least, a node  
could try forwarding the datagram and if it fails then it could  
indicate that it is not a neighbor.

> 2) Code 3 - should be Code 7?

Yes, you are right.  We originally had Code 3, but through creating a  
new code would be more appropriate.

> also consider changing header from: "RPL Routing Header" to: "Source
> Routing Header for RPL"

To be completely descriptive, maybe something like "An IPv6 Routing  
Header for Source Routing with RPL".  We are describing a new IPv6  
Routing type after all.

--
Jonathan Hui

>
> Best Regards,
> Yoav
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of
> Jonathan Hui
> Sent: Thursday, May 27, 2010 7:21 PM
> To: ROLL WG
> Subject: [Roll] Fwd: New Version Notification for
> draft-hui-6man-rpl-routing-header-00
>
>
> To address RPL ticket #35, we submitted a draft to 6man that proposes
> a new IPv6 routing header to support source routing in non-storing  
> mode.
>
> Some high-level details:
> - Format is derived from RH0
> - Format is extended to support simple compression of IPv6 address
> entries within the routing header
> - Use of the RPL routing header is constrained to a RPL domain.
>
> http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00
>
> Comments appreciated as always.
>
> --
> Jonathan Hui
>
> Begin forwarded message:
>
>> From: IETF I-D Submission Tool <[email-masked]>
>> Date: May 26, 2010 11:41:21 AM PDT
>> To: [email-masked]
>> Cc: [email-masked],[email-masked]
>> Subject: New Version Notification for  draft-hui-6man-rpl-routing-
>> header-00
>>
>>
>> A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has
>> been successfully submitted by Jonathan Hui and posted to the IETF
>> repository.
>>
>> Filename:	 draft-hui-6man-rpl-routing-header
>> Revision:	 00
>> Title:		 A Source Routing Header for RPL
>> Creation_date:	 2010-05-26
>> WG ID:		 Independent Submission
>> Number_of_pages: 13
>>
>> Abstract:
>> In Low power and Lossy Networks (LLNs), memory constraints on routers
>> may limit them to maintaining at most a few routes.  In some
>> configurations, it is necessary to use these memory constrained
>> routers to deliver datagrams to nodes within the LLN.  The Routing
>> for Low Power and Lossy Networks (RPL) protocol can be used in some
>> deployments to store most, if not all, routes on one (e.g. the
>> Directed Acyclic Graph (DAG) root) or few routers and forward the
>> IPv6 datagram using a source routing technique to avoid large routing
>> tables on memory constrained routers.  This document specifies a new
>> IPv6 Routing header type for delivering datagrams within a RPL
>> domain.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

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

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 31 May 2010 13:42:05 +0200

Mukul, Jonahan,

I agree on this one:

> I don't think even a storing node would always know if a 
> particular address is not a neighbor. Highly constrained 
> nodes (storing or non-storing) may have very small neighbor 
> table or no neighbor table at all, so they are very likely to 
> not know.

It is unlikely that most constrained nodes will have storage for
this.

Therefore this may be the most sensible thing to do:

>  At the very least, a node could try forwarding the datagram 
> and if it fails then it could indicate that it is not a neighbor.

In essence, reverse the routing stack pointer direction and send
a NUD back to the source (possibly after a number of retries).

- Anders

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mukul Goyal
> Sent: Monday, May 31, 2010 10:23
> To: Jonathan Hui
> Cc: ROLL WG
> Subject: Re: [Roll] Fwd: New Version Notification 
> fordraft-hui-6man-rpl-routing-header-00
> 
> Hi Jonathan
> 
> I don't think even a storing node would always know if a 
> particular address is not a neighbor. Highly constrained 
> nodes (storing or non-storing) may have very small neighbor 
> table or no neighbor table at all, so they are very likely to 
> not know. I think that the text quoted above should be 
> removed from the draft. 
> 
> Thanks
> Mukul
> 
> > neighboring node? It is non storing...
> 
> Non-storing means that it doesn't store routes for the 
> destination.  A node presumably needs to maintain some notion 
> of neighbors, whether that's through ND or something similar. 
>  At the very least, a node could try forwarding the datagram 
> and if it fails then it could indicate that it is not a neighbor.
> 
> Yes, you are right.  We originally had Code 3, but through 
> creating a new code would be more appropriate.
> 
> To be completely descriptive, maybe something like "An IPv6 
> Routing Header for Source Routing with RPL".  We are 
> describing a new IPv6 Routing type after all.
> 
> --
> Jonathan Hui
> 
> >
> > Best Regards,
> > Yoav
> >
> > Of Jonathan Hui

---

From: Philip Levis <[email-masked]>
Date: Mon, 31 May 2010 13:45:05 -0700

> I don't think even a storing node would always know if a particular address is not a neighbor. Highly constrained nodes (storing or non-storing) may have very small neighbor table or no neighbor ta…

I'll return to my comment on this line of argument -- it seems to be introducing a new requirement which doesn't exist in any of the requirement documents: a node must be able to route without a neighbor table. If this is truly a requirement, rather than a convincing argument for a particular approach, then we need to re-examine the requirements documents and several parts of RPL. Do we?

Phil