Re: [nemo] new requirement for draft-ietf-nemo-requirements

Alexandru Petrescu <alexandru.petrescu@motorola.com> Mon, 04 December 2006 15:48 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrG3C-0004Nw-5J; Mon, 04 Dec 2006 10:48:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrG3A-0004NS-Fh for nemo@ietf.org; Mon, 04 Dec 2006 10:48:13 -0500
Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrG38-0007GQ-4g for nemo@ietf.org; Mon, 04 Dec 2006 10:48:12 -0500
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@motorola.com
X-Msg-Ref: server-7.tower-128.messagelabs.com!1165247287!5126851!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.100]
Received: (qmail 15318 invoked from network); 4 Dec 2006 15:48:07 -0000
Received: from motgate.mot.com (HELO motgate.mot.com) (129.188.136.100) by server-7.tower-128.messagelabs.com with SMTP; 4 Dec 2006 15:48:07 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motorola) with ESMTP id kB4Fm6Pf022810; Mon, 4 Dec 2006 08:48:06 -0700 (MST)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id kB4Fm2qJ010738; Mon, 4 Dec 2006 09:48:04 -0600 (CST)
Message-ID: <45744331.90300@motorola.com>
Date: Mon, 04 Dec 2006 16:48:01 +0100
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [nemo] new requirement for draft-ietf-nemo-requirements
References: <45743493.3010403@piuha.net>
In-Reply-To: <45743493.3010403@piuha.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: IETF NEMO WG <nemo@ietf.org>, Ross Callon <rcallon@juniper.net>
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>
Errors-To: nemo-bounces@ietf.org

Jari Arkko wrote:
> Hi all,
> 
> We reviewed this draft in the IESG, and Ross raised a requirement 
> that he thinks is important but is not listed in the current 
> document. It is about the effect to the Internet routing tables. 
> Please find a suggested edit below. We thought that this change is 
> large enough that the WG needs to be consulted, even if the 
> requirement is fulfilled by NEMO BSP. So, if you have a problem with
>  this change let us know by the end of the week (Dec 8th).

For me the change is welcome and am surprised this text isn't already
in the draft, because we discussed precisely this at large, and I think
reflects common thinking here.  There's a req approaching this idea
(3.7. 'Scalability') which could be extended with this text.

This is also to mention that apart from the NEMOv6 protocol, and apart
from this requirements document, this requriement may be challenged in
certain contexts, especially knowing that network mobility with BGP has
been shown to be working for a small setting.

Alex

> 
> NEW Section 3.12:
> 
> 3.12  Minimal Impact on Internet Routing
> 
> Any NEMO solution(s) needs have minimal negative effect on the global
>  Internet routing system. The solution must therefore limit both the
>  amount of information that must be injected into Internet routing,
> as well as the dynamic changes in the information that is injected
> into the global routing system.
> 
> As one example of why this is necessary, consider the approach of 
> advertising each mobile network's connectivity into BGP, and for 
> every movement withdrawing old routes and injecting new routes. If 
> there were tens of thousands of mobile networks each advertising and
>  withdrawing routes, for example, at the speed that an airplane can 
> move from one ground station to another, the potential effect on BGP 
> could be very unfortunate. In this example the total amount of 
> routing information advertised into BGP may be acceptable, but the 
> dynamic instability of the information (ie, the number of changes 
> over time) would be unacceptable.
> 
> NEW requirement to be added to the end of Section 4:
> 
> R17: The solution should have a minimal impact on the global Internet
>  routing system.
> 
> 
>