Hi Samita,
some more quick (and terse, sorry) answers.
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.
We don't need that as an assumption any more, so why not provide more
freedom to the implementation?
("Guess" refers to assumptions that are not needed, but only help with
some optimizations.
In this case: If the MAC address and the IP address match, routers may
be able to reduce table space.)
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.
We are not really defining that term -- RFC 4291 does.
But it is an important element of the 6lowpan architecture that the
whole lowpan is a subnet, i.e. the address does not change when a node
registers through a different router or even to a different edge router.
====> What do we mean by "node to node" synchronization?
I think this is about the sleeping schedules.
=====> Why is this specification is "REQUIRED" for LowPAN operation?
Some explanation is needed.
Because that's the point of updating 4944: If it's a LoWPAN, it uses
LoWPAN-ND.
LoWPANs (except for two-node and full-mesh with full multicast) did
not have a working ND protocol yet.
6LoWPAN-ND provides that. If you don't want to force every node to
implement multiple NDs, you have to make a decision.
Not supporting the fringe cases in which 4861 works in a LoWPAN is
that decision.
Drafts/specifications on extensions for more complex scenarios such as
extended LowPANs, mobility etc. can follow in a separate doc.
We could do the work to separate these out.
Every host needs to know these are possibilities -- we don't want
hosts that work only in a simple LoWPAN.
(There is very little cost for that.)
Specifying the inter-ER operations of the extended LoWPAN could be
extracted into a separate spec, but I don't see a strong reason for
that.
As it is, the 6lowpan-ND document is slightly more than half the
length of 4861 -- would you suggest splitting that into three parts?
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
?
6LoWPAN-ND should be independent of ROLL.
(ROLL may very well piggy-back on 6LoWPAN-ND messages, but that's for
ROLL to decide.)
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 ?
It does both. Generality is fine if it does not cost anything.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
