Hi Zach,
Here are some long due comments on the nd-07 draft. Sorry I could not
have time to review before the publications. There has been some
discussions on the list regarding the previous version of the document
and I know we have discussed them on the 6lowpan list and in the
co-authors list. Due to my time limitations, I was not able to
participate fully in those discussions - sorry about the late
comments. But I thought I'd provide these comments to the 6lowpan list
so that you folks can discuss at the f2f IETF meeting if needed.
Thanks.
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" ?
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.
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.
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.
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.
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.
5. Section 3 [ Protocol Overview]
"6LoWPAN-ND
supports non-transitive links, the use of both mesh-under and route-
over techniques and makes no assumptions about node-node
synchronization."
====> What do we mean by "node to node" synchronization?
"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.
If it co-exists with RFC4861 - does it mean that rfc4861 ND will be
used in the 6lowpan if the L2 supports multicast and less-lossy links?
Or does it mean that rfc4861 implementation could be enhanced with
this specification with some additional configuration knobs.
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.
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.
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
?
2) do we need to consider fault-tolerance as a basic requirement?
3) Should we define one 6lowPAN-ND document encompassing scenarios for
"simple Lowpan", "extended-lowpan", mobility in "lowpan", "fixed
Lowpan - more like Star network" , compliant to ROLL requirement etc.?
Pros: Everything is in one cookbook.
Cons: Document takes time to complete and get approved at IETF
and it becomes complex to figure out
mandatory implementation needs for simple operations/scenarios.
4) Should we split up the document into two documents - 1) basic 2)
Extended. A basic document that requires minimal changes from Standard
ND(rfc 4861) and covers simple Lowpan and adhoc-lowpan?
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 ?
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.
Best regards,
-Samita
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
