Subject: RE: [nemo] Announcing the Global HAHA draft

From: "Dul, Andrew L" <[email-masked]>
Date: Fri, 3 Dec 2004 14:35:39 -0800

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Saturday, November 20, 2004 4:14 PM
> To: Dul, Andrew L
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nemo] Announcing the Global HAHA draft
> 
> 
> I just wanted to mention that I've just read somewhere that 
> when BGP routes are allowed to be injected at several ISPs 
> they must be at most or longer than /19 (v4 space).  Is it so?
> 

The smallest network that will be globally propagated today in the
Default Free Zone is /24.  For our implementation we have chosen that
network size for commercial passenger jets.  The /24 number however is
just what is currently accepted by the largest majority of service
providers.  If a majority of providers decided to change to /23 tomorrow
(unlikely, IMO) then we would have to change our network size to inject
the routes in a manner that was useful.

If we need more than /24 we could always assign a larger block to a
particular aircraft.

> 
> > At this point it is unclear to me if a similar rehoming solution is
> > possible or desirable in the multihomed v6 world.  This also may be 
> > too much of a corner case but it is nonetheless an interesting case.
> 
> YEs, I guess so, a case that I'm interested to know.  For 
> example, is it that the router onboard talks BGP, or the one 
> on the ground?
> 

In our implementation BGP is confined to the ground, but there is no
reason why BGP couldn't be deployed in the air if one wanted to.

> I also wanted to say it seems to me that passenger 
> trajectories are usually known knowns (not random as in 
> mobile handset trajectories). And I have the feeling this may 
> ease the impact of route injection may have on the core 
> routing tables.  For example, if the ground router at the 
> destination knows the plane shows above at exactly 02h55gmt 
> then it could prepare in advance something for it.  This may 
> be far off what BGP can do, I;m not knowledgeable, just 
> floating an idea.

I don't see how this would effect the BGP table, you have to transition
from one location to another at some time, whether you can predict the
time or not only changes when the change will happen not how the change
will happen.  In our case we have a limited time to make the transition
happen on the order of 10's of minutes, given we've all been on flights
that are delayed by hours the trajectory is probably not that
deterministic.  Trajectories also very daily due to weather conditions. 

Andrew

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Dec 2004 12:36:04 +0100

Dul, Andrew L wrote:
>  network size for commercial passenger jets.  The /24 number however 
> is just what is currently accepted by the largest majority of service
>  providers.  If a majority of providers decided to change to /23 
> tomorrow (unlikely, IMO) then we would have to change our network 
> size to inject the routes in a manner that was useful.
> 

You mean several /24s, not a larger block, right?  If ISPs only accept
max /24 then one couldn't assign /23 to a particular aircraft, or am I
wrong somewhere.

>> YEs, I guess so, a case that I'm interested to know.  For example, 
>> is it that the router onboard talks BGP, or the one on the ground?
> 

I see, I understand that if BGP runs on ground it could be easily be put
on board.  They seem to have a small server farm on-board for
entertainment now, so running BGP can work too.

OTOH, if your current implementation runs BGP on ground and the onboard 
router ("mobile router"?) does not run BGP, then what is used on this 
onboard router to inform the ground BGP router that it arrived?  Is this
information passed with an L2 protocol?

> I don't see how this would effect the BGP table, you have to 
> transition from one location to another at some time, whether you can
>  predict the time or not only changes when the change will happen not
>  how the change will happen.

I somehow agree.  I think one problem is the one of "converging" routing
table entries, or "converging" state of routing protocols is one of
time; i.e. it takes too long to stabilize the routing state when a small
change occurs.  Info I've read mentions in the order of 30minutes.  I
guess that the timelength can be related to the size of the change.  If
larger change is requested then longer it takes.

With this, if ground router knows 30min in advance about a 30min change
that is bound to occur, then it could trigger that change 30min at the
right time.

In addition, if a /24 needs to be injected then this could be split into 
several /25s and another /24 such that injecting would not happen at 
once, but in a sequence with sufficient time laps in between, so 
probably inducing a lesser "oscillation" in the network.

Something like that.

> In our case we have a limited time to make the transition happen on 
> the order of 10's of minutes, given we've all been on flights that 
> are delayed by hours the trajectory is probably not that 

Yes, I sense the feeling of the impossibility to plan on this, because
of too many random factors.

It was just an idea.

Alex