Re: [Autoconf] Re: Some Thoughts on Problem Statement.

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 28 November 2007 11:37 UTC

Return-path: <autoconf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxLEd-0003J2-23; Wed, 28 Nov 2007 06:37:43 -0500
Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IxLEa-0003Ic-VR for autoconf-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 06:37:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxLEa-0003IU-Eh for autoconf@ietf.org; Wed, 28 Nov 2007 06:37:40 -0500
Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxLEZ-0000hH-R3 for autoconf@ietf.org; Wed, 28 Nov 2007 06:37:40 -0500
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@gmail.com
X-Msg-Ref: server-9.tower-119.messagelabs.com!1196249859!22615334!1
X-StarScan-Version: 5.5.12.14.2; banners=.,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 12156 invoked from network); 28 Nov 2007 11:37:39 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 28 Nov 2007 11:37:39 -0000
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lASBbXm6005344; Wed, 28 Nov 2007 04:37:33 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id lASBbXSG024096; Wed, 28 Nov 2007 05:37:33 -0600 (CST)
Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id lASBbVaU024077; Wed, 28 Nov 2007 05:37:32 -0600 (CST)
Message-ID: <474D52FA.3010401@gmail.com>
Date: Wed, 28 Nov 2007 12:37:30 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Shubhranshu <shubranshu@gmail.com>
Subject: Re: [Autoconf] Re: Some Thoughts on Problem Statement.
References: <e9c684940711280244q15d24ee1j46b259214f311e17@mail.gmail.com>
In-Reply-To: <e9c684940711280244q15d24ee1j46b259214f311e17@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 071125-0, 25/11/2007), Outbound message
X-Antivirus-Status: Clean
X-CFilter-Loop: Reflected
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: autoconf@ietf.org
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
Errors-To: autoconf-bounces@ietf.org

Shubhranshu wrote:
> <snip>
>> Also, MANET Scope is somehting I need to understand better.  Is
>> MANET Scope in any relationship with the existing scopes:
>> link-local scope, global scope?  Is MANET Scope in some
>> relationship with the scope of the all-manet-routers IP multicast
>> group requested by manet-iana document?
>> 
>> Is MANET scope in some relationship with the scopes of the
>> following Ethernet MAC multicast addresses: 33::1 (all Ethernet
>> hosts), 33::2 (all Ethernet routers), or other Ethernet MAC
>> multicast group scopes?
>> 
>> _some_ relationship?  _No_ relationship whatsoever?
> 
> IMO, MANET scope would be same as all-manet-routers multicast address
>  but the manet-iana document authors can confirm this.

Ok, I would like to know whether MANET Scope is the same as
all-manet-routers multicast address scope.

If that is the case, then it is necessary what is the relationship
between that scope and Ethernet link scope.

>> This makes me think the MANET Router doesn't communicate  to
>> anybody else than self.  Its (real) network interface has no hosts
>> attached to it (has Routers attached to it?), MANET interface is
>> virtual and loopback interface leads to self.  I may misunderstand
>> you.
>> 
>> Also, I will have to read other documents to understand why the
>> loopback interface needs to have address/prefix. If I understand
>> that then maybe I can understand the above as well.
> 
> Not sure why you think MANET router does not communicate with anyone 
> else than self. Its network interface may or may not have any
> attached hosts, depending on the application / deployment scenario.
> MANET routers are expected to run manet-protocols on their MANET
> interface only.

Ok, I understand that on some MANET Router all other nodes are connected
to the MANET Router's MANET interface(s).


>> If the MANET interface is virtual then I think there's no standard
>> for defining link-local address on a virtual interface.  People do
>> different things for these, sometimes random.
>> 
>> I think a good virtual interface (MANET interface or other) would
>> need: -a link-local address (/128 length). -a link-local prefix
>> (the fe80 /10 length). -maybe a global subnet prefix with global
>> address. -maybe another global subnet prefix with a global address.
>> 
>> 
>> I think you mean that "MANET Interface" means a sort of a label we
>> put on a real network interface.  Something that in some contexts
>> some people call "egress interface", or "ingress interface".
>> 
>> So, if you mean MANET Interface is a real interface, then we may
>> already have a means to form a link-local address for it.
> 
> Agree, MANET interface is real interface and, in your words, MANET 
> interface is a sort of label we put on real network interface because
>  manet-protocols are suppose to run on this interface.

I understand.

>>> The probability of address duplication is quite low if most of
>>> the /128 bits are randomly generated and so a node may skip
>>> address uniqueness test. However, address uniqueness detection /
>>> resolution is a requirement when smaller prefixes are used and
>>> also in military & other critical MANET application scenarios.
>>> The address uniqueness detection / resolution should be done
>>> across the entire  network thus requiring that the specific
>>> broadcast/multicast messages used for this purpose be propagated
>>> "even to MANET Routers that are multi-hop away". Currently there
>>> is no standard specification that addresses this requirement.
>> I think I'd suggest that when the MANET network uses subnets with 
>> well-defined link-layer multicast behaviour then the duplication
>> should be ensured by DAD.  If the MANET network doesn't use such
>> subnets, or uses SBI (semi-broadcast interface) then the address
>> uniqueness detection should be indeed done across the semi-subnets
>> (maybe define semi-subnet).
>> 
>> Or maybe that address uniqueness should be _ensured_ across the
>> entire MANET network, probably with a detection mechanism that acts
>> on a scope lesser than the entire MANET network.
> 
> I think it needs to be done across the network. Not sure why you 
> suggest to use some detection mechanism to act on a scope lesser than
>  the entire network. May be for performance optimization ?

Not for performance optimization, just to say that DAD acts on the
well-define Ethernet link scope.  That is supposedly lesser scope than
MANET scope.  But I'm not sure you mean that MANET scope is lesser scope
than Ethernet, or the same scope, or wider scope.

If we say that MANET scope is same as Ethernet link scope then DAD can
work on MANET scope.

If we say MANET scope can contain several Ethernet link scopes then one
would do DAD on each of these links, each link would be a subnet.

If we say that Ethernet scope can contain several MANET scopes then IP
DAD would not work.

Alex


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


_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf