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

[Ulrich Herberg <[e-mail]>]

Zach,

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

On Thu, Nov 19, 2009 at 11:18 AM, Zach Shelby <[e-mail]> wrote:
> 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.

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. RFC4861 also explains that a link might be non-transitive, so that could also be referenced.

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 what 6lowpan-nd does for a 6lowpan network.

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 "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 ;-)

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


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