Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 16 November 2009 07:36 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8503F3A6A91 for <autoconf@core3.amsl.com>; Sun, 15 Nov 2009 23:36:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.234
X-Spam-Level:
X-Spam-Status: No, score=-5.234 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jc3mpBkKvFSL for <autoconf@core3.amsl.com>; Sun, 15 Nov 2009 23:36:08 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A58153A6925 for <autoconf@ietf.org>; Sun, 15 Nov 2009 23:36:07 -0800 (PST)
X-uc3m-safe: yes
Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 62C5DBA5235; Mon, 16 Nov 2009 08:36:05 +0100 (CET)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Teco Boot <teco@inf-net.nl>
In-Reply-To: <006a01ca65e2$2bdc1ba0$839452e0$@nl>
References: <1258127094.5035.32.camel@acorde.it.uc3m.es> <006a01ca65e2$2bdc1ba0$839452e0$@nl>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-XGU3yCdD3c4mR3zghRzO"
Organization: Universidad Carlos III de Madrid
Date: Mon, 16 Nov 2009 08:36:05 +0100
Message-Id: <1258356965.7116.27.camel@acorde.it.uc3m.es>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.3
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2009 07:36:12 -0000

Hi Teco,

On Sun, 2009-11-15 at 19:55 +0900, Teco Boot wrote:
> Carlos Jesús Bernardos Cano wrote:
> 
> >	- Section 3: "The configuration proposed by this model is
> >applicable to
> >any router's IP interface" --> I wonder if this should be changed to
> >"The configuration proposed by this model is applicable to any router's
> >IP MANET interface" or something like that. By saying "any router's IP
> >interface" it may seem that the configuration of "non-MANET" interfaces
> >would also follow the guidelines provided by the document (i.e., /128,
> >no uniqueness ensured for LLs, etc.). I'd prefer to explicitly state
> >that the model is for MANET interfaces.
> 
> Somewhat agreed. The problem is wording: what is MANET interface?
> I say: interface with MANET protocol running. Then your suggestion

I agree with that definition. It is actually the one we used in our
draft.

> is also not completely correct. Interface to Wireless Link? Also

Why is it not correct?

> not completely correct, as there are many wireless links that do not 
> have problems with on-link prefixes.
> 
> 
> >	- Section 4: "no two such interfaces in the network should be
> >configured with the same subnet prefix" --> this at least conflicts with
> >LLs. (I'm not bringing up __here__ again the LL issue, just pointing out
> >that the document should be revised to avoid this kind of contradictory
> >statements: "Note that while an IPv6 link-local address is assigned to
> >each interface as per [RFC4291]" and "no two such interfaces in the
> >network should be configured with the same subnet prefix".
> 
> Agreed.
> 
> 
> >	- Section 6.1: "These limitations are further exacerbated by the
> >smaller pool of IPv4 link-local addresses to choose from and thus
> >increased reliance on DAD" --> if link-locals are not considered and
> >"normal" DAD is not considered suitable for MANETs, I think this
> >sentence makes no sense and should just simply be removed.
> 
> Yes, we should remove all references to DAD. It is to controversial.
> 
> 
> >	- Section 6.2: "Routers cannot forward any packet with link-local
> >source or destination address to other links..." --> this is rather
> >obvious and not particular of MANETs, why is this described in the
> >document?
> 
> See my other posting. This is an important argument, as in the normal
> case the link is expected to be somewhat stable, and there is an
> interface down trigger to signal the link down. On xxx interfaces,

Protocols should be designed to work without such triggers (actually
there are many cases win which these triggers are not available, even in
wired networks).

> there is no such a trigger. And when nodes get out of range,
> connections using LLs are affected while connections with non-LLs
> are not.

Well, this depends. If your IP one hop neighbour gets out of range, you
need to find a new one. If you are talking about TCP-alike connections
(connection oriented protocols), I agree, but in this case it is a bad
idea to use link-locals anyway, IMHO.

Thanks,

Carlos

> 
> 
> >	- Section 6.2: "There is no mechanism to ensure that IPv6 link-
> >local
> >addresses are unique across multiple links, hence they can not be used
> >to reliably identify routers." --> this is not particular of MANETs
> >either, why is in the document?
> 
> We should remove this argument.
> 
> 
> >	- Appendix A: "MANET Link Model" --> I don't believe in the
> >existence
> >of a "MANET Link", and I don't see its relevance in an __address
> >autoconfiguration__ document. Repeating myself here... I think this
> >document and some discussions in the ML deviate from the charter goal:
> >we need to come up with a practical ____addressing____ architecture.
> >IMHO, we have been discussing instead about "IP over MANET", which to me
> >is a rather different thing (well, to me it doesn't even exist, if we
> >consider L3 MANETs).
> 
> With having the draft-baccelli-autoconf-adhoc-addr-model, we can close
> this issue.
> 
> 
> >	- Appendix A: "it remains to be determined whether or not the
> >scope of
> >AUTOCONF includes applications other than routing protocols running on
> >the router" --> this is a very important question that we have brought
> >in the meeting. I have my personal opinion, but this is irrelevant,
> >since there seem to be a consensus (I wasn't aware of it, but Thomas
> >stated otherwise). I'd like to ask the chairs to bring this to the ML to
> >close this issue.
> 
> I think the consensus is that there are applications in a MANET. The MANET 
> is not solely for running MANET protocols... .
> It is also in the charter:
>   It is required that such models do not cause problems for ad
>   hoc-unaware parts of the system, such as standard applications running
>   on an ad hoc node or regular Internet nodes attached to the ad hoc
>   nodes.
> 
> 
> Teco.
> 
> 
-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67