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

From: "Dul, Andrew L" <[email-masked]>
Date: Fri, 10 Dec 2004 10:03:03 -0800

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Friday, December 10, 2004 3:36 AM
> To: Dul, Andrew L
> Cc: [email-masked]
> Subject: Re: [nemo] Announcing the Global HAHA draft
> 
> 
> Dul, Andrew L wrote:
> > 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.
> 
> 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.

I think we are getting our larger vs. longer confused. :)  You could
assign a /23 because network operators will allow it to propagate in the
global BGP table, you could also do several /24 but that creates
unnecessary entries in the table.  Almost all providers will not accept
a /25 network from their BGP neighbors.

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

Currently the movement between regions is controlled by software on the
ground, this ground software causes the BGP route updates to be
propagated.  There currently isn't a routing protocol running between
ground & air.  

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

Generally speaking we see the global route table reconverge within a
minute.  This reconvergence time is complementary to the time it takes
to switch between satellites.

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

I think introducing more routes (like the /25s) will actually cause more
table churn vs. a single update & withdrawal.

Andrew

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Dec 2004 20:14:32 +0100

Dul, Andrew L wrote:
>> 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.
> 
>  assign a /23 because network operators will allow it to propagate in
>  the global BGP table, you could also do several /24 but that creates
>  unnecessary entries in the table.  Almost all providers will not 
> accept a /25 network from their BGP neighbors.

Ah I see, yes I made a confusion above.

>>>> 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 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
> Currently the movement between regions is controlled by software on 
> the ground, this ground software causes the BGP route updates to be 

Oh, that looks different.  Does the software on the ground also offer an 
IP address to the onboard router with DHCP? (I would assume so).

>  minute.  This reconvergence time is complementary to the time it 
> takes to switch between satellites.

So 1minute is seen as acceptable.  And I guess you are talking about the 
"global route table convergence" as "global Iinternet", not a particular 
widelyspread closed core network.

>> 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.
>> 
> I think introducing more routes (like the /25s) will actually cause 
> more table churn vs. a single update & withdrawal.

Yes...  It's just that I'm trying to identify what may be different in 
this particular aerospace setting that would give hints for a different 
solution.  And I was thinking that the approximate pre-knowledge of the 
trajectory may be a distinction.  Maybe also the fact that during a 
longest trajectory possibly only 2-3 changes happen.

Just some thoughts and thanks for the info about this type of network 
mobility.

Alex