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

[Alexandru Petrescu <[e-mail]>]

Vijay Devarapalli wrote:
> 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.

Yes, I read the Ross req very fine within the current req document, the
one he reviewed.  I agree with it.

> but it is in the wrong document. :)

You mean we may need another reqs document?  Or in the RO existing
documents? (ps, ro space).

> perhaps we can add a sentence to the charter saying that any route 
> optimization solution should have minimal impact on Internet routing.
> 
I think that's difficult.  Charter saying "minimal" may be too fuzzy.
What's minimal for you isn't for me.

> then the requirement becomes really applicable to any route 
> optimization solution.

YEs, that requirement should be more worked out, I think finer
description (than what current req doc has, and the Ross req suggestion).

For example, the Marcelo req about advertising aggregates (provider
aggregates) instead of MNP-based routes is a sort of refinement that may
make sense.  I so think.

Alex

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