Samita,
Thanks for the review. Here are a few clarifications. I integrated
some of your questions into tomorrow's presentation, so just in time.
On Nov 9, 2009, at 19:35 , Samita Chakrabarti wrote:
Here are some comments on nd-07:
1.Document refers to "Classic ND" which brings up some questions in
mind - should not it be "Standard ND" ?
Classic makes more sense. There is no "Standard ND" as it is a link
protocol, and there can be multiple ones. For me either works - heck,
we can reference RFC4861 each time even...
2. Section 1.1 [ Goals, Assumptions and Guesses]
I believe, 6lowpan-nd is a standard track doucment; we cannot
specify guesses here. If there are some "guesses" or unconfirmed
assumptions they should go to the appendix.
True, "guesses" is probably not the best word. They could be included
as assumptions with softer wording. Good comment.
The following should be an assumption:
Link-local IPv6 addresses are derived from a unique identifier
(e.g. EUI-64) corresponding to a link-layer address.
I also agree. But there was a list comment claiming that you shouldn't
even assume this. 6lowpan-nd will still work even if this is not true.
So an assumption with softer wording would be enough, if this text is
needed at all.
3. Section 2.1 (Terminology)
a) The terms link and link-local are still unclear; we need to work
on them to provide a clear picture.
OK, any ideas there are welcome.
b) Route-over definition - especially the last sentence is
confusing. A natural question comes to the mind:
i,e: how is IP-routing and Route-over related. This definition
can be simplified.
They are the same thing. A LoWPAN in which you use IP routing is Route
Over (and vice-versa). You could even get rid of Mesh Under and Route
Over completely, as this works with both. The only difference is you
have routers if you do IP routing (which is pretty obvious).
4. Subnet : This is a new definition of subnet where multiple hops can
be taken from one node to another in a 6lowpan-subnet in route-over
configuration. It might be better to name it differently - say
6lowpan-subnet.
Sure, it has been called LoWPAN Subnet in the past. That works too.
"This specification is REQUIRED for LoWPAN
operation, but MAY also coexist with [RFC4861], [RFC3122] or other
future ND mechanisms. Any use of [RFC4944] without this
specification is NOT RECOMMENDED."
=====> Why is this specification is "REQUIRED" for LowPAN operation?
Some explanation is needed.
All interfaces on a link must run the same ND, as it is a link
protocol. 6lowpan-nd is an ND mechanism that ensures all interfaces on
a LoWPAN are compatible. It is sufficient to make the LoWPAN work on
its own.
Co-existance with RFC4861 (or any other ND specification) means that
you could use RFC4861 in addition to 6lowpan-nd if you have the need
for NS/NA. You are not required to use RFC4861. We are dealing with
constrained nodes here, it would make no sense to run RFC4861 in all
cases.
We did achieve a kind of interop in the way that a node running
6lowpan-nd only, and one running 6lowpan-nd+RFC4861 are compatible.
Section 4.3 indicates that RA would use the same ICMP type as RFC4861,
but it can (should?) use additional options such as 6AO, 6IO, Summary
option or regular Prefix Information option.
It seems a little complex if all these options are needed and how they
are handled by nodes, lowpan-routers and Edge-routers. There are
cases, when we may only need a mandatory option in a LowPAN network
and then there are cases when we can use all of them.
Compatibility with RA messages coming from e.g. unmodified radvd was
requested during the latest list discussions. This is the reason we
also support the processing of Prefix Information options.
The 6AO is not used with RAs, only the 6SO and 6IO are used.
We will of course clarify the text, but in summary all of those have a
purpose.
Without going further details into each section of the document, it
seems to me that this document could/should be simplified to specify a
basic set of requirement/soultion for a simple 6LowPAN network. This
is the minimum and basic optimization one needs to implement for
6lowpan-ND as a 1)node and as a 2) router.
If we assume L3 routing and multihop-subnet definition as the basic
assumptions for the 6Lowpan optimization
then let's just mark those items for the core operations. [ RS, RA,
NR, NC, Whiteboarding, DAD(?), NUD(?) and
new options ]. Also we can mark the options for MUST and MAY, SHOULD
use.
This is already done. Everything is required except:
1. Mesh-under has no LoWPAN Router nodes.
2. Extended LoWPAN is optional (and in its own sub-section).
If an ER uses Extended LoWPAN mode, it has no affect of Host and
Router specs.
In summary, Extended LoWPAN is really the only option. We will try to
make that clearer in -08.
Drafts/specifications on extensions for more complex scenarios such as
extended LowPANs, mobility etc. can follow in a separate doc.
Now, the wg may consider :
1) Do we need to split this document into a basic 6lowpan
(ND+bootstrapping) document that requires minimum change from RFC4861
and a follow-up document with more optimization for extended
configuration or usage? Do we need 6lowPAN ND to tie up with ROLL
routing protocol or keep them independent in the basic 6lowPAN-ND doc
?
I don't see a strong reason to split them personally. We could further
isolate the Extended LoWPAN stuff into its own section or appendix in
the same document, but it is much easier to have it all in one. At
least I wouldn't want to run 2 protocols through WGLC and the IESG.
2) do we need to consider fault-tolerance as a basic requirement?
It doesn't really require much of anything as details on how to do
fault tolerance are out-of-scope. We were asked to add a section on
fault tolerance. If it isn't needed then we can just remove that (it
doesn't technically affect anything else).
5) Does this solution only focus on Route-over first? Or are there
enough demand for both mesh-under and route-over ND discussions in the
6lowpan-ND base document ?
The document is totally agnostic to RO or MU, so I don't see a need
for this.
I apologize in advance for not bringing these questions in the list
earlier, but I beleive that we should answer these questions now
rather than later in the game. It'll help us in the
6lowpan-interoperability and also to isolate the mandatory
requirements vs optional case-by-case functionalities.
No problem!
Zach
Best regards,
-Samita
--
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
