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

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

El 06/12/2006, a las 19:29, Vijay Devarapalli escribió:

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

:-)
good point

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

agree... but i think this sentence was there

just checked, and it was there in a previous version, that stated that: 
" All solutions will aim at
   preserving route aggregation within the Internet"

but it was removed, perhaps it is a good idea to keep it in the new 
charter...

regards, marcelo


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