Re: [6lowpan] Fwd: New Version Notification fordraft-chakrabarti-6lowpan-ipv6-nd-simple-00

["Mathilde Durvy (mdurvy)" <[e-mail]>]

Hi Samita, Erik, 

Thanks a lot for you answers, it helps! I think these are the kind of things
you might want to include in the next version although I think the current
text is already very good.

I agree we should keed ND independent from the routing protocol. I guess my
comment was only that if the routing protocol happens to duplicate some of
the functionalities provided by ND maybe these should become optional to
avoid wasted resources...

Best,
Mathilde 

-----Original Message-----
From: Samita Chakrabarti [mailto:[e-mail]] 
Sent: mercredi, 24. mars 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: Erik Nordmark; 6lowpan
Subject: Re: [6lowpan] Fwd: New Version Notification
fordraft-chakrabarti-6lowpan-ipv6-nd-simple-00

Hi Mathilde,

Thanks for your comments.  Here are some more  responses in addition to
Erik's and Pascal's.
Please see in-line.

On Mon, Mar 22, 2010 at 10:45 AM, Mathilde Durvy (mdurvy) <[e-mail]>
wrote:
> Hi Erik, Samita,
>
> Thanks for your draft. This proposal is much closer to what I had in 
> mind myself and I feel this is a great step forward!
>

Great to hear that from you!

> I have a few questions / comments:
> - Assumptions: why do you assume that 6LR use RA to configure their 
> global addresses while host are allowed to use DHCPv6? In IPv6, 
> routers are typically ignoring received RAs... It is not very clear 
> whether your proposal allows the case where all addresses (host and 
> 6LR) are assigned using DHCPv6. It might also be that in a route-over 
> situation the routing protocol itself would take care of distributing 
> well chosen prefixes/addresses to allow prefix aggregation in routing 
> tables or routing messages.

6LRs are assumed to be dual personalities. In most cases they are acting as
a routers. But indeed they are special as they form global addresses from
prefixes through autoconfiguration and they can also send RS to their
neighbors as they come up.

As for DHCPv6-pd, nd-simple does not do DHCP prefix delegation. It simply
relays the prefixes to neighbors since the 6lowpan contains same prefix
throughut. Multiple prefixes are possible - but they are same throughout the
6lowpan.

This draft however does not discuss DHCPv6 address assignment and it is left
to a separate draft. nd-simple only discusses address autoconfiguration.

If DHCPv6 relay/server is used then all addresses could be assigned by the
DHCP server when the DHCP-server would know that it has to use the same
prefix for all addresses over a 6lowpan.  It is not written in the draft and
we think the DHCP-related draft would cover that.

>> - Section 7.3: I feel like you are underestimating the role that the 
>> routing
> protocol might play. If you take the example of what RPL is defining, 
> an
> IPv6 host could very well be a RPL leaf node, in which case it might 
> discover its default router by listening to DIO messages, and send DAO 
> to 'register'. In addition, if the 6LR are RPL routers that use DHCPv6 
> or another scheme for address allocation, RS/RA might be completely
disabled.
> What do you think?

The same logic applies to regular IPv6 network. IPv6 ND cannot and should
not depend on a particular routing protocol behavior that is running on the
nodes.

Note that the concept of 6LoWPAN link(route-over) is a bit different than
regular IPv6-link.  Not all 6lowPAN networks will run RPL or routing
protocols and yet they need to communicate without static configuration.

> - Section 7.3: Reading your description, is it correct to say that 
> hosts perform NUD and address resolution for their default router? (of 
> course the number of messages is reduced by the heavy use of the SLLA 
> option). Do you also use NS/NA to perform NUD and address resolution
between 6LR?
> - Section 7.3: ND uses already upper-layer protocol feedback. Would 
> you consider to extend it to include lower layer feedback?
>
> To summarize my comments, I would like to understand a bit better how 
> you envision the operation of nd-simple when a routing protocol such 
> as RPL is used on top of it.
>

I'd think RPL will do p2mp, mp2p or p2p routing within a 6LoWPAN .
6LRs may act as hosts as well, as they have aquired their global prefixes.
6LRs will also know how to forward packets to 6LBRs when the destination
addresses are not resolved by RPL'ed routes.

Thanks,
-Samita

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Erik Nordmark
> Sent: lundi, 1. mars 2010 05:17
> To: 6lowpan
> Subject: [6lowpan] Fwd: New Version Notification 
> fordraft-chakrabarti-6lowpan-ipv6-nd-simple-00
>
>
> Samita and I have tried to capture a minimal set of ND optimizations 
> in this draft.
>
>    Erik
>
>
> -------- Original Message --------
>
> A new version of I-D, draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt
> has been successfuly submitted by Erik Nordmark and posted to the IETF 
> repository.
>
> Filename:        draft-chakrabarti-6lowpan-ipv6-nd-simple
> Revision:        00
> Title:           IPv6 LoWPAN Neighbor Discovery and Addressing Choices
> Creation_date:   2010-03-01
> WG ID:           Independent Submission
> Number_of_pages: 16
>
> Abstract:
> IETF 6LoWPAN working group defines IPv6 over low-power personal area 
> network (IEEE 802.15.4).  IEEE 802.15.4 and other low-power wireless 
> networks have limited or no usage of broadcast or multicast signaling 
> due to energy conservation.  Besides the wireless nodes may not 
> strictly follow traditional concept of IP subnet and IP-links while 
> connecting nodes and routers.  This document describes simple 
> optimizations to IPv6 Neighbor Discovery protocol(RFC4861), and 
> addressing mechanisms that are useful for small scale 6LoWPAN networks in
star and mesh topologies.
>
> The optimizations include reducing the amount of Neighbor Discovery 
> multicast traffic and allowing for a single subnet to span multiple 
> routers in a "route-over" topology.
>
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> 6lowpan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
> _______________________________________________
> 6lowpan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
>