Subject: [Autoconf] Comments on adhoc-addr-model-00

From: Zach Shelby <[email-masked]>
Date: Thu, 19 Nov 2009 12:18:21 +0200

Hi,

Over in the 6lowpan WG we are defining a technique for optimizing the host-router (node-router) interface, called 6lowpan-nd. Working on this problem for a couple years, and starting with RFC4861 terminology, it turns out that we came to a very similar conclusion to the autoconf WG. However, in 6lowpan we are routing protocol agnostic and we deal with hosts and routers.

The link technologies we use in 6lowpan exhibit the characteristics defined (very nicely!) in draft-baccelli-multi-hop-wireless-communications-03. Although we don't always have multi-hop, even then many of the same characteristics occur.

The current version of ietf-6lowpan-nd-07 goes to all the trouble of defining mostly the same things you have (with much more text...). In Hiroshima we got a kick (thanks Dave!) to explore the use of draft-ietf-autoconf-adhoc-addr-model to simplify our own document and to unite the models across WGs. 

Here are my comments/thoughts on the addr-model-00 document from the 6lowpan perspective:

1. Make the document MANET agnostic. This can just as well be referenced by ROLL and 6LoWPAN work e.g. I only find MANET referenced in the intro (can be extended with other examples) and in the last paragraph of 6.2. Both are easily fixed.

2. I like the "link of undetermined properties"... however you might want to point to a document like draft-baccelli-multi-hop-wireless-communications to point out why links end up like that. RFC4861 also explains that a link might be non-transitive, so that could also be referenced. 

3. You have two open issues in Appendix A. To me both of these are OK already. The link model is fine (see 2). If globally unique addresses are needed, leave that to some other mechanism. This is what 6lowpan-nd does for a 6lowpan network.

4. In 6lowpan we would use the "when more specific assumptions can be made about connectivity" clause, as we always assign a single (global or ULA) prefix across the whole 6lowpan network. So the "MAY be configured with the same prefix" in Section 4 would be applied. In 6lowpan-nd we are able to make an assumption about connectivity between node-router pairs thanks to our mechanism defined. So please do keep this clause, it is very useful ;-)

5. We consider link-local addresses in the same way, this is OK.

6.  The second bullet point of Section 6.2 needs some expansion not to be misunderstood. In addition to the existing sentence, also add text like: ", unless an assumption can be made about connectivity in which case the prefix may be /64." The point being that if you can assume connectivity with a router (who somehow advertises a prefix), you may be able to autoconfigure an address using a shared prefix. This is what we do in 6lowpan.

So in my opinion, with the very small changes above (1. and 6.), this document would be very useful for our work. 

Thanks,
Zach 

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 10:53:04 -0000

> 1. Make the document MANET agnostic.

MANET is an overloaded term. One meaning is "what's done in
the MANET WG". The other is "what's done in an ad hoc network".
(Why have I dropped "mobile"? - because really it's not mobility
that matters, it's dynamism, and pretty much all ad hoc networks
are dynamic, just the timescale varies.) In the latter sense
- which is what I think matters - what's happening in ROLL and
6LoWPAN are specialised MANETs. The document may be agnostic on
the former sense, but not, I suggest, on the latter sense.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 19 Nov 2009 11:53:10 +0100

Zach,

it's good to hear that the autoconf-addr-model can be used for 6lowpan
with only small changes. My comments inline...

> 1. Make the document MANET agnostic. This can just as well be referenced by ROLL and 6LoWPAN work e.g. I only find MANET referenced in the intro (can be extended with other examples) and in the las…

Yes, that seems to be reasonable for me.

> 2. I like the "link of undetermined properties"... however you might want to point to a document like draft-baccelli-multi-hop-wireless-communications to point out why links end up like that. RFC48…

I agree that the baccelli draft is very useful. I am undecided on
whether to include a reference to that draft in the address model.
While I think it could be very useful as a rationale for the address
model, I also understand that the chairs are afraid of going this
direction. The reason is that autoconf is only chartered for a single
document, namely the address model. We are already years behind
schedule. Producing a second document -- and including a reference
from the address-model ID -- which we are not chartered for, could be
difficult to argue for in the IESG.

> 3. You have two open issues in Appendix A. To me both of these are OK already. The link model is fine (see 2). If globally unique addresses are needed, leave that to some other mechanism. This is w…

I think that the authors of the draft will release an updated version
very soon that removes the Appendix. Is this correct?

> 4. In 6lowpan we would use the "when more specific assumptions can be made about connectivity" clause, as we always assign a single (global or ULA) prefix across the whole 6lowpan network. So the "…

good :-)

> 5. We consider link-local addresses in the same way, this is OK.

good.

> 6.  The second bullet point of Section 6.2 needs some expansion not to be misunderstood. In addition to the existing sentence, also add text like: ", unless an assumption can be made about connecti…

One could argue that this is already implicit due to the sentence in section 3:
   "When more specific assumptions can be made regarding the connectivity
   between interfaces, these SHOULD be considered when configuring
   subnet prefixes."

> So in my opinion, with the very small changes above (1. and 6.), this document would be very useful for our work.

Thanks for your review, Zach.

Ulrich

---

From: Zach Shelby <[email-masked]>
Date: Thu, 19 Nov 2009 13:31:34 +0200

> the former sense, but not, I suggest, on the latter sense.

Exactly. 

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Zach Shelby <[email-masked]>
Date: Thu, 19 Nov 2009 13:37:04 +0200

Ulrich,

> difficult to argue for in the IESG.

Yep, makes sense. So instead just summarize the reasons why such a link might be categorized like this with a short paragraph in the adhoc-addr-model document. You may still point at RFC4861, as non-transitivity is mentioned there as well.

>   between interfaces, these SHOULD be considered when configuring

Right, so there could be a pointer to Section 3 at least in that bullet point to remind the reader of this exception? 

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND