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 22:37:14 -0500 (CDT)

Hi Philip

In this particular case, the intent is to require that a router MUST drop a packet if it can not deliver the packet to the next entry in the routing header in one IP hop. I think the authors will update the language to this effect.

In general and in context of P2P mechanisms, the requirement is to allow operation with highly constrained (in memory) devices. The neighbor table, in general, will contain only a subset of neighbors. There is no reason to not use neighbors not in neighbor table if the underlying routing metrics do not require maintenance of neighbor-specific state.

Thanks
Mukul

----- Original Message -----
From: "Philip Levis" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "Jonathan Hui" <[email-masked]>, "ROLL WG" <[email-masked]>
Sent: Monday, May 31, 2010 3:45:05 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00

On May 31, 2010, at 1:23 AM, Mukul Goyal wrote:

> 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. 

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

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 1 Jun 2010 08:55:33 +0200

Hi Phil 

Comment inline.

Cheers,
  Anders

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mukul Goyal
> Sent: Tuesday, June 01, 2010 05:37
> To: Philip Levis
> Cc: ROLL WG
> Subject: Re: [Roll] Fwd: New Version Notification 
> fordraft-hui-6man-rpl-routing-header-00
> 
> Hi Philip
> 
> In this particular case, the intent is to require that a 
> router MUST drop a packet if it can not deliver the packet to 
> the next entry in the routing header in one IP hop. I think 
> the authors will update the language to this effect.
> 
> In general and in context of P2P mechanisms, the requirement 
> is to allow operation with highly constrained (in memory) 
> devices. The neighbor table, in general, will contain only a 
> subset of neighbors. There is no reason to not use neighbors 
> not in neighbor table if the underlying routing metrics do 
> not require maintenance of neighbor-specific state.
> 
> Thanks
> Mukul
> 
> > 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. 
> 
> 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 

Agreed. The home requirements spec does not explicitly say that a
node MUST operate without a neighbor table. I would claim that this
somewhat has to do with scoping of our individual mindsets. Over
time I have found that Kris and Pascal has a different interpretation
of "memory constrained" than Jerry and me.

I want to support Mukul that at best, a home (or building) node may
hold link information on a few neighbors out of potentially 100's
in a dense network.
There is a reason we prefer source routing in this environment.

> 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
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>