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

[Emmanuel Baccelli <[e-mail]>]

Hi Cralos thanks for your feedback,

Carlos Jesús Bernardos Cano a écrit :
> 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.
> 

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

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

Agreed.

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

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

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

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

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

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

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

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


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