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

Vijay Devarapalli <vijay.devarapalli@azairenet.com> Wed, 06 December 2006 18:30 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs1Wr-0004Dq-1Y; Wed, 06 Dec 2006 13:30:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs1Wq-0004Dk-1b for nemo@ietf.org; Wed, 06 Dec 2006 13:30:00 -0500
Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs1Wo-0002fX-Jd for nemo@ietf.org; Wed, 06 Dec 2006 13:30:00 -0500
Received: from [10.1.210.17] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 10:29:57 -0800
Message-ID: <45770C23.5080307@azairenet.com>
Date: Wed, 06 Dec 2006 10:29:55 -0800
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: marcelo bagnulo braun <marcelo@it.uc3m.es>, alexandru.petrescu@motorola.com
Subject: Re: [nemo] new requirement for draft-ietf-nemo-requirements
References: <45743493.3010403@piuha.net> <28F4D755-55C4-4DBD-AF93-729A30EE9E3B@gmail.com> <45744302.5030502@piuha.net> <3ff5d001ae78906b9c8337fc0378ae46@it.uc3m.es>
In-Reply-To: <3ff5d001ae78906b9c8337fc0378ae46@it.uc3m.es>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 06 Dec 2006 18:29:57.0262 (UTC) FILETIME=[88023AE0:01C71964]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Cc: IETF NEMO WG <nemo@ietf.org>
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

Marcelo and Alex,

note that draft-ietf-nemo-requirements only lists
requirements for the NEMO Basic support protocol
not for any route optimization solution that might
come out of the NEMO WG.

the requirement by itself is fine with me. but it
is in the wrong document. :) perhaps we can add a
sentence to the charter saying that any route
optimization solution should have minimal impact on
Internet routing. then the requirement becomes
really applicable to any route optimization solution.

Vijay

marcelo bagnulo braun wrote:
> Hi,
> 
> 
> El 04/12/2006, a las 16:47, Jari Arkko escribió:
> 
>> I have not looked into HAHA yet, but from your
>> description below it does not seem to cause
>> routing problems. It is common to advertise
>> prefixes from multiple locations.
>>
> 
> agree that this is common, but announcing a specific routing entry for 
> each home network (i.e. end site, not ISP)  does seem to pose 
> scalability issues for the routing system, imho
> 
> I mean, we have discussed this before in this ml. If global HAHA is 
> deployed as a global mobility provider i.e. there is a single home 
> prefix that aggregates all the home networks from different end sites, 
> then, this seems similar to the provider aggregation
> However, if each home network of each nemo is announced seaprately, then 
> the number of announced routes increases considerably and i am not sure 
> if thi contribution to the global routing tables is acceptable.
> 
> Anyway, i think the requirement is perfectly ok, we just need to 
> understand what is the intended deployment scenarios for global HAHA and 
> if those scale well.
> 
> Regards, marcelo
> 
> 
>> --Jari
>>
>> RYUJI WAKIKAWA kirjoitti:
>>> Hi Jari,
>>>
>>> I want to make sure one item whether it breaks new requirements or not.
>>>
>>> We have been discussing multiple HAs usage (global-haha) in NEMO WG.
>>> It is not clear yet whether we will pick this in a WG item, but maybe
>>> in future.
>>> This global HAHA advertises block of home prefixes to BGP in anycast
>>> fashion,
>>> but dynamic change of BGP entries is not occurred.
>>>
>>> regards,
>>> ryuji
>>>
>>>
>>> On 2006/12/04, at 23:45, 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).
>>>>
>>>> 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.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 
>