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

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 4 Apr 2006 15:53:13 -0700

Marcelo,

you have to consider two things.

first, MIPv6 and NEMO are based on the concept 
of the mobile node and mobile router having the
same home address and maintaining session
continuity without changing the home address.
this means for HAHA, the mobile router should
have the same home address irrespective of which
home agent (from the bunch of home agents that
serve its home network) it attaches to.

second, it is not realistic to assume the mobile
router can figure out which home agent it is
closest to based on IP hops, round trips, etc..
these are not always reliable ways of measuring
distance from each home agent.

Vijay

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Tuesday, April 04, 2006 6:43 AM
> To: Alexandru Petrescu
> Cc: Pascal Thubert (pthubert); Davis, Terry L; T.J. Kniveton; 
> Vijay Devarapalli; ml-nemo WG
> Subject: Re: About route aggregation in global HAHA (was Re: 
> draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal)
> 
> Hi Alex,
> 
> 
> El 04/04/2006, a las 16:01, Alexandru Petrescu escribió:
> 
> > marcelo bagnulo braun wrote:
> >> 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.
> >
> > 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).
> >
> 
> well, there are some configurations that use this, basically anycast 
> services, like DNS infrastucutre
> 
> > 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?
> 
> >
> >> 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 
> terminology misunderstanding here..
> 
> > "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.
> >
> 
> 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)
> 
> > 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.
> >
> 
> 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
> 
> > Alex
> >
> 
>

---

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

Hi Vijay,

> continuity without changing the home address.

agree

> serve its home network) it attaches to.

depends what you are looking for

from the presentation from boeing, it seemed to me that their goal was 
to use the HA that is closer to the current location of the MR. It is 
not a problem of fault tolerance, but rather a problem of performance. 
I don't think that the general case there are many long lived 
communications, but rather some how short lived communications 
(compared to the time required to change the geographical area covered 
by one of the HAs). So it makes sense to use MIP because the CoA is 
changing, so you want to preserve communications through CoA changes, 
but i guess that is not so common to have communications that last 
longer than the time required to change HA. for scuh communications 
additional host based RO mechanisms can be used

however, i think i more and more agree with Alex here, perhaps we need 
to figure out what are the exact requirements that we are trying to 
address

personally, i see that general fault tolerance support for multiple 
distributed HA and using the HA that is closer to the current location 
of the MR can be tackled with different tools.... i mean, the first 
case is just a multihomed site that is attached to multiple points in 
the internet...

> distance from each home agent.

not sure what difficulties you here, i mean defining a probe protocol 
between the MR and the HA shouldn't be hard...

regards, marcelo

---

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

marcelo bagnulo braun wrote:
>> first, MIPv6 and NEMO are based on the concept of the mobile node
>> and mobile router having the same home address and maintaining
>> session continuity without changing the home address.
> 
> agree
> 
>> this means for HAHA, the mobile router should have the same home
>> address irrespective of which home agent (from the bunch of home
>> agents that serve its home network) it attaches to.
>> 
> 
> from the presentation from boeing, it seemed to me that their goal
> was to use the HA that is closer to the current location of the MR.
> It is not a problem of fault tolerance, but rather a problem of
> performance.

I think there is some misunderstanding here...

It is true that in general any mobile needs to connect to the system
that is closer to it.  But the HA concept was never designed to be close
to the mobile, instead it was designed to be able to serve its mobile
wherever it may be, especially far away cases.

It may be the case that the boeing presentation may actually not need
Mobile IP at all, and its HA.

Connecting to the access point closest to the mobile, and having all
access points linked together can easily offer session continuity
without Mobile IP.

In general, I am not at all sure where Mobile IP is needed in a closed
(or small) system.

> (compared to the time required to change the geographical area
> covered by one of the HAs). So it makes sense to use MIP because the
> CoA is changing, so you want to preserve communications through CoA
> changes, but i guess that is not so common to have communications
> that last longer than the time required to change HA. for scuh
> communications additional host based RO mechanisms can be used
> 
> however, i think i more and more agree with Alex here, perhaps we
> need to figure out what are the exact requirements that we are trying
> to address
> 
> distributed HA and using the HA that is closer to the current
> location of the MR can be tackled with different tools.... i mean,
> the first case is just a multihomed site that is attached to multiple
> points in the internet...
> 
>> second, it is not realistic to assume the mobile router can figure
>> out which home agent it is closest to based on IP hops, round
>> trips, etc.. these are not always reliable ways of measuring 

It's a probe that draws a conclusion about the intermediary network 
topology, which may vary a lot after the probe... I think in the routing 
wisdom these kinds of probing across large domains are considered 
useless... eliminating the variance of the topology (get a more precise 
idea about who's closer) involves even more probes, which adds to the 
load itself...

Alex

---

From: "Dul, Andrew L" <[email-masked]>
Date: Wed, 5 Apr 2006 10:03:04 -0700

> from the presentation from boeing, it seemed to me that their 
> goal was to use the HA that is closer to the current location 
> of the MR. It is not a problem of fault tolerance, but rather 
> a problem of performance. 

True, one of our main objectives was performance not fault tolerance.

> communications, but rather some how short lived 
> communications (compared to the time required to change the 
> geographical area covered by one of the HAs). So it makes 
> sense to use MIP because the CoA is changing, so you want to 
> preserve communications through CoA changes, but i guess that 
> is not so common to have communications that last longer than 
> the time required to change HA. for scuh communications 

Just one example...we needed to ensure that if you had a VPN session
established your connection wouldn't break when we changed satellites &
ground stations from Europe to Asia.  If you were using host based MIP
on the airplane your next upstream network does not change, rather the
transport network between the plane and the ground changes.

---

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

> wherever it may be, especially far away cases.

agree, but it is also true that if the HA is far away in the topology, 
then the resulting performance can be really bad, if all the traffic 
needs to flow through the HA (which is the current nemo case where 
there is no RO support). So trying to switch to a more direct path 
makes sense (how do we do this, is a different story of course)

> In general, I am not at all sure where Mobile IP is needed in a closed

yes, but from other comments, i understood that they have different 
ISPs in different locations, so it is far from being a closed system. 
They seem to be a mobile network that gets connectivity from different 
providers as it moves, so proabably they need something like mobile IP 
that supports moving through different providers

> topology, which may vary a lot after the probe... I think in the 
> routing wisdom these kinds of probing across large domains are 
> considered useless... eliminating the variance of the topology (get a 
> more precise idea about who's closer) involves even more probes, which 
> adds to the load itself...
>

well, their current option is AS path length which doesn't seems to be 
a very accurate metric in any case. While i agree that probes may not 
be accurate, i am not sure how inaccurate they are if you compare it 
with AS path length metric.
In any case, i guess that as you say, having more probes can improve 
the precision, with a cost. OTOH, they are running BGP today, and this 
implies quite some traffic, with the BGP session and the BGP 
keepalives, so, perhaps it may ok to analyze how acceptable probes are.

regards, marcelo

---

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

> transport network between the plane and the ground changes.

ok, but in this case, i guess the micro/localized mobility solutions 
should provide support for this.
Basically what is happening here is that the plane is moving its 
attachment point inside a closed domain, as Alex was mentioning, so 
localized mobility mechanisms should work here.
So agree that there is no need for MIP to support this case, but i 
guess the a solution like global HAHA doesn't buy you anything neither. 
Moreover, i don't understand how injecting a PI prefix would provide 
better performance than using a PA block from the global provider.... i 
mean, the global provider prefix is being injected through all the 
points where the global provide attaches to the internet, so, the CN 
will reach the global provider through the point that is closer to the 
CN and then the traffic will be routed through the internal global ISP 
network

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Apr 2006 17:02:29 +0200

marcelo bagnulo braun wrote:
>> It is true that in general any mobile needs to connect to the
>> system that is closer to it.  But the HA concept was never designed
>> to be close to the mobile, instead it was designed to be able to
>> serve its mobile wherever it may be, especially far away cases.
>> 
> 
> agree, but it is also true that if the HA is far away in the
> topology, then the resulting performance can be really bad, if all
> the traffic needs to flow through the HA (which is the current nemo
> case where there is no RO support).

... _if_ Mobile IP is used.  One can build moving networks without
Mobile IP, and still offer continuous sessions or reachability at a more
permanent address.

I'm trying to say that when we have an clear idea about the aviation
topology, requirements, points of control then we can decide whether or
not we need Mobile IP for aviation.

The word "Mobile" in Mobile IP makes people tend to think that all that
moves and connects to Internet should use Mobile IP.  That's not true.

>> In general, I am not at all sure where Mobile IP is needed in a
>> closed (or small) system.
>> 
> 

If they control all these ISPs it all becomes a "closed" system, 
manageable by a single entity.  If the aviation industry _can_ say to 
ISP1 "please place a HA here" to ISP2 "please place a HA there" then it 
means that they can already tell ISPs what to do.

And if they can do that, then they can also tell ISPs "ISPs please 
exchange routes about the MR when you sense it in your location".  And 
if the ISPs exchange these routes then no need of Mobile IP.

If however the ISPs are reluctant to place mutually trusted HAs, or if 
the ISPs are not straighlty connected together (connected without BGP) 
then they won't be able to place HAs nor to exchange routes.

To say that if ISPs can place HAs at different places then they can also 
exchange routes; and if they can exchange routes then no Mobile IP, no HA.

> They seem to be a mobile network that gets connectivity from
> different providers as it moves, so proabably they need something
> like mobile IP that supports moving through different providers

IMHO no no; if the providers can use Mobile IP for different HAs then
they can also exchange routes. If they can't exchange routes then they
can't place HAs either.

_If_ there's a link (physical) between the ISPs which doesn't influence 
the global routing tables then it is possible for the ISPs to exchange 
routes directly, again no Mobile IP.

>>> covered by one of the HAs). So it makes sense to use MIP because
>>> the CoA is changing, so you want to preserve communications
>>> through CoA changes, but i guess that is not so common to have
>>> communications that last longer than the time required to change
>>> HA. for scuh communications additional host based RO mechanisms
>>> can be used however, i think i more and more agree with Alex
>>> here, perhaps we need to figure out what are the exact
>>> requirements that we are trying to address personally, i see that
>>> general fault tolerance support for multiple distributed HA and
>>> using the HA that is closer to the current location of the MR can
>>> be tackled with different tools.... i mean, the first case is
>>> just a multihomed site that is attached to multiple points in the
>>> internet...
>>>> second, it is not realistic to assume the mobile router can
>>>> figure out which home agent it is closest to based on IP hops,
>>>> round trips, etc.. these are not always reliable ways of
>>>> measuring distance from each home agent.
>>> not sure what difficulties you here, i mean defining a probe
>>> protocol between the MR and the HA shouldn't be hard...
>> 
>> considered useless... eliminating the variance of the topology (get
>> a more precise idea about who's closer) involves even more probes,
>> which adds to the load itself...
>> 
> 
> well, their current option is AS path length which doesn't seems to
> be a very accurate metric in any case. While i agree that probes may
> not be accurate, i am not sure how inaccurate they are if you compare
> it with AS path length metric. In any case, i guess that as you say,
> having more probes can improve the precision, with a cost. OTOH, they
> are running BGP today, and this implies quite some traffic, with the
> BGP session and the BGP keepalives, so, perhaps it may ok to analyze
> how acceptable probes are.

What is the risk of probing giving a false indication?  It nullifies the 
entire goal of global HAHA.  I wouldn't risk the main requirement of a 
protocol on this kind of unreliable probe.  If the probing were just a 
hint, in addition to other info, then yes.

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 7 Apr 2006 08:42:34 +0300

El 06/04/2006, a las 18:02, Alexandru Petrescu escribió:

> manageable by a single entity.

if all the ISPs involved are peering directly this may be easy, but if 
they are not, they need to start configuring tunnels between them to 
pass the routing information and the situation becomes rather messy and 
hard to manage imho (but i agree that is an option... see more below)

>  If the aviation industry _can_ say to ISP1 "please place a HA here" 
> to ISP2 "please place a HA there" then it means that they can already 
> tell ISPs what to do.
>

but are you assuming that the nemo has its own PI prefix or not?

- if it has its own PI prefix, this is basically what has been 
presented in the slides by boeing, that is what they are currently 
doing. the problem with this is that each nemo adds an additional entry 
to the global routing table and they depend on BGP convergence times 
(which won't be that good if they keep on adding routes i am afraid)

- if the nemo do not have its own PI prefix, then it has a PA prefix 
from one of the ISP, which means that the traffic from the internet to 
the nemo is always routed through that particular ISP, which in the 
case that the CN and the nemo are topologically far away from that ISP, 
then the resulting performance may be pretty bad i guess

That is why, i think that a solution that support some form of RO would 
be good for this case (mixed with having multiple PA prefixes, in order 
to reduce the need for using the RO solution)

> then they won't be able to place HAs nor to exchange routes.

well, if they are not directly connected they may dtill be willing to 
place HAs

In addition, it is also possible that the ground infrastructure has 
internet access, so that the HA can be located in there. This seems 
much easier that getting each local ISP to peer

> To say that if ISPs can place HAs at different places then they can 
> also exchange routes;

I am not sure that is true, i mean selling HA services has much less 
impact in the ISP netwrok infrastructure than exchenging routes. 
BEsides, it is possible for the ground infrastrucutre to have a local 
HA, not located inside the ISP
...

> What is the risk of probing giving a false indication?  It nullifies 
> the entire goal of global HAHA.  I wouldn't risk the main requirement 
> of a protocol on this kind of unreliable probe.  If the probing were 
> just a hint, in addition to other info, then yes.
>

well, another option would be to do use the BGP AS path length as a 
complementary metric. However, what i don't like about this is to 
require the MR to run BGP. However, it would be possible to workaround 
this requirement, by requiring the HAs to acquire BGP information and 
inform the MR about the distance between the local HA and the COA where 
the MR is currently located. In this way, each HA would inform the As 
distance between it and the MR and the MR can choose the prefix of the 
closest HA as the preferred prefix for the MNN to initiate new 
communications... do you think this would be more reliable?

(i still think that probes would provide more accurate information, 
but...)

regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Apr 2006 12:19:25 +0200

marcelo bagnulo braun wrote:
>>> yes, but from other comments, i understood that they have 
>>> different ISPs in different locations, so it is far from being a
>>>  closed system.
>> 
> if all the ISPs involved are peering directly this may be easy,
> 
> 
> but if they are not [peering], they need to start configuring tunnels
>  between them to pass the routing information

I don't think so.  If ISPs use tunnels between them to pass the routing
information this only helps for hosts in ISP1 and hosts in ISP2 to reach
each other.  But it doesn't help at all hosts in the Internet other than
ISP12 to reach a host1; host1 is a host who moved from ISP1 to ISP2 and
for which routes have been exchanged between ISPs over tunnels.  CN on
the Internet knew the route to host1 goes to ISP1, but it doesn't know
it goes to ISP2.  So packets from CN1 to host1 will go first to ISP1 and
then tunnelled to ISP2.  This is exactly the same as if simple Mobile IP
were used (no global HAHA).

> and the situation becomes rather messy and hard to manage imho (but i
>  agree that is an option... see more below)
> 
> 
>>  to ISP2 "please place a HA there" then it means that they can 
>> already tell ISPs what to do.
>> 
>>  exchange routes about the MR when you sense it in your location".
>>  And if the ISPs exchange these routes then no need of Mobile IP.
>> 
> 

I don't think edge fringe networks can afford PI (provider-independent)
prefixes.  These seem to be for providers to further provide
sub-prefixes.  But it's a vague idea I have.

This is exactly a question to deployers.

> doing. the problem with this is that each nemo adds an additional 
> entry to the global routing table and they depend on BGP convergence
>  times (which won't be that good if they keep on adding routes i am 
> afraid)

I agree and I think they know it too.

>  from one of the ISP, which means that the traffic from the internet
>  to the nemo is always routed through that particular ISP, which in 
> the case that the CN and the nemo are topologically far away from 
> that ISP, then the resulting performance may be pretty bad i guess

I agree with you (as described above).  Moreover, exchanging routes over
VPNs is nothing short of Mobile IP - global HAHA wouldn't eliminate any
HA from the path.

> That is why, i think that a solution that support some form of RO 
> would be good for this case (mixed with having multiple PA prefixes,
>  in order to reduce the need for using the RO solution)

RO have their own issues.  But I think RO together with MIP would be a
_the_ global mobility solution (on paper at least).

>> If however the ISPs are reluctant to place mutually trusted HAs, or
>>  if the ISPs are not straighlty connected together (connected 
>> without BGP) then they won't be able to place HAs nor to exchange 
>> routes.
>> 
> 
>  HA, not located inside the ISP ...
> 
>> What is the risk of probing giving a false indication?  It 
>> nullifies the entire goal of global HAHA.  I wouldn't risk the main
>>  requirement of a protocol on this kind of unreliable probe.  If 
>> the probing were just a hint, in addition to other info, then yes.
>> 
> 
> require the MR to run BGP. However, it would be possible to 
> workaround this requirement, by requiring the HAs to acquire BGP 
> information and inform the MR about the distance between the local HA
>  and the COA where the MR is currently located. In this way, each HA
>  would inform the As distance between it and the MR and the MR can 
> choose the prefix of the closest HA as the preferred prefix for the 
> MNN to initiate new communications... do you think this would be more
>  reliable?

Seems it sounds like two complementary hints then it's probably yes.  It
can probably be done.  But it's probably too early to discuss solution
space.

Alex

---

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

> Moreover, i don't understand how injecting a PI prefix would 
> provide better performance than using a PA block from the 
> global provider.... i mean, the global provider prefix is 
> being injected through all the points where the global 
> provide attaches to the internet, so, the CN will reach the 
> global provider through the point that is closer to the CN 
> and then the traffic will be routed through the internal 
> global ISP network
> 

The path that your traffic takes is wholly dependant on how "well
connected" your global provider is...  If they peer at every major
exchange point and have transit relationships with the major carriers it
is unlikely to be very different.  However, there are no providers today
that "cover the whole globe", so in some cases your traffic may go "the
long way" because two providers don't peer with each other.    

I agree with you that in some cases PI traffic will follow the same path
as a PA based prefix.  However there are other cases where a PI prefix
would be different; for example if you are multihomed or if there are
providers who filter deaggregated PA address space.

Andrew

---

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

> Sent: Thursday, April 06, 2006 10:43 PM
> To: Alexandru Petrescu
> Cc: ml-nemo WG; Pascal Thubert (pthubert); T.J. Kniveton; 
> Davis, Terry L; Vijay Devarapalli
> Subject: Re: About route aggregation in global HAHA (was 
> Re:draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter 
> proposal)
> 
> 
> different 
> if all the ISPs involved are peering directly this may be 
> easy, but if they are not, they need to start configuring 
> tunnels between them to pass the routing information and the 
> situation becomes rather messy and hard to manage imho (but i 

Yes, this is one of my operational concerns with global-HAHA

> but are you assuming that the nemo has its own PI prefix or not?

I personally think you have to assume that globally mobile networks have PI address space.

> - if it has its own PI prefix, this is basically what has 
> been presented in the slides by boeing, that is what they are 
> currently doing. 

Just because you have a PI prefix doesn't mean that it has to be 1 prefix in the global routing table per mobile-network.  It is possible to aggregate.

> the problem with this is that each nemo adds 
> an additional entry to the global routing table and they 
> depend on BGP convergence times (which won't be that good if 
> they keep on adding routes i am afraid)

It is something we are keeping an eye on, but at this time there are plenty of other people out there who are putting lots of useless updates into the routing system...

http://www3.ietf.org/proceedings/06mar/slides/grow-3.pdf

Andrew

---

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

agree

regards, marcelo

---

From: Masafumi Watari <[email-masked]>
Date: Fri, 14 Apr 2006 10:41:10 +0900

> http://www3.ietf.org/proceedings/06mar/slides/grow-3.pdf

Which is not acceptable, adding even greater concerns when more sites
start multihoming, is what I heard...

watari