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

[marcelo bagnulo braun <[e-mail]>]

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.
>>>
>>>
>>
>>
>>
>
>