Zach,
I would prefer not to use the WGLC as a forcing function to get folks to
really read and think about this document. I hope that this discussion will
cause everyone to re-read the draft and think about the issues that are
being brought up and get this discussed on the list.
I think that these are extremely important issues and concerns raised by
some. As I have said, I'm not opposed to the ND optimizations. I would
like to see them as optional optimizations such that if I'm building a very
simple embedded network and I want the smallest least cost seamless solution
then I'm not required to implement these ND optimizations and whiteboards,
but could choose to interact with a completely standard RFC4861 ND router.
For those networks such as ISA100 that have designs/architectures and
requirements for the features of these optimizations then they can and
should use 6lowpan ND.
geoff
On Mon, Oct 12, 2009 at 2:09 PM, Zach Shelby <[email protected]> wrote:
>
> On Oct 12, 2009, at 23:01 , Jonathan Hui wrote:
>
>> On Oct 12, 2009, at 12:01 PM, JP Vasseur wrote:
>>
>>>
>>> On Oct 12, 2009, at 6:50 PM, Colin O'Flynn wrote:
>>>
>>> Hello Adam,
>>>>
>>>> Also, one specific question: how would an IPv6 host deal with an
>>>>> 802.15.4 network interface if the IPv6 adaptation layer would require
>>>>> changes to the core of the IPv6 stack to function properly?
>>>>>
>>>>
>>>> Having a router in between seems sensible to me. You can get uIPv6
>>>> somewhere
>>>> small, so I don't see having a simple router as a big problem...
>>>>
>>>
>>> I do not think that the issue is the code size itself but a change in the
>>> architecture, thus
>>> the reasonable question on whether we could find a simpler approach
>>> compatible with
>>> 4861 to handle the case of non transitive links that preserves the
>>> architecture.
>>>
>>
>> I do agree that we have to be very careful with the architectural
>> implications. For me, it's not about whether or not we require an extra
>> router in between or some extra code. It's more about making sure we are OK
>> with the proposed simplifications changing the semantics of ND operations
>> defined (explicitly or implicitly) by RFC 4861. Some examples that come to
>> mind:
>>
>>
> Yep, and this is why people need to read and comment on the draft. I like
> this approach.
>
> 1) Assuming that link-layer addresses can always be computed from IIDs.
>> While this assumption can remove the need for NS/NA for address resolution,
>> the implication is that the IIDs are limited to the link-layer addresses in
>> use. 802.15.4 radio hardware is typically limited to one short and one
>> extended address at a time and that limits the number and structure of IIDs
>> that can be assigned at any time.
>>
>>
> Actually this is not true anymore in nd-06. Based on feedback in Stockholm,
> we relaxed the IID-MAC mapping assumption. If you have a LoWPAN that for
> some reasons assigns an IID that requires address resolution, this can be
> performed on the host-router interface.
>
> 2) Using NR/NC exchanges to provide NUD. With the current draft, NR/NC
>> exchanges only maintain reachability information for the link-local address
>> of the attachment router. However, NR/NC exchanges, as defined, cannot
>> provide reachability information for global addresses. Additionally, NR/NC
>> messages cannot be used to maintain reachability information for neighboring
>> hosts (not routers).
>>
>>
> Good example. If this is really a problem we can look at ways to improve
> that of course. I don't follow you on why they can't provide reachability
> info for global addresses (from Address Options) - but let's talk about that
> separately.
>
> I'm not convinced that these are the only examples that we need to be
>> aware of with the existing draft. I'm also not convinced that enough people
>> have weighed in on the examples above to say that such implications are OK
>>
>
> This is exactly what last call is for ;-) Forcing everyone to actually read
> the thing again, and to make constructive comments.
>
> Zach
>
>
>> --
>> Jonathan Hui
>>
>> _______________________________________________
>> 6lowpan mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/6lowpan
>>
>
> --
> http://www.sensinode.com
> http://zachshelby.org - My blog “On the Internet of Things”
> Mobile: +358 40 7796297
>
> Zach Shelby
> Head of Research
> Sensinode Ltd.
> Kidekuja 2
> 88610 Vuokatti, FINLAND
>
> This e-mail and all attached material are confidential and may contain
> legally privileged information. If you are not the intended recipient,
> please contact the sender and delete the e-mail from your system without
> producing, distributing or retaining copies thereof.
>
>
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
