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

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Dec 2006 16:45:39 +0200

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.

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 5 Dec 2006 00:36:53 +0900

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Dec 2006 17:47:14 +0200

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.

--Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Dec 2006 16:48:01 +0100

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

For me the change is welcome and am surprised this text isn't already
in the draft, because we discussed precisely this at large, and I think
reflects common thinking here.  There's a req approaching this idea
(3.7. 'Scalability') which could be extended with this text.

This is also to mention that apart from the NEMOv6 protocol, and apart
from this requirements document, this requriement may be challenged in
certain contexts, especially knowing that network mobility with BGP has
been shown to be working for a small setting.

Alex

> 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,
> 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 
> 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.
> 
> R17: The solution should have a minimal impact on the global Internet
>  routing system.
> 
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Dec 2006 16:50:04 +0100

RYUJI WAKIKAWA wrote:
>  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.

I would keep this for future enhancements of the reqs document, or other
reqs document.  For now the reqs document with this requirements added
(Ross proposals) make perfect sense to me.

Alex

> regards, ryuji
>> 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:
>> 
>> 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.
>> 
>> 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.
>> 
>> R17: The solution should have a minimal impact on the global 
>> Internet routing system.
>> 
>> 
> 
> 
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 4 Dec 2006 17:31:31 +0100

Hi,

> 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

>>> both
>>> can
>>> routing

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Dec 2006 19:22:16 +0200

Alex,
> been shown to be working for a small setting.
It indeed works, and works quite well, in a small setting.
There is no debate about that, but I think everyone agrees
that when we have tens of thousands of networks like that
then we have to do something else. My back-of-the-envelope
calculations indicated that running all of commercial airliners
with this scheme would roughly double global BGP update
traffic.

In any case, I don't think anyone needs to challenge the
requirement as such -- the intention was not to claim
that in small scale this would be a problem.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Dec 2006 19:24:34 +0200

Hi Marcelo,
> then the number of announced routes increases considerably and i am
> not sure if thi contribution to the global routing tables is acceptable.
I see.
> understand what is the intended deployment scenarios for global HAHA
Ok.

--Jari

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 5 Dec 2006 02:25:50 +0900

Hi Marcelo,

On 2006/12/05, at 1:31, marcelo bagnulo braun wrote:

> 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  

This is too detail to discuss at this point. This is operational issue.

> prefix that aggregates all the home networks from different end  
> sites, then, this seems similar to the provider aggregation

The global HAHA does not recommend to advertise each prefix separately.
We have the home network usage document to deploy home network in  
aggregated fashion.

> understand what is the intended deployment scenarios for global  
> HAHA and if those scale well.

right. What i want to know now is the answer from Jari.
We can discuss any further NEMO related protocols with this requirement.

ryuji

>>> maybe

---

From: "Davis, Terry L" <[email-masked]>
Date: Mon, 4 Dec 2006 10:24:23 -0800

Jari

Ross makes an excellent point!  I think that Geof's statistics showed
that Connexion by Boeing with just about 200 aircraft (mobile networks)
in service, we were 21st in forced routing table updates already.

Take care
Terry

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Monday, December 04, 2006 6:46 AM
> To: IETF NEMO WG
> Cc: Ross Callon
> Subject: [nemo] new requirement for draft-ietf-nemo-requirements
> 
> Hi all,
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 5 Dec 2006 15:41:53 +1100

Jari, 

It's hard to disagree with the requirement. As you say the current solution
doesn't break this requirement so it might only be useful for future work,
but it's fine to have it. 

Hesham 

 > Sent: Tuesday, December 05, 2006 1:46 AM
 > To: IETF NEMO WG
 > Cc: Ross Callon

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 06 Dec 2006 10:29:55 -0800

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:
> 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.
> 
> understand what is the intended deployment scenarios for global HAHA and 
> if those scale well.
> 
> Regards, marcelo
> 
> 
>> --Jari
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 6 Dec 2006 19:40:19 +0100

> not for any route optimization solution that might

:-)
good point

> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Dec 2006 19:41:04 +0100

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

>>> 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.
>>> 
>> 
>>  then the number of announced routes increases considerably and i 
>> am not sure if thi contribution to the global routing tables is 
>> acceptable.
>> 
>>>> 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
>>>> 
>>>> 
>>>>> 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 
>>>>> 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.
>>>>>

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 7 Dec 2006 12:52:44 +0100

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

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

-- 
Thierry ERNST, PhD
http://www.nautilus6.org/~thierry
IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair
--
INRIA Rocquencourt Project-Team IMARA, France.
+33 1 39 63 59 30 (office)

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 8 Dec 2006 14:37:21 -0800

Maybe I have lost too much context on NEMO, but I thought the base protocol does support dynamic routing protocols between the MR and HA to update the MNPs. In that case, any routing changes to the MNPs are expected to propagate via the routing protocols to the rest of the network. 

I would not expect these updates to be as frequently changing as in the RO case, but, nevertheless, the capability for propagation through routing protocols does exist. 

Independent of this, the requirement suggested by Ross seems perfectly reasonable to me. 

Vidya 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, December 06, 2006 10:30 AM
> To: marcelo bagnulo braun; [email-masked]
> Cc: IETF NEMO WG
> Subject: Re: [nemo] new requirement for draft-ietf-nemo-requirements
> 
> Marcelo and Alex,
> 
> 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
> 
> >> 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 
> 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.
> > 
> >>> maybe in future.
> >>> fashion, but dynamic change of BGP entries is not occurred.
> >>>
> >>> regards,
> >>> ryuji
> >>>
> >>>
> requirement 
> approach of

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Dec 2006 12:29:20 +0200

Thanks for your responses. I added a note to the
RFC Editor to insert the requirement. Ross, I believe
you can clear your Discuss now. Thanks.

I will also look at the new charter with the
chairs and consider if it needs to say something
about this, or if the reference to this RFC will
be enough.

--Jari