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

[Thierry Ernst <[e-mail]>]

I need to correct a wrong statement:

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

This is half true half wrong. Section 4 in draft-ietf-nemo-requirements
lists the requirements behind NEMO Basic Support (RFC 3963 to be
explicit), but section 3 lists design goals for all sort of NEMO
solutions (Basic AND Extended, i.e. RO optimizations and the like).


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

There is no need to add anything in the charter besides may be adding a
sentence that solutions developped by the NEMO WG will have to comply
with design goals as stated in RFC{draft-ietf-nemo-requirements}.

Thierry.

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


-- 
Thierry ERNST, PhD
http://www.nautilus6.org/~thierry
IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair
--
INRIA Rocquencourt Project-Team IMARA, France.
[phone] (office)