Hi Chris,

>yup, sure what I was proposing is that they DO participate.
>I could see a world where the plane has a simple BGP instance, and some 
>orchestration does the equivalent of the mobile cell hand-off for hand-devices:
>  "about to leave AS1, start peering with AS2, ... drop peering with AS1"

With the Connexion By Boeing experience, we have proof that frequent injections
and withdrawals of prefixes due to mobility is bad for BGP. Plus, aircraft are
multi-link entities that often have multiple data links operational 
simultaneously,
where each data link connects to a data link service provider network that may
know nothing about BGP internally. And, we want to avoid tunneling over the
low data rate wireless data links themselves.

>I imagine each plane could even maintain more than one  live BGP session with 
>the ground stations, even. It's good to hear that the expected churn is low, 
>that makes 'plane based bgp' even more >attractive (to me anyway).

No, the aircraft could be moving into and out of service range dynamically, 
changing
their IP addresses frequently, switching between available data links, and 
updating
their QoS conditions, e.g., based on signal strength changes. So, there is a 
lot going
on from a mobility standpoint, but the architecture in our doc prevents that 
from
percolating up into BGP.

>Again this  still sounds like /2547 mpls vpn/ sorts of stuff, not something 
>super related to grow's 'global routing (internet focused) operations' area, 
>is it?

Again, this is a simple BGP arrangement – no RFC2547, no mpls, etc. About 
whether
or not it is related to grow, that’s what we’re here to find out.

Thanks - Fred

>in a 2547 sort of scenario (any of the vpn overlays  really) the carrier 
>network doesn't have to know anything at all about the vpn content or routes.




From: Christopher Morrow [mailto:christopher.mor...@gmail.com]
Sent: Monday, March 12, 2018 7:16 PM
To: Templin, Fred L <fred.l.temp...@boeing.com>
Cc: grow@ietf.org; Saccone, Gregory T <gregory.t.sacc...@boeing.com>; Gaurav 
Dawra <gdawra.i...@gmail.com>
Subject: Re: [GROW] A Simple BGP-based Mobile Routing System for the 
Aeronautical Telecommunications Network



On Mon, Mar 12, 2018 at 4:59 PM, Templin, Fred L 
<fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>> wrote:
Hi Chris,

Thanks for the comments, but no the planes (as Clients) do not do BGP;
only the ground-domain Servers and Relays do BGP.

Servers are ASBRs for stub ASes  and connect to Relays that are ASBRs for
a core AS in a hub-and-spokes fashion. When a plane contacts a Server,
it becomes part of that Server’s stub AS. And, because planes do not
move rapidly from Server to Server, the amount of mobility-related BGP
update churn as seen by the core AS is dampened.

But, the planes themselves do not participate in BGP, and are therefore
not mobile ASes.

yup, sure what I was proposing is that they DO participate.
I could see a world where the plane has a simple BGP instance, and some 
orchestration does the equivalent of the mobile cell hand-off for hand-devices:
  "about to leave AS1, start peering with AS2, ... drop peering with AS1"

I imagine each plane could even maintain more than one  live BGP session with 
the ground stations, even. It's good to hear that the expected churn is low, 
that makes 'plane based bgp' even more attractive (to me anyway).

Again this  still sounds like /2547 mpls vpn/ sorts of stuff, not something 
super related to grow's 'global routing (internet focused) operations' area, is 
it?
in a 2547 sort of scenario (any of the vpn overlays  really) the carrier 
network doesn't have to know anything at all about the vpn content or routes.


Thanks - Fred

From: Christopher Morrow 
[mailto:christopher.mor...@gmail.com<mailto:christopher.mor...@gmail.com>]
Sent: Monday, March 12, 2018 12:31 PM
To: Templin, Fred L 
<fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>>
Cc: grow@ietf.org<mailto:grow@ietf.org>; Saccone, Gregory T 
<gregory.t.sacc...@boeing.com<mailto:gregory.t.sacc...@boeing.com>>; Gaurav 
Dawra <gdawra.i...@gmail.com<mailto:gdawra.i...@gmail.com>>
Subject: Re: [GROW] A Simple BGP-based Mobile Routing System for the 
Aeronautical Telecommunications Network

(as a normal participant)

On Thu, Mar 8, 2018 at 3:14 PM, Templin, Fred L 
<fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>> wrote:
Hello,

We have published a document that proposes BGP as the core of a mobile routing
service for worldwide civil aviation in the Aeronautical Telecommunications 
Network
with Internet Protocol Services (ATN/IPS). This would be an overlay network 
deployment
of standard BGP with ASes arranged in such a way as to mitigate the 
mobility-related
instability that was inherent in past approaches. The system also leverages an
adjunct route optimization service known as AERO.

The ATN/IPS is planned to eventually replace existing air traffic management 
services
with an IPv6-based service as part of a long-term evolution. The choice of 
mobile
routing services is being made now, with this approach, LISP and Mobile IPv6 as
candidates. Although the decision is being considered in the International Civil
Aviation Organization (ICAO), we feel the time is right to socialize the effort
in the IETF.

Hey, much of this document reads like:
   "hey, the global internet is messy, and slowish, we think making our own bgp 
domain will make that problem go away"

Followed by what smells a lot like any old RFC2547 MPLS VPN deployment. I'm not 
sure I buy the need for 'ip mobility' in a world where the plane COULD be a BGP 
speaker and just negotiate upstream connectivity 'in real time'... but overall 
this just sounds like  any other 2547 deployment to me?

You'd have to convince your constituent parts that depending upon various 
providers 2547 interconnection agreements to work out properly is 
sane/useful/cost-effective/not-prone-to-explosion... but ... sure, make a 2547 
network, make the planes do bgp, and orchestrate the add/remove peerings part 
across the network as planes move around.

_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Reply via email to