Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal)

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 5 Apr 2006 11:44:50 +0900

On 2006/03/31, at 3:17, Vijay Devarapalli wrote:

>
>>> The good news is that TJ's revised charter has a line that
>> could cover
>>> these discussions:
>>> Aug 2006          Submit -00 draft on Route Optimization for
>>> geographically distributed HAs
>>>
>>
>> right, but the proposed charted also states that:
>>
>> The WG will:
>>
>> - Ensure that solutions will scale and function for the different
>> mobile network configurations, without requiring changes to
>> Correspondent Nodes in the Internet. All solutions will aim at
>> preserving route aggregation within the Internet and will satisfy an
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> acceptable level of security (a thorough survey of new threats and an
>> analysis of their severity will be conducted for any changes
>> introduced
>> to the network).
>>
>> I guess one of the points Andrew is pointing out is exactly with
>> respect to this issues, namely:
>>
>>>> Even if you had global-haha implemented it would require
>> multiple ASNs
>>>> to announce the mobile platform's address space.  That would likely
>>
>> how would this affect aggregation?
>
> it is very common today to advertise reachability
> to a particular network from different points in
> the Internet.

Yes. This is common operation these days.

> ofcourse, I do agree that route aggregation should
> be preserved.

We have NEMO home network models document:-)

ryuji

> Vijay
>
>>
>> imho we should first discuss and figure out if the operational
>> practices resulting from such a solution are acceptable before
>> chartering the work. I mean we should first figure out at least if
>> there seems to be a viable approach that fulfills the needs and
>> preserves scalability of the routing system
>>
>> Regards, marcelo
>>
>>
>>> We can propose global HAHA as a candidate, compete with
>> other proposals
>>> and try to keep the best from all.
>>>
>>> Pascal
>>>
>>
>>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 5 Apr 2006 13:20:59 +0300

> Yes. This is common operation these days.

in the v4 internet, you mean?

In v6 there is no RIR policy that allows an end site to obtain a prefix 
to announce it to the internet

only Provider Aggregatable prefixes are allocated to LIRs (ISPs), so 
that they can announce a single prefix covering all its providers.

trying to announce an end site prefix to the global routing table seems 
to be against current efforts to preserve the scalability of the global 
routing table, and should be very well justified imho

Regards, marcelo

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 5 Apr 2006 06:59:37 -0400

On Apr 5, 2006, at 6:20 AM, marcelo bagnulo braun wrote:

> In v6 there is no RIR policy that allows an end site to obtain a  
> prefix to announce it to the internet
>

Yet.

There are two ARIN proposals, 2005-1 and 2006-4, to allow this on the  
table for Montreal. If you
are interested, you might want to join the discussion on the ppml list.

Regards
Marshal Eubanks

> only Provider Aggregatable prefixes are allocated to LIRs (ISPs),  
> so that they can announce a single prefix covering all its providers.
>
> trying to announce an end site prefix to the global routing table  
> seems to be against current efforts to preserve the scalability of  
> the global routing table, and should be very well justified imho
>
> Regards, marcelo
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 5 Apr 2006 14:12:48 +0300

> are interested, you might want to join the discussion on the ppml list.

indeed, but this exactly refers to what i am arguing for.

routing system scalability is a major concern and the community is 
taking this very seriously. Solutions that inject additional routes to 
the global routing table are analyzed in depth and very important 
reasons need to be presented in order to accept them
I guess that the discussion in the ppml list proves that, there have 
been years of discussion, several times the proposal was presented and 
rejected and studied in more depth

this is why i think that we need to be very carefull in proposing 
solutions that contribute with additional entries in the global routing 
table and we need to make sure that we have compelling reasons to do 
so. i don't thionk we are quite there yet in HAHA

regards, marcelo

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 5 Apr 2006 20:18:29 +0900

> so that they can announce a single prefix covering all its providers.

Policy is policy.

> the global routing table, and should be very well justified imho

I don't think it effects the scalability of the global routing table.

We shouldn't prohibit this network configuration.
DNS anycast is already operated in IPv4. It can be operated for IPv6,  
too.
We don't have in mind that /64 prefixes will be used for HAHA.  This  
should be prohibited, but aggregated prefix is possible.

The problem you raised here is all about operations.
It is important to deliver protocol spec for operators who want to  
deploy globally scalable system (ex. haha).

ryuji

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 5 Apr 2006 14:39:13 +0300

> I don't think it effects the scalability of the global routing table.

what do you mean? The global HAHA solution requires (for geographically 
distibuted HAs in different sites) to inject a seperate prefix. How 
does this preserves the scalability of the routing system?
the number of entries on the global routing system grows linearly with 
the number of distributed home networks

It is exactly the same argument that for multihomed sites. It is not 
scalable because their contribution to the bgp global table is linear 
with the number of multihomed sites.

> We shouldn't prohibit this network configuration.

IETF cannot prohibit configurations i guess
but i still don't think we should endorse it by standarizing it

> DNS anycast is already operated in IPv4. It can be operated for IPv6, 

yes, right, but imho root dns servers are much more critical than 
distributed home networks

> should be prohibited, but aggregated prefix is possible.

how would you achieve aggregation?

> deploy globally scalable system (ex. haha).

again, how is global haha scalable?
I have pointed out that the contribution of global haha to the DFZ is 
linear with the number of distributed home networks, this is not 
scalable by my definition

from the wikipedia:

A routing protocol is considered scalable with respect to network size, 
if the size of the necessary routing table on each node grows as O(log 
N), where N is the number of nodes in the network.

so linear is not scalable

regards, marcelo

---

From: "Davis, Terry L" <[email-masked]>
Date: Wed, 5 Apr 2006 08:13:02 -0700

Ryuji/Marcelo

I would hope that we are NOT designing protocol based on RIR policy!  These do change.

And by definition, a mobile network platform (aircraft/ship) is going to create "route churn" unless you are willing accept declining QOS and increasing congestion/cost as you move further from your home port/base.

I might also point out that if you are planning on designing a protocol based on the current PA policy, although the protocol might work, the implementation would most likely fail, at least for those of us that actually move the links to our mobile platforms (ships & planes) between continents.  I'm not aware of an ISP that provides service on all continents, and in all countries, and at all airports and ports.

I think a global mobility architecture requires ISP independence in its design.

Also to make a fully functional global mobility service, I think we will need to finally get around to defining "Internet Docking" as an aircraft could easily need to "dock" with a dozen or more ISP's in a single day.  Today I get to "enjoy the benefits" of NAT at every airport; I would hope that this is not our future vision either?

Finally I'll comment that I can NEVER ever envision anyone building "critical infrastructure" based on the existing PA policy.  Down the road, we are "considering" whether to use IP based links for the next global air traffic management system.  In that context, consider this:
- Would you like your airline to switch providers while you are on their aircraft at 35,000 feet over the North Pacific?
- Or while you just coming in to land at 5 PM in rain storm to JFK?

How far do you willing to trust "re-addressing"?

Take care

Terry L Davis, P.E.
IP & Security Aircraft Architect
Boeing Commercial Airplanes

Formerly:
Chief Network Engineer
Connexion by Boeing

> -----Original Message-----
> From: Ryuji Wakikawa [mailto:[email-masked]]
> Sent: Wednesday, April 05, 2006 4:18 AM
> To: marcelo bagnulo braun
> Cc: Pascal Thubert (pthubert); T.J. Kniveton; Davis, Terry L; ml-nemo WG;
> Vijay Devarapalli
> Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter
> proposal)
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Apr 2006 17:16:06 +0200

> We have NEMO home network models document:-)

Itself having issues.  We discussed some of them recently here.  IIRC 
it's still not clear how a MR returning home may "match" a prefix (the 
home prefix) by checking it being shorter than its MNP.

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 6 Apr 2006 09:02:42 +0300

Hi Terry,

> I would hope that we are NOT designing protocol based on RIR policy!  

no, my point about policy was merely to refute arguments that seemed to 
imply that is common to have end sites injecting their own prefix as 
seperate entries in bgp. this is not the case in today's IPv6 internet.

The goal is to design protocols based on fundamental principles like 
routing system scalability, which are long lasting

> And by definition, a mobile network platform (aircraft/ship) is going 
> to create "route churn" unless you are willing accept declining QOS 
> and increasing congestion/cost as you move further from your home 
> port/base.
>

I don't follow your argument.

You can perfectly envision route optimization mechanisms that allow you 
to support mobility with enhanced performance wihtout any kind of 
impact in the global routing. See the RO document for a compilation of 
many of those approaches. Of course this implies additional work in the 
edges, but that is what scalability is about, moving load from the core 
to the edges

> I might also point out that if you are planning on designing a 
> protocol based on the current PA policy, although the protocol might 
> work, the implementation would most likely fail, at least for those of 
> us that actually move the links to our mobile platforms (ships & 
> planes) between continents.  I'm not aware of an ISP that provides 
> service on all continents, and in all countries, and at all airports 
> and ports.
>

But that is exactly the point, not needing a single ISP. I think that 
it would be worth exploring the possibility of having different ISPs, 
each one of them providing their own address block, and build a system 
that supports changing from one address block to another. Such a system 
wouldn't have any impact in the global routing table

> I think a global mobility architecture requires ISP independence in 

Why do you think that?

i think RO schemes can support global mobility without need for ISP 
independent addresses being injected in the DFZ

I mean with a RO scheme, the HA is simply a rendez vous point and after 
the initial contact has been achieved, you can just move to RO mode, 
where the direct communication will flow.
If to that you add that you can have multiple HAs in different 
locations, each one with their own address block, i think the result 
may be worth exploring

> Also to make a fully functional global mobility service, I think we 
> will need to finally get around to defining "Internet Docking" as an 
> aircraft could easily need to "dock" with a dozen or more ISP's in a 
> single day.  Today I get to "enjoy the benefits" of NAT at every 
> airport; I would hope that this is not our future vision either?
>
> Finally I'll comment that I can NEVER ever envision anyone building 
> "critical infrastructure" based on the existing PA policy.  Down the 
> road, we are "considering" whether to use IP based links for the next 
> global air traffic management system.

ok, i think we are mixing things here (or at least i am not following 
this now)

I mean, i think there are two different kinds of traffic here:
- one is the traffic of the machines that hook up inside the nemo of 
the plane. This are basically people that are communicating with the 
rest of the internet doing web, email or any kind of other stuff. This 
is not critical traffic, in the sense that in general, neither the life 
of people is at stake nor the health of the Internet depends on that. 
This traffic can suffer from different delays, but of course the 
service needs to be acceptable. I think it is somehow acceptable to 
have handovers delays, like in any other internet communication
- the other type of traffic is the traffic control traffic, signalling 
of the airplane control and so on, which is definitely critical. 
However, this is very different type of traffic, since i guess the 
communicating parties are very well detemrined and closed. For this 
case, i don't think it makes sense to treat it as normal internet 
traffic. I guess you should have direct links with the earth 
infrastructure in order to communicate with all the guarantees 
required. So, for this type of traffic, i fail to see why do you need 
global internet reachability (probably because of security reasons, 
this is likely (i hope) to be a closed system and reachability is 
limited to the trusted parties). So no need to inject global routes for 
this case.

>   In that context, consider this:
> - Would you like your airline to switch providers while you are on 
> their aircraft at 35,000 feet over the North Pacific?

No, but all this is the second type of traffic, that i defeinitly 
expect to be routed inside a closed secured network, separated from the 
internet, with private links.

Regards, marcelo