Subject: About route aggregation in global HAHA (was Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal)

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 4 Apr 2006 13:44:33 +0300

Hi all,

global HAHA draft states in section 5.1.1  External routing

    In return, each site advertises the aggregation that encompasses the
    Distributed Home Network aggregation back into the service provider
    network, to the outside world (the internet).

So, the (distributed) home network prefix is announced through BGP and 
this implies that each Home Network prefix will impact with an 
additional route in the global BGP table, all agree?

The question at this point is whether this is a reasonable model

Let's see what the current practise in IPv6 is.
As today, the reccommendation is that only ISPs can announce their 
blocks in BGP.
In particular, end sites are discouraged to do that, in  particular, 
multihomed sites have to find an alternative solution rather than rely 
on BGP.
Moreover, as today, there is no RIR policy that allows an end site to 
get their own address space. Only Provider aggregatable address is 
being handed out by the RIRs.

Now, as is read this proposal, it implies that each distributed home 
netwrok will need a prefix that is separately announced in the global 
BGP table. Now, the question is if this is in line with current 
tendency to consider global routing scalability as a top priority.
As i see it, there must be a very important reason to push a solution 
that relies on this approach, and i really would like to understand why 
the support of globally distributed HAs requires such approach.

I mean one could think of an approach to support gloablly distributed 
HAs that do not require having the home network prefix injected 
separately in the global BGP table.
In particular, one could envision a solution where each HA has its own 
prefix block, belonging to the ISPs aggregate and that the mobile node 
prefers to use the address of the closest HA to initiate new 
communications. This with a route optimization solution should provide 
similar benefits.

Regards, marcelo

El 30/03/2006, a las 22:07, Vijay Devarapalli escribió:

>
>> That's /8 or less, from less than 10 points.  Here we talk
>> /24 or more
>> (there are 255 /8 prefixes, while there are 16777216 /24s).
>> And mobiles
>> can be attached to much more than just 10 points.  No one could ever
>> advertise that large number of routes from that many parts of
>> Internet,
>> not even two parts.
>>
>> Worse with IPv6, where we talk /32 (usual operator boundary) vs /64
>> prefixes (Ethernet end-user boundary).  /64 prefixes are much more
>> numerous than IPv4 /24 prefixes.
>
> you shouldnt be advertising /64 mobile network
> prefixes. only aggregated home prefixes. but yes,
> it could still be a problem.
>
> Vijay
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Apr 2006 15:01:03 +0200

marcelo bagnulo braun wrote:
> So, the (distributed) home network prefix is announced through BGP 
> and this implies that each Home Network prefix will impact with an 
> Let's see what the current practise in IPv6 is. As today, the 
> reccommendation is that only ISPs can announce their blocks in BGP. 
>  multihomed sites have to find an alternative solution rather than 
> rely on BGP.

Additionally, I think that even if two routes are announced in the BGP
for same prefix, it's insured that the final destination of these two
routes are in the _same_ physical place (same end user).

Or, global HAHA claims its strengths in having a HA close to the point
wherever the mobile may be, with HAs placed in various parts of the 
Internet.  I.e. global HAHA requires the use of a multiply-announced BGP
prefix that eventually ends in _different_ places.

>  netwrok will need a prefix that is separately announced in the
> global BGP table. Now, the question is if this is in line with
> current tendency to consider global routing scalability as a top
> priority. As i see it, there must be a very important reason to push
> a solution that relies on this approach, and i really would like to
> understand why the support of globally distributed HAs requires such
> approach.
> 
> separately in the global BGP table. In particular, one could envision
>  a solution where each HA has its own prefix block, belonging to the
>  ISPs aggregate

Would you elaborate on this perspective?  How would an "ISP aggregate"
be able to be present anywhere in the world where the mobile may roam?

As a side note, do you think an "ISP aggregate" could outnumber all the
ISPs present out there?  If the media talks about some merger between
two large ISPs and then calls that "the largest combined ISP in the
world" do you really think that ISP covers the entire Internet?  I am
sure not.

"Large" ISP in terms of number of subscribers is different than "large"
in terms of square kilometers covered, because population density varies
so much.  A single cellular ISP in China may be bigger than all biggest 
western ISPs if we talk subscriber count, but of course much smaller 
than Iridium if we talk square kilometer count.

> and that the mobile node prefers to use the address of the closest HA
> to initiate new communications.

How would a mobile _know_ which HA is "closest"?  IP "distance" is
an unreliable variable, nowhere defined.

Maybe you meant that the BGP network will direct the BU to the HA that 
the network thinks it's closer, without MN involvement in the choice?

> This with a route optimization solution should provide similar
> benefits.

An RO solution gets its first packets through HA and then straight to 
CN, thus eliminating HA from the path.  Doesn't need global HAHA.

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 4 Apr 2006 16:43:03 +0300

Hi Alex,

> routes are in the _same_ physical place (same end user).

well, there are some configurations that use this, basically anycast 
services, like DNS infrastucutre

> prefix that eventually ends in _different_ places.

exactly, but i am not sure if this is a problem w.r.t. the scalability 
of the global routing system.
I mean, do you think that there is a difference w.r.t. routing system 
scalability in the case that it is a single multihomed site that 
announces the same prefix through multiple links to the internet, or a 
multiple seperate sites announcing the same prefix?

> be able to be present anywhere in the world where the mobile may roam?

see below...

> world" do you really think that ISP covers the entire Internet?  I am

actually by ISP aggregate i meant the ISP prefix (which aggregates all 
the prefixes of the ISP's customers), so i guess we only have a 
terminology misunderstanding here..

> so much.  A single cellular ISP in China may be bigger than all 
> biggest western ISPs if we talk subscriber count, but of course much 
> smaller than Iridium if we talk square kilometer count.
>

I haven't thought this approach completelly but i was thinking 
something in these lines.

Suppose that a mobile network wants to use 4 HA that are geographically 
distributed.
Each of these 4 home networks obtain a topologically meaningful prefix 
from the ISP prefix (which does not need to be announced seprately 
since it is part of the ISP prefix)
Suppose that the monet gets a home network prefix from each of the Home 
networks

Now, the goal at this point would be to use an address from the home 
network prefix that is closer to the monet in a certain moment in time 
to initiate new communications. If the node in the monet is able to 
choose the right address, then it will be using the HA that is closer 
to the monet achieving similar benefits to the ones obtained by the 
global HAHA in terms of round trip time, agree?

So in order to do that, the gaol would be for the MR to measure the 
distance with the different HA and inform the mobile network nodes to 
preffer the prefix that is associated to the HA that is closer.

In order to measure the distance with the HA, there are several 
possibilities as you mention below. One option would be to listen to 
BGP and use the AS-path length. this is probably not the best measure. 
Other option is to send probes and measure the RTT, which is likely to 
obtain better results than the BGP based technique.
In order to inform the hosts about which address to preffer, it could 
easily do that by deprecating the prefixes of the HAs that are far away 
and only leave the one of the closets HA as preferred. This would make 
that all the new communications to be initiated with the address 
associated to the closest HA

There is an underlying assumption here that the movement is slow, 
comparing distance and HAs. I mean, that in most of the cases, the 
address preferred when the communication is initiated will be good 
enough during all the lifetime of the communication. So the solution 
works better in this case. I think this is the case for the airplane 
case presented, since even while the airplane moves very fast, it 
doesn't changes that often of attachment point to the internet, soi it 
doesn't need to change the HA that often (compared with the lifetime of 
the communication)

> CN, thus eliminating HA from the path.  Doesn't need global HAHA.

Well, i hope it is clearer now what i had in mind.
So there are two cases that additional work is needed:
- one case is for communication that lasts for long and it was 
initiated with the address associated with a previous HA. In this case, 
this communication would not benefit from the closest HA. So in this 
case we need an additional RO to optimize this situation. But this is 
only for a reduced set of communications, so we can use something like 
host based RO, like MIPv6 based RO for this particular nodes.
- another case that needs to be taken into account is incoming 
communications. I guess that most of the application cases the mobile 
network nodes are clients, rather than servers, but in any case, it 
would be worthy to consider this case. The problem here is that the CN 
is the one selecting the address, so it may well choose not the  
address corresponding to the closest HA. For this cases, we also need 
some form of host based RO.

So, i guess this would work fine for outgoing communications that are 
not very long lived. But my feeling is that these are the most of the 
traffic to be expected in many scenarios, like planes and buses and 
trains.

For the other communications  a RO optimization mechanism is needed

So i see this as an approach that is complementary with a RO solution, 
makes any sense to you?

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Apr 2006 19:35:17 +0200

>  services, like DNS infrastucutre

yes, right, but infrastructure not edge fringes.

>> Or, global HAHA claims its strengths in having a HA close to the 
>> point wherever the mobile may be, with HAs placed in various parts
>>  of the Internet.  I.e. global HAHA requires the use of a 
>> multiply-announced BGP prefix that eventually ends in _different_ 
>> places.
> 
> exactly, but i am not sure if this is a problem w.r.t. the 
> scalability of the global routing system. I mean, do you think that 
> there is a difference w.r.t. routing system scalability in the case 
> that it is a single multihomed site that announces the same prefix 
> through multiple links to the internet, or a multiple seperate sites
>  announcing the same prefix?

Yes, while it's feasible to multi home a few yearly-changing
short prefixes it's infeasible to multi home several minutely-changing 
long prefixes.

>>> Moreover, as today, there is no RIR policy that allows an end 
>>> site to get their own address space. Only Provider aggregatable 
>>> address is being handed out by the RIRs. Now, as is read this 
>>> proposal, it implies that each distributed home netwrok will need
>>>  a prefix that is separately announced in the global BGP table. 
>>> Now, the question is if this is in line with current tendency to
>>>  consider global routing scalability as a top priority. As i see
>>>  it, there must be a very important reason to push a solution
>>> that relies on this approach, and i really would like to
>>> understand why the support of globally distributed HAs requires
>>> such approach. I mean one could think of an approach to support 
>>> gloablly distributed HAs that do not require having the home 
>>> network prefix injected separately in the global BGP table. In 
>>> particular, one could envision a solution where each HA has its 
>>> own prefix block, belonging to the ISPs aggregate
>> 
>> Would you elaborate on this perspective?  How would an "ISP 
>> aggregate" be able to be present anywhere in the world where the 
>> mobile may roam?
>> 
> 
> see below...
> 
>> As a side note, do you think an "ISP aggregate" could outnumber all
>>  the ISPs present out there?  If the media talks about some merger
>>  between two large ISPs and then calls that "the largest combined 
>> ISP in the world" do you really think that ISP covers the entire 
>> Internet?  I am sure not.
>> 
> 
> actually by ISP aggregate i meant the ISP prefix (which aggregates 
> all the prefixes of the ISP's customers), so i guess we only have a 

We should make sure that when we rely on an aggregated prefix advertised
in core to solve mobility problems we don't also secretly assume
specific prefixes being advertised too.

>> "Large" ISP in terms of number of subscribers is different than 
>> "large" in terms of square kilometers covered, because population 
>> density varies so much.  A single cellular ISP in China may be 
>> bigger than all biggest western ISPs if we talk subscriber count, 
>> but of course much smaller than Iridium if we talk square kilometer
>>  count.
>> 
>>> and that the mobile node prefers to use the address of the 
>>> closest HA to initiate new communications.
>> 
> 
> Suppose that a mobile network wants to use 4 HA that are 
> geographically distributed. Each of these 4 home networks obtain a 
> topologically meaningful prefix from the ISP prefix (which does not 
> need to be announced seprately since it is part of the ISP prefix) 
> Suppose that the monet gets a home network prefix from each of the 
> Home networks

So the monet gets 4 prefixes?  4 potential Home Addresses for LFNs?

>  network prefix that is closer to the monet in a certain moment in 
> time to initiate new communications. If the node in the monet is able
>  to choose the right address, then it will be using the HA that is 
> closer to the monet achieving similar benefits to the ones obtained 
> by the global HAHA in terms of round trip time, agree?

I think I get the picture.  This looks feasible.  MR may try to identify
which MNP (out of the 4) to use for its Home Address.

But this comes down to when MR moves in a different geographical area
stop all its communications (LFNs' too) and then use another Home
Address and start new communications.  Ongoing apps stopped.  Is this an 
accepted assumption? (that no session continuity is required)

We've discussed this at some point in the mip4 WG.  They have the
Dynamic HA Assignment draft, now maybe an RFC.  It was stressed that is
about an initial assignment of the Home Address and that it wouldn't be
about session continuity.

And, if it's agreed that a globalHAHA-like solution is ok to not offer
session continuity then the paradox is that one wouldn't need globalHAHA
at all - it's sufficient for MR to _discover_ a local HA, obtain a
"local" Home Address and all is fine.

Which is: instead of pre-configuring 4 HAs do HA discovery.  GlobalHAHA
wouldn't be needed (i.e. no need of BGP route injection nor multi-homing).

>  BGP and use the AS-path length.

I see, sounds as a good tool.  It assumes though that MR will be exposed
to the core BGP.  An ISP for /24 end-users avoids that.  But depends on
the picture of course.

> Other option is to send probes and measure the RTT, which is likely 
> to obtain better results than the BGP based technique.

Yes, to write that we'd need routing experts involved.

> easily do that by deprecating the prefixes of the HAs that are far
> away and only leave the one of the closets HA as preferred. This
> would make that all the new communications to be initiated with the
> address associated to the closest HA

Ok.

> doesn't changes that often of attachment point to the internet, soi 
> it doesn't need to change the HA that often (compared with the 
> lifetime of the communication)

I think this is right.

I think in the case of commercial airline jet liners, sea liners and 
similar the problem is even more simple because trajectories are well 
known.  They are planned.  Points of connection are well known in 
advance, there'd be little need to "discover" HA or to probe paths.

>> Maybe you meant that the BGP network will direct the BU to the HA 
>> that the network thinks it's closer, without MN involvement in the
>>  choice?
>> 
>> An RO solution gets its first packets through HA and then straight
>>  to CN, thus eliminating HA from the path.  Doesn't need global 
>> HAHA.
>> 
> 
> Well, i hope it is clearer now what i had in mind. So there are two 
> cases that additional work is needed: - one case is for communication
>  that lasts for long and it was initiated with the address associated
>  with a previous HA. In this case, this communication would not 
> benefit from the closest HA. So in this case we need an additional RO
>  to optimize this situation. But this is only for a reduced set of 
> communications, so we can use something like host based RO, like 
> MIPv6 based RO for this particular nodes. - another case that needs 
> to be taken into account is incoming communications. I guess that 
> most of the application cases the mobile network nodes are clients, 
> rather than servers, but in any case, it would be worthy to consider
>  this case. The problem here is that the CN is the one selecting the
>  address, so it may well choose not the  address corresponding to the
>  closest HA. For this cases, we also need some form of host based RO.
> 
> 
>  not very long lived. But my feeling is that these are the most of 
> the traffic to be expected in many scenarios, like planes and buses 
> and trains.

I think once we accept that most communications are short lived then we 
can assume that Mobile IP is not needed at all.  There exist widely 
deployed end-user applications that offer an illusion of "session 
continuity" without using Mobile IP, with reachability at a permanent 
address and all that.  If we don't use Mobile IP and still offer users 
an idea of "session continuity" which s/he's ready to accept then the 
whole HA concept is not needed, so even less GlobalHAHA.

> So i see this as an approach that is complementary with a RO 
> solution, makes any sense to you?

I'm trying to, and understood most of the points you made.

I think that what is needed by deployments is the most important thing. 
  I think that if we have some set of scenarios from some people who 
wish to deploy the global HAHA tech (with an eventual description of the 
network topology) and some reasons to use Mobile IP then we'll get 
closer to delimiting the globalHAHA problem statement.

Sorry for the too long text,

Alex

---

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

Hi Alex
On 2006/04/04, at 22:01, Alexandru Petrescu wrote:

>> In return, each site advertises the aggregation that encompasses  
>> the Distributed Home Network aggregation back into the service  
>> provider network, to the outside world (the internet).
>> reccommendation is that only ISPs can announce their blocks in  
>> BGP. In particular, end sites are discouraged to do that, in   
>> particular,

VPN can be used.
Did you read draft-wakikawa-mip6-nemo-haha-spec-01.txt?
We describe the various Home Agent configurations.

> prefix that eventually ends in _different_ places.

For global HAHA, it is not necessarily to use BGP. Any routing  
protocol can be used.
Of course, one example is BGP to obtain globally scale route  
optimization.

ryuji

>>  get their own address space. Only Provider aggregatable address  
>> is being handed out by the RIRs.
> the
> "large"
> biggest western ISPs if we talk subscriber count, but of course  
> much smaller than Iridium if we talk square kilometer count.
>
> to CN, thus eliminating HA from the path.  Doesn't need global HAHA.
>
> Alex
>

---

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

> yes, right, but infrastructure not edge fringes.

absolutely

> short prefixes it's infeasible to multi home several minutely-changing 

completely agree, but my point is that this is because stress on the 
global routing table (due to additional entries and the dynamic of such 
entries) rather than because they are seperate sites announcing the 
same prefix. I mean, having many long prefixes of multihomed sites that 
appear and disapear would cause a similar effect even if they are 
announced by a single site connected through multiple points to the 
internet

>>>> Moreover, as today, there is no RIR policy that allows an end site 
>>>> to get their own address space. Only Provider aggregatable address 
>>>> is being handed out by the RIRs. Now, as is read this proposal, it 
>>>> implies that each distributed home netwrok will need
>>>> particular, one could envision a solution where each HA has its own 
>>>> prefix block, belonging to the ISPs aggregate

completely agree

>>>> and that the mobile node prefers to use the address of the closest 
>>>> HA to initiate new communications.

yes, like any multihomed site that gets PA addresses from their 
upstream providers

> which MNP (out of the 4) to use for its Home Address.

yes

> Address and start new communications.  Ongoing apps stopped.

well, no, because you still can get the packets arriving to the 
previous HA, because there is still the tunnel between the MR and the 
old HA (i mean, it is not like the MR can use only one HA at the time)

The problem is that as the MR moves away from a given HA, the delay in 
the communication that are being routed through the HA increases.

The MR will have 4 tunnels with 4 different HAs. It can communicate 
through all of them (if they are working of course), and it can receive 
packets addressed to the HoAs of each HA.
The point is that one of the HAs will be closer to the MR, so this 
would be the preferred one for starting new communications.

As the MR moves, the preferred MR can change. this doesn't means that 
the previous preferred HA becomes unreachable, or that the 
communications thorugh the previous HA need to be interrupted, just 
that there is a HA that would provide better performance for new 
communications.

It may well be the case that communication through previous HA get 
really log delays, that is why i think that a host based RO mechanism 
could be a good complement to this approach

>  Is this an accepted assumption? (that no session continuity is 
> required)
>

i think this is different. Here you have session continuity, it is just 
that the perfromance can be poor and you may want to use additional RO 
tools to overcome this limitation

> "local" Home Address and all is fine.

see above

> wouldn't be needed (i.e. no need of BGP route injection nor 

I think that supporting multiple HAs in paralel allows to softly moving 
from one HA to another one, since the MR can evaluate that it is 
approaching to a different HA and start using the new for new 
communications, but still preserving the sessions established using the 
previously preferred HA

> to the core BGP.  An ISP for /24 end-users avoids that.  But depends on

agree

> Yes, to write that we'd need routing experts involved.

not sure why do you think so... probing to different Has seems quite 
straight forward to me... what complexities do you see?

> advance, there'd be little need to "discover" HA or to probe paths.

makes sense to me

> I think once we accept that most communications are short lived then 
> we can assume that Mobile IP is not needed at all.  There exist widely 
> I think that what is needed by deployments is the most important 
> thing.  I think that if we have some set of scenarios from some people 
> who wish to deploy the global HAHA tech (with an eventual description 
> of the network topology) and some reasons to use Mobile IP then we'll 
> get closer to delimiting the globalHAHA problem statement.
>

well i was taking as a starting point the problem presented by the 
boeing people and what they are currently doing in the planes to 
provide connectivity

this seems a real problem with a suboptimal expensive solution in IPv4 
today, and i think that it would be important to provide an better 
solution than what they are doing today.

my goal was to try to figure out a solution that has no impact in the 
global routing table and that it fullfills their needs

regards, marcelo

---

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

> We describe the various Home Agent configurations.

The draft has no text "VPN".  How can the VPN concepts be used?

Since we've already discussed the draft when it was initially announced, 
I am open to discuss any scenario that is described inside.  Just 
explain one.

> For global HAHA, it is not necessarily to use BGP. Any routing protocol 
> can be used.
> Of course, one example is BGP to obtain globally scale route optimization.

I am talking about route in the core Internet towards the current CoA, I 
think you're talking about routes to the HoA.

Alex

---

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

marcelo bagnulo braun wrote:
> entries) rather than because they are seperate sites announcing the same 
> prefix. I mean, having many long prefixes of multihomed sites that 
> yes, like any multihomed site that gets PA addresses from their upstream 
> providers
> 
> well, no, because you still can get the packets arriving to the previous 
> HA, because there is still the tunnel between the MR and the old HA (i 
> mean, it is not like the MR can use only one HA at the time)
> 
> The point is that one of the HAs will be closer to the MR, so this would 
> be the preferred one for starting new communications.
> 
> communications thorugh the previous HA need to be interrupted, just that 
> there is a HA that would provide better performance for new communications.
> 
>>  Is this an accepted assumption? (that no session continuity is required)
>>
> boeing people and what they are currently doing in the planes to provide 
> connectivity

I'd have reserves.  The reports from the aviation industry seem to talk 
about systems that cover large geographical areas but are still very 
small closed systems.

When the aviation industry says they wouldn't like the plane over US to 
connect to the HA in EU it's because the satelite link is slow, not 
because EU is far from US (even if they connected to the HA placed in 
the US instead - that would still be slow, because of the slow first-hop 
satelite link).

> solution than what they are doing today.

Having a customer for a potential document is very important, helps 
delimiting the scope.

We should discuss too whether netlmm type of solutions are adapted to 
that customer's type of problem.

> global routing table and that it fullfills their needs

Easiest thing would be to get from them whether their system needs to 
connect to the Internet or not, and how, in the first place.  If the 
system connects to the Internet with a single exit point then there's no 
question of impact on the global routing table.

Alex

---

From: "Dul, Andrew L" <[email-masked]>
Date: Wed, 5 Apr 2006 09:23:19 -0700

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Wednesday, April 05, 2006 8:41 AM

> > global routing table and that it fullfills their needs

I think any solution will have some impact, but the trick is to make it
a globally scalable impact.

> 
> Easiest thing would be to get from them whether their system 
> needs to connect to the Internet or not, and how, in the 
> first place.  If the system connects to the Internet with a 
> single exit point then there's no question of impact on the 
> global routing table.
> 

I think this is a question for me...

I think you can assume that the aircraft will have a connection to the
Internet both for passenger services as well as other crew services.  I
also think you have to assume that for Internet services we will have to
use multiple ISPs.  

I believe Global-HAHA can be scalable if the individual BGP prefixes are
not injected into the global BGP table.  However, to still achieve
reasonable route optimization one would likely have to push this routing
complexity in to the operational world by requiring transit
relationships between HA's which are operated by different ISPs.  My
concern is that the operational complexity will create an environment
where global-haha cannot succeed for aircraft and other globally mobile
platforms. 

Another option would be to split the network identifier & locator.
There probably should be a bit of thinking about if this would be the
best way to go, not just for mobile networks but for BGP scaling in
general.  This was briefly discussed at the grow/shim6 group last month.

http://www.ietf.org/proceedings/06mar/slides/grow-1.pdf
http://ietfreport.isoc.org/idref/draft-ietf-ipngwg-gseaddr/ 

An aircraft of the future will also likely have connections to other
closed networks.  Those networks may have different mobility/scaling
problems compared to the Internet and thus the solutions there may be
completely different.

Andrew

---

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

El 05/04/2006, a las 18:40, Alexandru Petrescu escribió:

> I'd have reserves.  The reports from the aviation industry seem to 
> talk about systems that cover large geographical areas but are still 
> very small closed systems.
>
> When the aviation industry says they wouldn't like the plane over US 
> to connect to the HA in EU it's because the satelite link is slow, not 
> the US instead - that would still be slow, because of the slow 
> first-hop satelite link).
>
>> this seems a real problem with a suboptimal expensive solution in 
>> IPv4 today, and i think that it would be important to provide an 
>> better solution than what they are doing today.
>
> system connects to the Internet with a single exit point then there's 
> no question of impact on the global routing table.
>

Yes, i think that we should first really understand what they need and 
then try to provide a solution. Perhaps a good input to the wg would a 
description of their requirements (not limited to the aviation but to 
devices that move globally, like ships, planes)

regards, marcelo

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 06 Apr 2006 14:25:28 +0800

> devices that move globally, like ships, planes)

That is an excellent idea.  That would certainly indicates to us what
kind of route optimization schemes (if any) is needed more.

And on a related note, I wonder what are the providers/operators view on
route optimization?

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 6 Apr 2006 10:19:31 +0300

El 05/04/2006, a las 19:23, Dul, Andrew L escribió:
> Internet both for passenger services as well as other crew services.

By crew services are you talking about air traffic and navigation 
control traffic? i.e. critical traffic? (in the sense that the 
integrity of the airplane depends on it)

If this is the case, but wouldn't these be routed through different 
mechanisms? I mean, i guess you won't share the same channel between 
the web browsing of one passenger and the communication to the control 
of the airport.

Imho this distinction is quite important because they are likely to 
have very different QoS requirements

>  I

ok

> not injected into the global BGP table.

what do you call individual prefixes?
I mean, as i understand it, if you want to use global HAHA with 
multiple ISPs, you need to inject the distributed home prefix through 
the different ISPs, which imho precludes the routing system 
scalability,
so are you considering the distributed home prefix is not an individual 
prefix, or do you envision some way of running global HAHA wihtout 
injecting the dsitributed home prefix in bgp or other option that i 
missing?

regards, marcelo

>   However, to still achieve

---

From: "Dul, Andrew L" <[email-masked]>
Date: Fri, 7 Apr 2006 10:29:41 -0700

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Thursday, April 06, 2006 12:20 AM
> To: Dul, Andrew L
> Cc: ml-nemo WG; [email-masked]
> Subject: Re: About route aggregation in global HAHA (was 
> Re:draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter 
> proposal)
> 
> 
> By crew services are you talking about air traffic and 
> navigation control traffic? i.e. critical traffic? (in the 
> sense that the integrity of the airplane depends on it)

In this case I wasn't talking about critical traffic.  I was thinking about services for the crew that would allow them to communicate with their operations center for things like re-ticketing...etc.

Critical infrascturcture may likely use IPv6 too in the future, but will operate on closed networks.  They will likely still have mobility issues, but those are different from the mobility issues to access the Internet.

> 
> If this is the case, but wouldn't these be routed through 
> different mechanisms? I mean, i guess you won't share the 
> same channel between the web browsing of one passenger and 
> the communication to the control of the airport.
> 
> Imho this distinction is quite important because they are 
> likely to have very different QoS requirements

Yes, critical vs. non-critical will have very different requirements.

> > I believe Global-HAHA can be scalable if the individual BGP 
> prefixes 
> > are

Let say I have lots of aircraft and I assign each of them a /48 out of a /32.  The individual prefixes would be the /48 for each aircraft.  For a simple case with 2 HA's each in a different ISP.  If both ISPs announce the /32 via BGP but carry the /48 addresses internally, then the Internet doesn't see the /48s and reaches the aircraft via closest ISP announcing the /32.  I believe this is scalable because you are limiting the /48s to inside of autonomous systems.  This scheme requires the two ISP to cooperate and exchange MN state information between themselves.  If ISP "A" receives a packet for a MN that is currently being served by ISP "B" then it must forward the packet to ISP "B".

Andrew

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Apr 2006 20:39:42 +0200

Thanks for the example!

Dul, Andrew L wrote:
> Let say I have lots of aircraft and I assign each of them a /48 out
> of a /32.  The individual prefixes would be the /48 for each
> aircraft.  For a simple case with 2 HA's each in a different ISP.  If
> both ISPs announce the /32 via BGP but carry the /48 addresses
> internally, then the Internet doesn't see the /48s and reaches the
> aircraft via closest ISP announcing the /32.

Interesting.  Put this way looks ok scalable, no BGP route injection for 
mobility.

However, three things.  One is that 48-32 one can acommodate only 65536 
aircraft :-)

The second is that CN may be closer to ISP1 than ISP2 (MR under ISP2) 
and ISP2 may be closer to CN than to ISP1.  In which case, the fact that 
CN sends to ISP1 (because global HAHA) instead of ISP2 is not optimal at 
all.  It should have sent to ISP2 instead.

In general, one has some expectancies about how the two ISPs are 
distanced from each other, but it's more difficult to predict the 
placement of the CN with respect to ISPs.

Third, if the two ISPs are tightly linked together somehow (because they 
advertise same /32) then it would be sufficient for them to run route 
updates between them to point exactly where the /48 is, thus avoiding 
core-BGP injections _and_ Mobile IP tunnelling.

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 10 Apr 2006 10:07:36 +0300

El 07/04/2006, a las 20:29, Dul, Andrew L escribió:
> Let say I have lots of aircraft and I assign each of them a /48 out of 
> a /32.  The individual prefixes would be the /48 for each aircraft.  
> For a simple case with 2 HA's each in a different ISP.  If both ISPs 
> announce the /32 via BGP but carry the /48 addresses internally, then 
> the Internet doesn't see the /48s and reaches the aircraft via closest 
> ISP announcing the /32.  I believe this is scalable because you are 
> limiting the /48s to inside of autonomous systems.  This scheme 
> requires the two ISP to cooperate and exchange MN state information 
> between themselves.  If ISP "A" receives a packet for a MN that is 
> currently being served by ISP "B" then it must forward the packet to 
> ISP "B".
>

still you need one bgp table slot for this /32 which is not a LIR i.e. 
not PA addressing used here, which is a consumption of the global 
resources. In other words, the number of routes added by this approach 
grows linearly with the number of distributed home networks. This 
definitely better than a solution that adds one bgp entry per moving 
network, but still consumes global bgp slots

Now, this may be ok, but, imho we need to understand whether there are 
acceptable solutions that do not consume such resource, like for 
instance other types of RO mechanisms. Clearly and end to end RO 
mechanism do not consume any bgp slot since it is end to end and uses 
PA addressing. Now maybe the RO solutions do not fit the aircraft 
scenario requirements, but i still need to be convinced that this is 
the case.

Hence, i would propose (again) that we first identify which are the 
requirements for this scenario and then evaluate different solutions.

bottom line is why is the charter only considering the global HAHA tool 
as a possible RO solution and does not takes into account other RO 
solutions?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 10 Apr 2006 10:12:27 +0300

El 07/04/2006, a las 21:39, Alexandru Petrescu escribió:

> Interesting.  Put this way looks ok scalable, no BGP route injection 
> for mobility.
>

well, we still need to inject one bgp route per distributed home 
network, right?

...
>
> Third, if the two ISPs are tightly linked together somehow (because 
> they advertise same /32) then it would be sufficient for them to run 
> route updates between them to point exactly where the /48 is, thus 
> avoiding core-BGP injections _and_ Mobile IP tunnelling.
>

good point,

basically if the aircraft already knows what ISPs it will be visiting 
and it has some commercial arrangement with it, it is likely that the 
ISP can accept routes from the aircraft when it is visiting, so no 
mobile is required whatsoever

I guess that the bottom line is that the trust/commercial model in the 
case of an aircraft visiting an ISP is different from the one assumed 
in mobile IP. I mean, i guess we can assume a much more higher level of 
trust between the aircraft and the visited ISP, so that route injection 
is an option (we can see that from boeing presentation, i guess)

regards, marcelo

---

From: "Dul, Andrew L" <[email-masked]>
Date: Fri, 14 Apr 2006 10:49:30 -0700

> well, we still need to inject one bgp route per distributed 
> home network, right?

I think I'm getting confused on the terminology.  I tried going back to the nemo-terminology draft but that didn't help...  :(

We need to inject at least 1 BGP route.  Theoretically all mobile nodes could be aggregated into a single route, however that isn't likely.  The best case that I see happening is an aggregated prefix per "mobile-network operator".  Where a "mobile network operator" is responsible for the provisioning an providing service to a large number of mobile platforms.  

Make sense?

> > avoiding core-BGP injections _and_ Mobile IP tunnelling.

Advertising BGP routes between providers certainly is an option, but the complexity can really grow when there are more than two providers.  My concern about that is that you are now seperating the mobility signalling between the NEMO and BGP.  It seems like it would be easier operationally if your mobility signalling was in one protocol not two. 

> 
> good point,
> 
> basically if the aircraft already knows what ISPs it will be 
> visiting and it has some commercial arrangement with it, it 
> is likely that the ISP can accept routes from the aircraft 
> when it is visiting, so no mobile is required whatsoever
> 
> I guess that the bottom line is that the trust/commercial 
> model in the case of an aircraft visiting an ISP is different 
> from the one assumed in mobile IP. I mean, i guess we can 
> assume a much more higher level of trust between the aircraft 
> and the visited ISP, so that route injection is an option (we 
> can see that from boeing presentation, i guess)
> 

I can see there being a higher level of trust as you describe.  Route injection could be an option.  I don't necessarily think that is the best option though.  Route injection similar to what we are doing today requires a high level of integration between ISPs.  

Andrew

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 18 Apr 2006 14:06:54 +0300

El 14/04/2006, a las 20:49, Dul, Andrew L escribió:

> I think I'm getting confused on the terminology.  I tried going back 
> to the nemo-terminology draft but that didn't help...  :(
>
> We need to inject at least 1 BGP route.  Theoretically all mobile 
> nodes could be aggregated into a single route, however that isn't 
> likely.  The best case that I see happening is an aggregated prefix 
> per "mobile-network operator".  Where a "mobile network operator" is 
> responsible for the provisioning an providing service to a large 
> number of mobile platforms.
>
> Make sense?
>

I guess that the in order to evaluate a solution that consumes common 
resources (like this one that burns global bgp table slots) we need to 
evaluate:
- number of resource consumed and
- need for the particular solution

So far we have discussed different deployment models that have impact 
on the resources consumed.
We have the mobile ISP model, where there seems to be a few global 
consortiums that provide internet connectivity for aircrafts. In this 
model, the number of routing slots burned seem to be quite limited

the other option is that local ISPs host home agents for different 
airlines, in which case each airline would have its own distributed 
home network prefix and the number of routing table slots burned would 
increase if internet access becomes a comodity (and more when they 
start to use such apporach for other globally moving devices, like 
ships )

So, i guess we really need to asses the cost that this apporach will 
imply for the community in term of routing slots

The second issue is why this solution and not other alternatives, that 
may not have this cost (and that may have another cost for the 
particular end site)
The justification for this would be that this solution fits best the 
requiremetns which unfortunatelly are not documented afaict, which 
makes it very hard to figure out if another solution would solve this 
problem....

regards, marcelo

> Advertising BGP routes between providers certainly is an option, but 
> the complexity can really grow when there are more than two providers. 
>  My concern about that is that you are now seperating the mobility 
> signalling between the NEMO and BGP.  It seems like it would be easier 
> operationally if your mobility signalling was in one protocol not two.
>
>>
>> good point,
>>
> I can see there being a higher level of trust as you describe.  Route 
> injection could be an option.  I don't necessarily think that is the 
> best option though.  Route injection similar to what we are doing 
> today requires a high level of integration between ISPs.
>
>
> Andrew
>
>
>