Subject: [Autoconf] Review of draft-ietf-autoconf-statement-01

From: Thomas Clausen <[email-masked]>
Date: Wed, 7 Nov 2007 12:47:20 +0100

Dear Authors, AUTOCONF wg,

I've been reading over the I-D mentioned in subj, and want to share a  
few comments with you. I hope that the authors can address/discuss  
these issues on the mailing list and, if appropriate, issue updated I- 
Ds, that we may be able to make rapid progress.

Let me, however, first thank the authors for the effort they've gone  
through in trying to collect and write this I-D, and keep things  
consistent with http://www.ietf.org/internet-drafts/draft-ietf- 
autoconf-manetarch-06.txt
  -- I know that it is not an easy task to "chase a moving target"  
such as another I-D while at the same time try to stabilise draft- 
ietf-autoconf-statement, and I am impressed by the progress made. So  
THANKS, and keep up the good work ;)

I'll also apologise in advance here, since I'm trying to ask a bunch  
of nasty questions here, but I am not trying to be nasty -- rather,  
to ask them such that we can get them discussed and addressed  
quickly. I hope that you will forgive my direct style in the below.

<wg-chair-hat-on>
	I hope that this may also inspire others to carefully review this I- 
D and provide
	feedback -- specifically those who are contemplating or already have  
proposed
	solutions.
</wg-chair-hat-off>

Hereby general comments, followed by specific comments to different  
sections of the I-D.

General comments
===============

	o After a brief read-through the I-D, it is unclear what the focus  
is. Are we
	   talking about assigning IP addresses? Delegating prefixes? Both?
	   Neither? How does this I-D position itself wrt. prefix delegation  
and NDP?
	   DHCP? Do either/both of these support both address assignment and
	   prefix delegation? (I *know* the answer to this question, but the  
discussion
	   related would be useful in the I-D since, I think that it  
transpires that in this
	   I-D we are really looking at "prefix delegation" -- in which case  
there may
	   be reasons other than "ad hoc networks' unique  
characteristics" (to borrow
	   a phrase from the introduction) which may motivate additional/new  
work.

	   This, to me, is a rather big issue that I would like to be very  
clear on -- addresses?
	   prefixes? both? neither?

	o Also after the first read-through, it is not clear that the goal  
is a mechanism for
	   within MANETs, but that this implies that "outside MANETs" things  
remain as
	   they are. In other words, this I-D should not indicate that  
"protocol XXX has
	   shortcomings, so it should be abandoned and replaced by something- 
yet-to-
	   be-designed". It'd be good to, up-front, state the scope of the  
problem statement
	   very clearly, and thereby the scope of the protocols-yet-to-be- 
designed.

1. Introduction
===========

	o last paragraph states that:

		"Standard automatic IPv6 address/prefix assignment solutions [5], [3]
		[4] do not work "as-is" on MANETs due to ad hoc networks' unique
    		characteristics [2], therefore new or modified mechanisms are  
needed.
    		This document thus details and categorizes the issues that need  
to be
		addressed."

	  While that no doubt is true, reading through [2], there are a  
number of the
	  "unique characteristics" which MANETs have, and which do not  
immediately
	  spring forward as making existing solutions "not work". As an  
example, that
	  nodes in a MANET may join/leave freely is more common in a MANET, but
	  is still ocurring in other forms of network (I regularly connect/ 
disconnect my
	  laptop, and NDP happily gives me addresses).

	  It might be well to be more explicit as to what it is precisely  
that "does not work"
	  and what "might work, but not efficiently enough".

	  I note that this document has a large educational mission, and as  
such it is
	  important to be clear on such matters

	o last paragraph, and also elsewhere in the I-D:

		"...MANETs due to ad hoc networks' ...."

	   There's through the document a somewhat inconsistent use of  
"MANET" and
	   of "ad hoc network". Are these interchangeable (in which case a  
single term
	   should be chosen and used) or are they so subtly different that  
the subtlety
	   escaped me (in which case it might be helpful to be up-front and  
define the
	   difference)?
	
	   This comment applies also to the remainder of the I-D, where the  
MANET / ad hoc
	   network terminology is neither used consistently nor defined such  
that any
	   difference is clear.

2. Terminology
============

	o Is it a conscious choice not to import RFC2119 terminology?

	o first paragraph, there's an extraneous space before the colon ":"

	o plenty of "MANET" vs. "ad hoc network" confusion.

	o to "Global Address":

		- what does it mean when saying "An IP address configured on a  
MANET router"?

	   as far as I am concerned, we usually talk about *delegating* (if  
appropriate) prefixes to
	   routers, and *assigning* IP addresses to interfaces

	o to "Standalone MANET":

		- this is defined by "An independent ad hoc network...." It'd be  
helpful to understand
		  what "independent" means.

		- I note that a "Non-standalone MANET" is not defined anywhere.  
Should we go with
		  the logic of negation, then this would become "A dependent ad hoc  
network....."
	
		- Later in the I-D (3.1 and 3.2) you talk about "Standalone" as  
opposed to "Connected".
	  	  Is the difference between these two to be found in the presence  
of a "MANET border
		  router", as is indicated in 3.2? If so, then stating this clearly  
in the terminology section
		  might help. Also see comments to 3.3 below.

	o to "Address Generation".....I do not think (but Chris will confirm/ 
correct this, I gather ;) ) that
	   it is correct English to say ".....in view to configure...".  
Could it not become "with the purpose of"
	   - or something similar - instead?

	o to "Address Generation" and "Address Assignment":

		- first, there's a logical issue that I think is unclear:

			* "address generation" yields a "tentative address"
			* "address assignment" assigns a generated address (I assume the  
address resulting
			   from "address generation") to an interface

		  This leads me to read that "address assignment means configuring  
an interface with
		  a tentative address" -- is that intentional? At what point does  
an interface get a non-tentative
		  address assigned?

		- Second, here, we talk about addresses. Are we concerned with  
addresses or prefixes? How do
		  prefixes appear and are delegated to routers?

	o to "Pre/In-service address uniqueness":

		- again, here the I-D talks about addresses. How about prefixes?

		- something is "unique within a certain scope". What is the  
definition of "scope"? What "is" a scope?
		  (Playing the devils advocate here) do you by "scope" really mean  
"subnet"?
	
3.1 Standalone MANET and 3.2 Connected MANET
========================================

	o as discussed above, the definition of a standalone and connected  
MANET is fuzzy to me. It reads as if it can apply to:

		- a network where there is no MANET border router present;
		- a network where there is a MANET border router present, yet this  
MANET border router does
		  not have a prefix from which it can assign/delegate addresses/ 
prefixes;
		- a network where there is a MANET border router present, which has  
authority of a prefix.

	   Of course, this comes down to the fact that "MANET border router"  
from a router-guys point-of-view may
	   simply be an entity forwarding traffic not destined to itself --  
which is exactly what the I-D states, saying that
	   "MANET routers may generate traffic destined to remote  
hosts" (may MANET routers also receive traffic
	   from such remote hosts, btw.? If so, does it happen directly, or  
through an ill-viewed technique which rhymes
	   with "CAT"?) For AUTOCONF, it seems that there might be some  
underlying  assumptions as to if it also runs
	  "something else on its interfaces which can autoconfigure MANET  
routers", but this is not clearly spelled out.

	   Would it be possible to be much more explicit on this item?

	o This is only to 3.1.......in second paragraph, you write "pre- 
configured local or global IP addresses (or prefixes)"

		- what's a "local address"?
		- what's a "local prefix"?
		- can it have either? both?

	  Again, the fact that we do not know (at least, the I-D does not  
make it clear) at this point if the aim is "something with
	  addresses" or "something with prefixes", then this seems unclear,  
Also, is "local address" == "Link Local Address", or
	  is it a "MANET Local Address" as defined in this I-D in the  
terminology section?

4. Problem Statement
=================

	o the crux of this section is, that it talks about addresses and  
prefixes as if these are interchangeable, yet nowhere
	   is this motivated. Taking a purely academic viewpoint, one may  
argue that an address just is a prefix of
	   length==ADDRESSLENGTH, and yes, one can argue this way. However,  
in case of any mechanism for
	   continued address uniqueness verification, it may be important to  
make the distinction. Assuming that MR1
	   has the prefix p:1:: delegated, and MR2 has the prefix p:2::  
delegated, then MR1 and MR2 are each responsible
	   for the uniqueness within p:1:: and p:2:: respectively, whereas  
"the MANET" is responsible for simply assuring that
	   MR1 and MR2 have unique prefixes delegated. In case we are  
talking about address assignment, not prefix delegation,
	   then if MR1 has 3 hosts attached, these might get addresses p: 
1::3 p:2::4 and p:2::5, all assigned "from outside MR1"
	   -- and thus, any continued address uniqueness (or duplicate  
address detection) would not be among the MANET
	  routers, but also involve attached hosts which would otherwise not  
be MANET aware.

	  It might be evident to the authors and to the autoconf WG how to  
think about this, but I think that it is something that
	  should be made clear in this I-D -- and I find that it is not.

	o in 4.1, does a MANET router *need* to configure a link-local  
address on its MANET interface? A /128?  a MLA?
	   I have run numerous MANETs where I did not have a link-local  
address on the MANET interface, and I wonder
	   why that is broken since, in practice, it runs just fine?

	o in 4.1, I have a little difficulty with the second paragraph. In  
this, it is clearly said (for the first time) that the goal is
	   prefix delegation (and in IPv6......also for the first time). It  
tries to make a distinction between "routing" and
	  "autoconfiguration", but I find that this is a slight bit  
backwards. Is it more complicated than that:
			
			- autoconf: getting an unique prefix assigned to each router
			- routing: propagating information about which prefixes are  
physically where in the network (and
			   subsequently finding paths etc...)

	  I may be missing something subtle, and the way this section  
appeared made me think that this might indeed
	  be the case ;)

	o for 4.2 "Existing Protocols' Shortcomings":

		- see general comment, specifically:

			- do other protocols do prefix delegation? how? (rhetoric question  
again, my point
			  is that there are no references to or discussion of such).  
Perhaps a new subsection
			  to 4.2?;

			- some MANET characteristics may not "break" existing protocols,  
but just make
			  these protocols "less efficient". Could it be possible to be a  
bit more explicit on this?

		- I am unclear on what "traditional solutions" means exactly. Can  
we not just start by saying
		  something like "PD/AC is done using RFCXXX, YYY, XXX. These do  
not support the following
		  events, which are common in MANETs" somewhere early in 4.2
		  ("traditional" is one step away from "legacy" -- a word I've  
promised Thomas N to not use ;) )

		  Anyway, the introduction to 4.2.3 and 4.2.4 starting "XXX is a  
potential event that was not
		  considered in the design of traditional solutions" may even be  
wrong -- likely it was considered
		  and then classified as "not relevant" for the network topologies  
these "traditional solutions"
		  were designed for.

		- in 4.2.4, I have a difficulty with "The MANET must thus function  
without traditional address
	 	  allocation server availability". Assuming that one uses, say,  
DHCP, to delegate prefixes to
		  each MANET router, can a MANET not survive even if the top-level  
DHCP server is unavailable
		  for "a while"?

	o for 4.3 "MANET Autoconfiguration issues", I think that:

		- it should be added that the "shortcomings of traditional  
solutions" are only within the scope
		  of a MANET, and not in general. I.e. that it should not be  
insinuated that the existing solutions
		  do not work in general (they work rather fine within the context  
where they were designed).

	o for 4.3.1 "Address and Prefix Generation"

		- what is "traditional"?

		- I do not think that it is fair to say that "hierarchies" are  
"bad", which is sort of what is being
		  said in this paragraph. Rather, if I read the I-D correctly, no  
explicit hierarchy is assumed
		  within the MANET, but with respect to other networks, hierarchies  
are respected -- e.g. wrt.
		  any form of global addresses or prefixes acquired/delegated

		- can we find an alternative phrase to replace the last sentence,  
in particular I do not like
		  the word "totally", and I do not understand what "....a priori  
over all the MANET" means.

	o for 4.3.2

		- another "totally"

		- last paragraph first sentence, add "then" before "checking". Also  
second sentence.

		- last paragraph second sentence, is it reasonable to state that  
"checking should be used",
		  universally?

		- to the whole section, paragraph 2+3 discusses pre/in-service  
issues, whereas 3+4 discuss
		  "checking". One wonders if this refers to pre-service checking or  
in-service checking -- or both
		  or neither. I suspect (since the talk is about merging/ 
partitioning) that these paragraphs
	  	  reference in-service, but it is not clearly spelled out.

	o for 4.3.3 "MANET Border Routers Related Issues"

		- the MANEMO initiative has brought some good stuff forward on this  
subject, notably
		  about the importance that if an address is acquired from one  
MANET border router, then
		  the traffic to/from that node should go through that MANET border  
router. I would suggest
		  looking at some of the discussions relative to MANEMO, and  
perhaps consult some of the
		  MANEMO proponents to ensure that this section reflects their  
considerations correctly. Off
		  the top of my head, Teco (having just published an individual I-D  
relative to this) and
		  Wakikawa (if you can find his now expired global6 I-D) might make  
good starting points for
		  this?

		  In any event, I feel that this section should elaborate a bit on  
this issue, since it is not at all
		  addressed in the current incarnation of this section.

	o for 5 "Solutions considerations"

		- A thing that can be brought forward would be "compatibility with  
existing solutions" -- example:
		  NDP is used for IPv6 stateless, but also for MobileIP/NEMO.  
Assuming that a solution "multi-hop
		  NDP with prefix-delegation" was produced, would this interwork  
with other uses of NDP, say NEMO,
		  which may make other assumptions of how far a NA/NS/RA/RS travels  
in the network? I am not
		  having precise suggestions to this section, but I would encourage  
that it be thought about and
		  discussed since this may be one of the areas where there would be  
gains for other protocols if
		  the AUTOCONF wg developed protocols are done in one way or another.

That's all for now!

Cheers,

Thomas

-- 
Thomas Clausen
[email-masked]
http://www.thomasclausen.org/
http://hipercom.thomasclausen.org/

_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf