Subject: [Autoconf] Comments on draft-ietf-autoconf-statement-02.txt

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 21 Nov 2007 01:24:47 +0100

Hi all,

	Thanks for the new version of the draft. Some comments below (I hope I
don't repeat any already brought on the ML):

	- "Connected MANET  - A mobile ad hoc network, which contains at least
one ICP." --> I'm not sure a connected MANET should necessarily contain
one ICP, at least as I understand what an ICP is. As I see it, an ICP
can be -- going to solution space -- a DHCP server in the infrastructure
(and therefore not _contained_ in the MANET). Maybe it's just myself not
reading the definition properly.

	- "Another example of such a scenario is coverage extension of a fixed
wide-area wireless network, where one or more mobile routers in the
MANET are connected to the Internet through technologies such as UMTS or
WiMAX." --> I think the term mobile router may lead to confusion, I'd
prefer MANET router, since mobile router is usually related to NEMO (RFC
3963).

	- (Section 4.1.2 Dynamic Topology Support) "Moreover, possible frequent
reconfiguration due to intermittent reachability cause [5] to be less
efficient than expected, due to large amounts of control signalling."
--> I think I'm missing something here, can [5] (RFC 4862) be used in a
multihop environment? I don't clearly the comment on [5] and dynamic
topology.

	- (Section 4.1.3 Network Merging Support) "For instance, [5] and [3]
test address uniqueness via messages that are sent to neighbors only,
and as such cannot detect the presence of duplicate addresses configured
within the network but located several hops away.  However, since MANETs
are generally multi-hop, detection of duplicate addresses over several
hops is a feature that may be required for MANET interface address
assignment (see Section 4.2.2)." --> Again, I think I'm missing
something here, I see network merging has more to do with the in-service
uniqueness requirement that with the multi-hop nature (of course,
everything is related ...).

	- (Section 4.2.2 Prefix and Address Uniqueness Requirements) "Phenomena
such as MANET merging and MANET partitioning may bring the need for
checking the uniqueness (within the specified scope) of addresses or
prefixes that are already assigned and used." --> I'd remove "and MANET
partitioning", since IMHO only merging may produce duplicates, right?

	- (Section 4.2.2 Prefix and Address Uniqueness Requirements) "For
instance, if (i) is extremely low and (ii) significant, then checking
pre-service uniqueness of addresses and prefixes may not be used." -->
shouldn't it say ... checking in-service uniqueness of addresses ...? I
thought pre-service is assumed to be always required to avoid duplicate
addresses when a MANET router joins the network (and therefore avoid
routing problems, etc...).

	- (Section 5 Solutions Considerations) "Solutions must achieve their
task with (i) low overhead, due to scarse bandwidth, and (ii) low
delay/convergence time, due to the dynamicity of the topology." --> Are
we assuming always "scarse bandwidth"? IMHO this is scenario-specific,
and although I agree on the requirement of low overhead in general, how
important this issue is depends on the particular scenario. IMHO,
Section 5 as it is now does not really fulfils the goal of providing
solutions considerations. I really think that performing such an
analysis without going more deeply into the details (such as in
draft-bernardos-autoconf-evaluation-considerations-01.txt) is very hard.
As I see it (this is my personal view on that), either we extend this
section or we remove it.

	Hope these comments help.

	Kind Regards,

	Carlos J.

-- 
¡ASÓCIATE! Gratis para estudiantes  http://www.telematica.ws
 Carlos Jesús Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 21 Nov 2007 10:42:35 +0100

Hi Cralos thanks for your feedback,

> reading the definition properly.

OK, I agree. Maybe a more precise way would be to say instead that a 
connected MANET can reach an ICP?

> prefer MANET router, since mobile router is usually related to NEMO (RFC

Agreed.

> everything is related ...).

I see what you mean. How about replacing the word "assignment" by 
"(re)assignment"?

> partitioning", since IMHO only merging may produce duplicates, right?

Agreed. I guess the order was more intended to be 
partitionning=>merging=>problems ;) But it may be clearer to just talk 
about merging here.

> routing problems, etc...).

You are right. This is a typo that eluded me.

> As I see it (this is my personal view on that), either we extend this

We agree that low control overhead is a generic requirement. If you see 
other generic requirements that are missing here, please tell us and it 
will be mentionned in this section.

Emmanuel

---

From: "Simone Ruffino" <[email-masked]>
Date: Wed, 21 Nov 2007 11:05:18 +0100

Hi Carlos and thanks for your comments.
See below my comments,
Regs,
Simone

> reading the definition properly.

ICP is not clearly defined. In a previous post, I already commented on this.

> prefer MANET router, since mobile router is usually related to NEMO (RFC

I agree.
Suggestion: s / "mobile routers in the MANET"/ "MANET routers".

> multihop environment? I don't clearly the comment on [5] and dynamic

Reading this statement again (sorry, we wrote this sentence a time 
ago...), I think that we "zipped" our thoughts in one sentence, leaving 
out some detail.
IIRC, I think here the problem is not the "multi-hop" environment 
(incidentally, if you think of "normal" ISP network, which are 
multi-hop, rfc4862 perfectly works).
The problem here is the "intermittent reachability": if MANET router 
experiences bad connectivity to its neighbors, it _could_ be forced, for 
example, to repeat DAD on MANET interface much more times than in 
managed networks, thus bringing inefficiency.

Emmanuel, can you add some details here ? Is my understanding correct ?

> As I see it (this is my personal view on that), either we extend this

In my opinion, some text that summarizes general requirements for 
solutions is needed in the PS. Going too much into details here could be 
not appropriate.
Suggestion: keep it as it is, making only punctual corrections, such as 
the one you suggested on the bandwidth.

> ------------------------------------------------------------------------
>
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 21 Nov 2007 11:25:47 +0100

Hi Emmanuel,

	See below...

> connected MANET can reach an ICP?

	That's a possibility, although I'm not 100% convinced about current ICP
definition (as Simone also comments). I have to think more about it
before providing a suggestion...

> I see what you mean. How about replacing the word "assignment" by 

	I'll address this in my reply to Simone's mail.

> will be mentionned in this section.

	I'll also address this in my reply to Simone's mail.

	Regards,

	Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 21 Nov 2007 11:34:21 +0100

Hi Simone,

	My comments inline...

> ICP is not clearly defined. In a previous post, I already commented on this.

	Agree, we should work on this definition. I don't have a suggestion
yet...

> Suggestion: s / "mobile routers in the MANET"/ "MANET routers".

Agree.

> managed networks, thus bringing inefficiency.

	Yes, and it's not only that, but the fact that if we assume the same
IPv6 prefix is used for all the nodes within the MANET (again, that
depends on the model we are thinking of), DAD as it is defined for
non-MANET networks will not ensure the address uniqueness, so we need
some kind of in-service mechanism. Even if a pre-service address
uniqueness mechanism is used, duplications might happen as a result of
merging.

> solutions is needed in the PS. Going too much into details here could be 

	I agree that going too much into details maybe is not the right
approach (that's the reason we worked on that on a separate document),
but I'm not completely sure that addressing these issues just in a
generic way is possible without leaving important things out. That's why
I was suggesting the possibility of removing the section. As it is now,
a reader may think: "OK, overhead is an issue, but also routing protocol
dependency, and the scalability, and the address space utilisation,
etc..."

	Regards,

	Carlos

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Nov 2007 11:43:44 +0100

[...]
 >> Simone wrote:
>>  ago...), I think that we "zipped" our thoughts in one sentence,
>> leaving out some detail. IIRC, I think here the problem is not the
>> "multi-hop" environment (incidentally, if you think of "normal" ISP
>> network, which are multi-hop, rfc4862 perfectly works). The problem
>> here is the "intermittent reachability": if MANET router 
>> experiences bad connectivity to its neighbors, it _could_ be
>> forced, for example, to repeat DAD on MANET interface much more
>> times than in managed networks, thus bringing inefficiency.
> 
> non-MANET networks will not ensure the address uniqueness,

I don't understand... if the entire MANET has only one prefix and only
one subnet then DAD will surely ensure address uniqueness.

Simone says that if a MANET router has bad connectivity to
its neighbor then it could be forced to repeat DAD more often than if
the connectivity was stable.  But isn't this true for _any_ protocol?
If connectivity is troublesome then IP protocols will break, including
any new one.

DAD has a timer and variables (eg count of NS messages to send before
deciding there's no NA) that can be tweaked to accommodate a certain
level of intermitency in connectivity.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 21 Nov 2007 15:02:10 +0100

Hi Alex,

> one subnet then DAD will surely ensure address uniqueness.

	I'm referring to the model where in a multi-hop network ("classic"
MANET model), nodes configure addresses belonging to the same address
prefix (not judging if this model makes sense or not). In this case, the
DAD protocol doesn't work, right? If then we add merging, things get
more complicated...

	Regards,

	Carlos