Re: [nemo] WG Last Call on draft-ietf-nemo-terminology

Romain KUNTZ <kuntz@sfc.wide.ad.jp> Mon, 21 November 2005 02:45 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee1gN-0000sX-UL; Sun, 20 Nov 2005 21:45:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ee1gM-0000rx-ST for nemo@megatron.ietf.org; Sun, 20 Nov 2005 21:45:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27694 for <nemo@ietf.org>; Sun, 20 Nov 2005 21:44:50 -0500 (EST)
Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ee1yh-0003gO-MO for nemo@ietf.org; Sun, 20 Nov 2005 22:04:26 -0500
Received: from [10.0.1.196] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id C33104CAFA for <nemo@ietf.org>; Mon, 21 Nov 2005 11:45:14 +0900 (JST)
Message-ID: <43813545.9070804@sfc.wide.ad.jp>
Date: Mon, 21 Nov 2005 11:47:33 +0900
From: Romain KUNTZ <kuntz@sfc.wide.ad.jp>
Organization: Keio University
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: nemo <nemo@ietf.org>
Subject: Re: [nemo] WG Last Call on draft-ietf-nemo-terminology
References: <E1EV94s-0000Iv-L1@newodin.ietf.org> <20051028155154.719167e5.ernst@sfc.wide.ad.jp> <20051117192750.7b7688d8.ernst@sfc.wide.ad.jp> <437D339F.3010305@sfc.wide.ad.jp> <1132280807.4927.14.camel@localhost>
In-Reply-To: <1132280807.4927.14.camel@localhost>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org

Hello Chan-Wah,

Chan-Wah Ng wrote:
>>A split NEMO occurs when a single mobile subnet connected to multiple 
>>Mobile Routers, or multiple mobile subnets interconnected with routers, 
>>become two or more independant mobile subnets.
> 
> 
> "independent".
> 
> Anyway, "multiple mobile subnets interconnected with routers" is not
> very accurate and leads to controversy.  Consider
> 
>     MR1            MR1
>      |              |
>   ---+-+---  =>   --+---   MR2
>        |                    |
>       MR2                 --+--
>        |
>     ---+----
> 
> It fits your definition but does not falls into the normal sense of
> split NEMO.

That's right.


>>     |             |          |       |
>>    MR1  Router   MR2        MR1     MR2
>>     |    |  |     |    ->    |       |
>>   --------  -------        -----   -----
>>
> 
> 
> With a router, presumably a LFR, in between, the two links are separate
> subnets.   So, MR1 and MR2 are handling different prefixes.  When the
> two links goes separate way, what would happens is that the LFR would no
> longer function as a router, since it loses its at least one of its link
> for forwarding.
> 
> As far as NEMO-BS is concerned, this situation also does not fall into
> the normal sense of split-NEMO problem, because MR1 and MR2 are handling
> different prefixes, even when they split, there is no ambiguity in the
> HA(s) on who to forward a packet destined for one of the MNPs to.

Correct. I do not know what I had in mind when drawing this :-)
I was thinking about MR2 registering some of MR1 prefixes for redundancy 
purposes, but this has no relations with current NEMO-BS.

> It all depends on what is the motivation for the inclusion of the
> split-NEMO definition.  I thought the motivation was to assist in
> illustrating the problem of split NEMO as documented in
> draft-ietf-nemo-multihoming-issues.  If this is indeed the case, then
> the definition of split-NEMO should define cases only when the problem
> of split NEMO occurs.

I agree. So do you see other case than (n,1,1) with the following topology:


     |    |             |      |
    MR1  MR2           MR1    MR2
     |    |      ->     |      |
   ----------         -----  -----

(ie multiple MRs attached to the same mobile subnet on their ingress 
interface, registering the same prefix to the same HA)

where split NEMO is a problem?

Romain