Subject: [6lowpan] Comments/suggestions on nd-07

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 9 Nov 2009 02:35:10 -0800

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Nov 2009 19:43:57 +0900

> mind - should not it be "Standard ND" ?

No.  Both 6lowpan-ND and RFC 4861 will be standards-track, so  
"Standard ND" is ambiguous.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Nov 2009 20:14:54 +0900

Hi Samita,

some more quick (and terse, sorry) answers.

>      (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.)

> configuration. It might be better to name it differently - say

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.

> 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.

> 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?

> 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.)

> 6lowpan-ND base document ?

It does both.  Generality is fine if it does not cost anything.

Gruesse, Carsten

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 09 Nov 2009 05:23:58 -0700

Not really since this document would not refer to itself and does not
refer to itself as standard ND.  It was very clear in the previous
version what standard ND meant.

	geoff

On Mon, 2009-11-09 at 19:43 +0900, Carsten Bormann wrote:
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 09 Nov 2009 05:29:43 -0700

> I think this is about the sleeping schedules.

This should be clarified.
> Because that's the point of updating 4944: If it's a LoWPAN, it uses  

There is not consensus about this.

> Not supporting the fringe cases in which 4861 works in a LoWPAN is  

There is disagreement about this also.  As has been pointed out a number
of times on this list - 4861 does work and not just in "fringe" cases.
This is not a decided point!

	geoff

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Nov 2009 21:42:23 +0900

On Nov 9, 2009, at 21:29, Geoff Mulligan wrote:

> 4861 does work

Please reread section 1 of that document.

No, 4861 does not work on an NBMA.
I thought we had this discussion a couple of times now.

The fringe cases where 6LoWPANs happen not to be NBMAs are not worth  
holding the whole technology hostage.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Nov 2009 21:54:01 +0900

On Nov 9, 2009, at 21:23, Geoff Mulligan wrote:

> It was very clear in the previous

Does RFC 2460 refer to RFC 791 as "Standard IP"?
Does IMAP refer to POP3 as "Standard mail access protocol"?
Does SIP refer to H.323 as "Standard IP telephony signaling"?

When we define an alternative to something, we don't necessarily call  
the existing way "standard".

I think the desire to call 4861 "standard ND" is an expression of a  
mindset that somehow glorifies that standard.
That's why I asked to get rid of that term in ND-07.

There is, of course, no desire to get rid of 4861 for the domains  
where it works (links where you can cheaply reach all other nodes in  
one message, i.e., broadcast and point-to-point links).
But there is absolutely no gain in desperately trying to use its  
mechanisms where they do not work.

Gruesse, Carsten

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 09 Nov 2009 06:45:36 -0700

I'm not so wrapped around the word standard ND vs 4861 ND or anything
else though I think your examples are off base.  I would hope that there
is no desire to get rid of 4861 and I never thought there was. 

There is obviously no consensus here that 4861 does or does not work in
lowpans.

It does seem clear that there have been concerns expressed on the list
that this new ND may not be the "right" direction and may be unnecessary
for all lowpans, may create complexity where it is not needed, and may
break or be incompatible with other forms of address assignment for
lowpans.

I am re-reading draft 7 and will send my comments.

	geoff

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Nov 2009 22:56:01 +0900

> There is obviously no consensus here that 4861 does or does not work  

But that is a simple matter of checking the facts.
Let's do that and lay that misconception to rest.

> for all lowpans,

Now that is a matter of opinion.
Yes, we had these discussions, and I had the impression they were  
resolved.

> may create complexity where it is not needed, and may

Fixed in ND-07.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Mon, 9 Nov 2009 23:56:01 +0900

Samita,

Thanks for the review. Here are a few clarifications. I integrated  
some of your questions into tomorrow's presentation, so just in time.

> 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...

> 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.

>      (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.

> on them to provide a clear picture.

OK, any ideas there are welcome.

>      i,e: how is IP-routing and Route-over related. This definition

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).

> configuration. It might be better to name it differently - say

Sure, it has been called LoWPAN Subnet in the past. That works too.

> 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.

> 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.

> new options ]. Also we can mark the options for MUST and MAY, SHOULD  

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.

> 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).

> 6lowpan-ND base document ?

The document is totally agnostic to RO or MU, so I don't see a need  
for this.
> requirements vs optional case-by-case functionalities.

No problem!

Zach

-- 
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.

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 9 Nov 2009 18:40:45 +0100

Hi Carsten, 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: lundi 9 novembre 2009 14:56
> To: Geoff Mulligan
> Cc: 6lowpan; [email-masked]
> Subject: Re: [6lowpan] Comments/suggestions on nd-07
> 
> > There is obviously no consensus here that 4861 does or does 
> not work 
> > in lowpans.
> 
I am not sure we have an agreement on what needs to be fixed though from
4861.

> > that this new ND may not be the "right" direction and may be 
> > unnecessary for all lowpans,
> 
> Yes, we had these discussions, and I had the impression they 
> were resolved.
I never had the impression there were resolved and am still not
convinced by section 1.2.
What is the proposed process to progress on disagreements? What is the
status of cross review with 6man?

Best,
Julien

> 
> > may create complexity where it is not needed, and may break or be 
> > incompatible with other forms of address assignment for lowpans.
> 
> Fixed in ND-07.
> 
> Gruesse, Carsten
>

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 9 Nov 2009 18:34:38 -0800

Hi Julien,

> I am not sure we have an agreement on what needs to be fixed though from

[SC>]  One can run rfc4861 as it is on 6lowpan networks - no one can prevent
it. But the 6lowpan network will not run efficiently. This has been
discussed for many years in the 6lowpan working group and there is no doubt
that there is an optimized solution is needed for a power-efficient 6lowpan
network.

The co-authors of the current 6lowpan-ND have tried hard to accommodate all
corners of the problems in the low power and lossy networks including
multi-hop subnets, and migration of nodes from one 6lowpan subnet to another
etc. The problems are real and the solutions are there - but we would have
to define a basic scope that will be most useful for average applications.
The second/follow-up document will describe further ND optimization
necessary for enhanced 6lowpan applications/usage - that's all I was trying
to say.

Thanks,
-Samita