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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Simone,

	My comments inline...

El mié, 21-11-2007 a las 11:05 +0100, Simone Ruffino escribió:
> 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.

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

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

Agree.

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

	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.

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

	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

> 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
> 
> --------------------------------------------------------------------
>                         
-- 
¡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
[e-mail]
https://www1.ietf.org/mailman/listinfo/autoconf