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

["Simone Ruffino" <[e-mail]>]

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

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

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

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

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



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

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 ?

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

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.


> 	Hope these comments help.
>
> 	Kind Regards,
>
> 	Carlos J.
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Autoconf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/autoconf
>   
--------------------------------------------------------------------

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 [e-mail].

        Thank you

                                        www.telecomitalia.it

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


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