Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[t.petch]

- Original Message -
From: "Templin, Fred L" 
Sent: Wednesday, March 14, 2018 6:19 PM

> Chris,
>
> I forgot to mention that one of the key requirements is that there be
no
> dynamic routing protocol running over the air-to-ground data links.
The
> data links we are talking about have data rates as low as 1Mbps and
even
> lower, and the civil aviation community has declared that the control
> message overhead must be kept to a minimum. So, placing a BGP
> speaker on-board the airplane would not be  acceptable.
>
> Is there interest in having a presentation about this in London next
> week?

Fred

I am always interested in your ideas, especially when BGP is involved.
However widely they are or are not adopted, I find them stimulating

Tom Petch

>
> Thanks - Fred
>
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Templin, Fred L
> Sent: Tuesday, March 13, 2018 8:57 AM
>
> Hi Chris,
>
> >it's bad for bgp on the global scale, but in a VPN scenario you're
talking about ~10k routes? (number of planes concurrently in the air)
and transitions at a rate of 100/second? 500/second? (what rate is
>expected at 10k planes? at 100k planes?)
>
> The model is that each airplane gets one or more IPv6 prefixes and
acts as a mobile
> network. So, it has a mobile router on board, and uses the IPv6
prefixes to number
> its downstream-attached devices and networks â?" an airborne Internet
of Things.
> The IPv6 prefixes stay the same wherever the plane roams to (more on
that below).
> But, the planeâ?Ts underlying data link connections can be changing
very dynamically,
> e.g., switch from SATCOM to cellular, update QoS due to signal fading,
etc.
>
> >For quick/dirty numbers:
>
>https://www.telegraph.co.uk/travel/travel-truths/how-many-planes-are-th
ere-in-the-world/
> >
> >says there are 25k planes (round numbers) planes that I think qualify
in your pool.
>
> You are very correct to check on the current numbers of planes. For
civil aviation,
> we currently see tens of thousands. But, the system should be flexible
to support
> several orders of magnitude more than that with the multitudes of
unmanned
> aircraft expected to be coming into the airspace in the near future.
>
> >why would you change ip addressing on the plane? having them keep
their addressing seems simpler and more conducive to stability, no?
>
> Right, the airplaneâ?Ts on-board IPv6 prefixes used for downstream IoT
addressing
> never change. It is the planeâ?Ts upstream data link addresses that
can change
> dynamically, i.e., in the same way that a cellphoneâ?Ts WiFi and/or 4G
addresses
> can change.
>
> Again, the design is to keep mobility-related churn out of BGP in the
core
> of the network and to keep the churn out in the edges of the network.
>
> Thanks - Fred
>
>
> From: Christopher Morrow [mailto:christopher.mor...@gmail.com]
> Sent: Tuesday, March 13, 2018 8:24 AM
>

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

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[Randy Bush]

> I'm not sure this is work that is a great fit for GROW.

you are being too polite.  this is a poorly thought out idea.  people
have already pointed out simpler approaches.  but our job is not to
design this for boeing, it is to decide if this is work for this wg.
imiho, it isn't.

randy

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

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[Templin, Fred L]

Hi Job,

What this document is about is a global routing service for a major 
international
enterprise, namely worldwide civil aviation. But, the same model could be
applied to any major enterprise, e.g., large corporate enterprise networks,
stock exchanges, etc. The contribution of this architecture is allowing scalable
growth for new usage models where mobility, multi-homing and traffic
engineering become important components of the services offered to
end users. But, by virtue of this design, the Internet core BGP routing system
only needs to know about a few short and unchanging prefixes - it does not
need to know about the more-specific prefixes of mobile, multi-homed and
traffic engineering-capable end systems. 

So, instead of looking at this as an isolated case of just civil aviation, 
another
viewpoint could see it as a model for how to grow the Internet in the coming
age of mobile devices that get IPv6 prefixes that need to remain constant as
the device moves around. Such that growth at the edges does not result in
growth in the core. That would be aligned with grow, wouldn't it?

Thanks - Fred

> -Original Message-
> From: Job Snijders [mailto:j...@ntt.net]
> Sent: Thursday, March 15, 2018 3:24 AM
> To: Templin, Fred L <fred.l.temp...@boeing.com>
> Cc: Christopher Morrow <christopher.mor...@gmail.com>; 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
> 
> Hi Fred,
> 
> On Wed, Mar 14, 2018 at 06:19:09PM +, Templin, Fred L wrote:
> > Is there interest in having a presentation about this in London next
> > week?
> 
> ### Speaking as a working group participant.
> 
> I'm not sure this is work that is a great fit for GROW. Since the work
> appears to be about a private airplane control traffic network operating
> as an overlay, I'd liken the work more to SCADA related work than
> Internet related projects. The fact that these planes fly around the
> world (global), and BGP is used (routing), doesn't necessarily make it a
> GROW item. You've indicated that ATN/IPS may not even be using the
> Internet as underlay.
> 
> I've given some thought to what would maybe be better working group.
> And, in all seriousness, I think the Internet-Of-Things side of IETF may
> be better. It is perhaps unconventional to liken a large item such as an
> airplane to what we often consider "Things" in the IoT-context such as
> mediaplayers, light bulbs, etc - but given the constraints you mentioned
> in your emails (BGP is too much protocol overhead etc) the airplanes
> really seems just "very large things" in IoT context.
> 
> Have you considered one of the following groups?
> 
> https://datatracker.ietf.org/rg/t2trg/about/ ('low-resource
> nodes ("things", "constrained nodes") can communicate among
> themselves and with the wider Internet')
> 
> https://datatracker.ietf.org/wg/detnet/about/ ('engine control
> systems, and other general industrial and vehicular applications')
> 
> I don't have access to a lot of airplanes, so I think it would be hard
> for me to contribute in a meaningful way.
> 
> ### (with co-chair hat on)
> 
> If GROW participants are interested in draft-templin-atn-bgp-06.txt,
> please speak up now. If there is interest, we'll try to make it fit in
> the IETF 101 agenda.
> 
> Kind regards,
> 
> Job


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

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[Job Snijders]

Hi Fred,

On Wed, Mar 14, 2018 at 06:19:09PM +, Templin, Fred L wrote:
> Is there interest in having a presentation about this in London next
> week?

### Speaking as a working group participant.

I'm not sure this is work that is a great fit for GROW. Since the work
appears to be about a private airplane control traffic network operating
as an overlay, I'd liken the work more to SCADA related work than
Internet related projects. The fact that these planes fly around the
world (global), and BGP is used (routing), doesn't necessarily make it a
GROW item. You've indicated that ATN/IPS may not even be using the
Internet as underlay.

I've given some thought to what would maybe be better working group.
And, in all seriousness, I think the Internet-Of-Things side of IETF may
be better. It is perhaps unconventional to liken a large item such as an
airplane to what we often consider "Things" in the IoT-context such as
mediaplayers, light bulbs, etc - but given the constraints you mentioned
in your emails (BGP is too much protocol overhead etc) the airplanes
really seems just "very large things" in IoT context.

Have you considered one of the following groups?

https://datatracker.ietf.org/rg/t2trg/about/ ('low-resource
nodes ("things", "constrained nodes") can communicate among
themselves and with the wider Internet')

https://datatracker.ietf.org/wg/detnet/about/ ('engine control
systems, and other general industrial and vehicular applications')

I don't have access to a lot of airplanes, so I think it would be hard
for me to contribute in a meaningful way.

### (with co-chair hat on)

If GROW participants are interested in draft-templin-atn-bgp-06.txt,
please speak up now. If there is interest, we'll try to make it fit in
the IETF 101 agenda.

Kind regards,

Job

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

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[Templin, Fred L]

Hi James,

Thank you for your valuable feedback, and see below for responses:

>First my understanding of this solution is that is BGP 
> underlay, BGP Overlay.. Is this correct?

It is a BGP overlay over an underlying connected wide area network such as the
Internet. So, yes, it is BGP in both the overlay and underlay.

>If so, what is the ask in Section 6 last paragraph? If it is to create 
>multiple instances
>of BGP would that be using Local-AS, Dual-AS etc… or to actually to create two 
>BGP
>Instances each with their own AS? We have had that discussion at IETF and it 
>is similar
>to an ask I have where I am using BGP 3107 as underlay and 2547, VPN etc… as 
>overlay..

The idea is that the overlay BGP instance will carry only Mobile Network Prefix 
(MNP)
routes, while the underlay BGP instance carries all of the routes in the 
Internet. If we
join the two instances, the overlay portion would only advertise one or a few 
aggregated
prefixes into the underlay portion – it would not advertise all of the 
more-specific MNPs.

>There is no discussion of the actual topology in terms of s-ASBRs and 
>C-ASBRs.. Is
>there some notion of geography, nation, continent etc…

s-ASBRs will be regionally distributed, e.g., some in Europe, some in the US, 
some
in Asia, etc. And, end systems choose which s-ASBRs to associate with based on a
map that tells which ones are closest. So, the end system chooses a nearby 
s-ASBR
and if it moves far from the s-ASBR it hands over to a different s-ASBR.

>Sect 3 ( Top of Pg 8 )
>
>“Since ATN/IPS end systems …”
>
>You indicate that airplanes remain in the stub area for an extended period of 
>time
>and therefore intra-domain mobility events are handled in the stub area only. 
>How
>is this possible? There must come a time where the MNP for said aircraft will 
>not
>be available via a given cell tower or cellular provider.  What am I missing 
>here..

The s-ASBR keeps track of the airplane’s current data link addresses and 
associates
these with the airplane’s IPv6  MNP. To get packets to the airplane, the s-ASBR 
uses
encapsulation with MNP addresses in the encapsulated packet header and data link
addresses in the encapsulation header.  The airplane may have multiple data 
links,
and it may be handing over between cell towers and/or service providers as it 
moves.
But, the s-ASBR never reports these kinds of mobility events to the c-ASBRs via 
BGP
updates, and so mobility-related churn is kept out of the BGP routing system.

>Sect 3 ( Middle of Pg 8 )
>
>It seems that you are going to apply route filters on the c-asbrs so that a 
>given set
>of them will service a given set of MSPs.

No, the c-ASBRs have full topology knowledge of all MNPs in the entire system.
The s-ASBRs only have knowledge of the MNPs they are currently serving. So
I think yes when I set up the implementation I used route filters. But, what 
they
did was allow the s-ASBRs to tell the c-ASBRs everything and did not allow the
c-ASBRs to tell the s-ASBRs anything.

> a) Are these filters applied inbound/outbound
>b) Is this generally static or will operations be mucking with these often. 
>More
>   hands equals more problems is my experience.
>c)What happens if mis-config? What is the blast radius of getting this wrong.

In terms of filters, we have it that the c-ASBRs originate “default” but do not
advertise any MNPs to any of the s-ASBRs. And, the s-ASBRs tell their peer
c-ASBRs about every MNP they are currently servicing.

In terms of static, c-ASBRs and s-ASBRs only need to be configured once, and
then the configuration would only be changed if new c/s-ASBRS are added
or old c/s-ASBRs are decommissioned. So, I think the configuration footprint
would be similar to the way the global Internet works but at a much smaller
scale – for example, there would probably only be about 100 or so s-ASBRs
and 1o or so c-ASBRs.

In terms of misconfigurations, if a peering between an s-ASBR and c-ASBR
is not set up correctly all of the end systems that associate with the (defunct)
s-ASBR will not receive service. But, in that case, the end systems can simply
choose a different s-ASBR.

I hope this addresses your questions. If not, I would be happy to iterate.
Thanks for your time.

Fred

From: UTTARO, JAMES [mailto:ju1...@att.com]
Sent: Wednesday, March 14, 2018 12:10 PM
To: Templin, Fred L <fred.l.temp...@boeing.com>; Christopher Morrow 
<christopher.mor...@gmail.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

Fred,

Took a read on the draft.. A few comments below..

First my understanding of this solution is that is BGP 
underlay, BGP Overlay.. Is this correct? If s

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[UTTARO, JAMES]

Fred,

Took a read on the draft.. A few comments below..

First my understanding of this solution is that is BGP 
underlay, BGP Overlay.. Is this correct? If so, what is the ask in Section 6 
last paragraph? If it is to create multiple instances of BGP would that be 
using Local-AS, Dual-AS etc… or to actually to create two BGP Instances each 
with their own AS? We have had that discussion at IETF and it is similar to an 
ask I have where I am using BGP 3107 as underlay and 2547, VPN etc… as overlay..

There is no discussion of the actual topology in terms of s-ASBRs and C-ASBRs.. 
Is there some notion of geography, nation, continent etc…

Sect 3 ( Top of Pg 8 )

“Since ATN/IPS end systems …”
You indicate that airplanes remain in the stub area for an extended period of 
time and therefore intra-domain mobility events are handled in the stub area 
only. How is this possible? There must come a time where the MNP for said 
aircraft will not be available via a given cell tower or cellular provider.  
What am I missing here..

Sect 3 ( Middle of Pg 8 )

It seems that you are going to apply route filters on the c-asbrs so that a 
given set of them will service a given set of MSPs.


a)  Are these filters applied inbound/outbound

b)  Is this generally static or will operations be mucking with these 
often. More hands equals more problems is my experience.

c)   What happens if mis-config? What is the blast radius of getting this 
wrong.

Thanks,
Jim Uttaro


From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Templin, Fred L
Sent: Wednesday, March 14, 2018 2:19 PM
To: Christopher Morrow <christopher.mor...@gmail.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

Chris,

I forgot to mention that one of the key requirements is that there be no
dynamic routing protocol running over the air-to-ground data links. The
data links we are talking about have data rates as low as 1Mbps and even
lower, and the civil aviation community has declared that the control
message overhead must be kept to a minimum. So, placing a BGP
speaker on-board the airplane would not be  acceptable.

Is there interest in having a presentation about this in London next
week?

Thanks - Fred

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Templin, Fred L
Sent: Tuesday, March 13, 2018 8:57 AM
To: Christopher Morrow 
<christopher.mor...@gmail.com<mailto:christopher.mor...@gmail.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

Hi Chris,

>it's bad for bgp on the global scale, but in a VPN scenario you're talking 
>about ~10k routes? (number of planes concurrently in the air) and transitions 
>at a rate of 100/second? 500/second? (what rate is >expected at 10k planes? at 
>100k planes?)

The model is that each airplane gets one or more IPv6 prefixes and acts as a 
mobile
network. So, it has a mobile router on board, and uses the IPv6 prefixes to 
number
its downstream-attached devices and networks – an airborne Internet of Things.
The IPv6 prefixes stay the same wherever the plane roams to (more on that 
below).
But, the plane’s underlying data link connections can be changing very 
dynamically,
e.g., switch from SATCOM to cellular, update QoS due to signal fading, etc.

>For quick/dirty numbers:
>https://www.telegraph.co.uk/travel/travel-truths/how-many-planes-are-there-in-the-world/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.telegraph.co.uk_travel_travel-2Dtruths_how-2Dmany-2Dplanes-2Dare-2Dthere-2Din-2Dthe-2Dworld_=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3qhKphE8RnwJQ6u8MrAGeA=1in3Oz4sy5FNjimSBTapMQePTjFvBG-cVosjFEOCeoc=WQSPIejYgOPpbdGwqVI7BM6J4EqZPOSmpKsBMoFyyfo=>
>
>says there are 25k planes (round numbers) planes that I think qualify in your 
>pool.

You are very correct to check on the current numbers of planes. For civil 
aviation,
we currently see tens of thousands. But, the system should be flexible to 
support
several orders of magnitude more than that with the multitudes of unmanned
aircraft expected to be coming into the airspace in the near future.

>why would you change ip addressing on the plane? having them keep their 
>addressing seems simpler and more conducive to stability, no?

Right, the airplane’s on-board IPv6 prefixes used for downstream IoT addressing
never change. It is the plane’s upstream data link addresses that can change
dynamically, i.e., in the same way that a cellphone’s WiFi and/or 4G addresses
can change.

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[Templin, Fred L]

Chris,

I forgot to mention that one of the key requirements is that there be no
dynamic routing protocol running over the air-to-ground data links. The
data links we are talking about have data rates as low as 1Mbps and even
lower, and the civil aviation community has declared that the control
message overhead must be kept to a minimum. So, placing a BGP
speaker on-board the airplane would not be  acceptable.

Is there interest in having a presentation about this in London next
week?

Thanks - Fred

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Templin, Fred L
Sent: Tuesday, March 13, 2018 8:57 AM
To: Christopher Morrow <christopher.mor...@gmail.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

Hi Chris,

>it's bad for bgp on the global scale, but in a VPN scenario you're talking 
>about ~10k routes? (number of planes concurrently in the air) and transitions 
>at a rate of 100/second? 500/second? (what rate is >expected at 10k planes? at 
>100k planes?)

The model is that each airplane gets one or more IPv6 prefixes and acts as a 
mobile
network. So, it has a mobile router on board, and uses the IPv6 prefixes to 
number
its downstream-attached devices and networks – an airborne Internet of Things.
The IPv6 prefixes stay the same wherever the plane roams to (more on that 
below).
But, the plane’s underlying data link connections can be changing very 
dynamically,
e.g., switch from SATCOM to cellular, update QoS due to signal fading, etc.

>For quick/dirty numbers:
>https://www.telegraph.co.uk/travel/travel-truths/how-many-planes-are-there-in-the-world/
>
>says there are 25k planes (round numbers) planes that I think qualify in your 
>pool.

You are very correct to check on the current numbers of planes. For civil 
aviation,
we currently see tens of thousands. But, the system should be flexible to 
support
several orders of magnitude more than that with the multitudes of unmanned
aircraft expected to be coming into the airspace in the near future.

>why would you change ip addressing on the plane? having them keep their 
>addressing seems simpler and more conducive to stability, no?

Right, the airplane’s on-board IPv6 prefixes used for downstream IoT addressing
never change. It is the plane’s upstream data link addresses that can change
dynamically, i.e., in the same way that a cellphone’s WiFi and/or 4G addresses
can change.

Again, the design is to keep mobility-related churn out of BGP in the core
of the network and to keep the churn out in the edges of the network.

Thanks - Fred


From: Christopher Morrow [mailto:christopher.mor...@gmail.com]
Sent: Tuesday, March 13, 2018 8:24 AM
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>>; Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: Re: [GROW] A Simple BGP-based Mobile Routing System for the 
Aeronautical Telecommunications Network



On Tue, Mar 13, 2018 at 10:58 AM, Templin, Fred L 
<fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>> wrote:
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

it's bad for bgp on the global scale, but in a VPN scenario you're talking 
about ~10k routes? (number of planes concurrently in the air) and transitions 
at a rate of 100/second? 500/second? (what rate is expected at 10k planes? at 
100k planes?)

For quick/dirty numbers:
https://www.telegraph.co.uk/travel/travel-truths/how-many-planes-are-there-in-the-world/

says there are 25k planes (round numbers) planes that I think qualify in your 
pool.

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 coul

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[Acee Lindem (acee)]

Hi Chris,

While the ATN in not THE Global Routing system, it is A Global Routing system 
that, at least in this proposal, is based on BGP. Hence, I think the GROW 
community is an excellent place for review. I would not liken it to RFC 4364 
VPNs though since the overlay network is not tightly coupled to the underlay 
network and, in the current proposal, both the underlay and overlay are using 
the global VRF. The overlay routes simply resolve their nexthops over the 
underlay routes which will, in many cases, also be BGP routes. A better analogy 
than RFC 4364 are commercial SD-WAN implementations which avail tunnels over 
multiple networks including the Internet.

Thanks,
Acee

From: "Templin, Fred L" <fred.l.temp...@boeing.com>
Date: Tuesday, March 13, 2018 at 11:56 AM
To: Christopher Morrow <christopher.mor...@gmail.com>
Cc: "grow@ietf.org" <grow@ietf.org>, "Saccone, Gregory T" 
<gregory.t.sacc...@boeing.com>, Gaurav Dawra <gdawra.i...@gmail.com>, Acee 
Lindem <a...@cisco.com>
Subject: RE: [GROW] A Simple BGP-based Mobile Routing System for the 
Aeronautical Telecommunications Network

Hi Chris,

>it's bad for bgp on the global scale, but in a VPN scenario you're talking 
>about ~10k routes? (number of planes concurrently in the air) and transitions 
>at a rate of 100/second? 500/second? (what rate is >expected at 10k planes? at 
>100k planes?)

The model is that each airplane gets one or more IPv6 prefixes and acts as a 
mobile
network. So, it has a mobile router on board, and uses the IPv6 prefixes to 
number
its downstream-attached devices and networks – an airborne Internet of Things.
The IPv6 prefixes stay the same wherever the plane roams to (more on that 
below).
But, the plane’s underlying data link connections can be changing very 
dynamically,
e.g., switch from SATCOM to cellular, update QoS due to signal fading, etc.

>For quick/dirty numbers:
>https://www.telegraph.co.uk/travel/travel-truths/how-many-planes-are-there-in-the-world/
>
>says there are 25k planes (round numbers) planes that I think qualify in your 
>pool.

You are very correct to check on the current numbers of planes. For civil 
aviation,
we currently see tens of thousands. But, the system should be flexible to 
support
several orders of magnitude more than that with the multitudes of unmanned
aircraft expected to be coming into the airspace in the near future.

>why would you change ip addressing on the plane? having them keep their 
>addressing seems simpler and more conducive to stability, no?

Right, the airplane’s on-board IPv6 prefixes used for downstream IoT addressing
never change. It is the plane’s upstream data link addresses that can change
dynamically, i.e., in the same way that a cellphone’s WiFi and/or 4G addresses
can change.

Again, the design is to keep mobility-related churn out of BGP in the core
of the network and to keep the churn out in the edges of the network.

Thanks - Fred


From: Christopher Morrow [mailto:christopher.mor...@gmail.com]
Sent: Tuesday, March 13, 2018 8:24 AM
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>; Acee Lindem (acee) <a...@cisco.com>
Subject: Re: [GROW] A Simple BGP-based Mobile Routing System for the 
Aeronautical Telecommunications Network



On Tue, Mar 13, 2018 at 10:58 AM, Templin, Fred L 
<fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>> wrote:
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

it's bad for bgp on the global scale, but in a VPN scenario you're talking 
about ~10k routes? (number of planes concurrently in the air) and transitions 
at a rate of 100/second? 500/second? (what rate is expected at 10k planes? at 
100k planes?)

For quick/dirty numbers:
https://www.telegraph.co.uk/travel/travel-truths/how-many-planes-are-there-in-the-world/

says there are 25k planes (round numbers) planes that I think qualify in your 
pool.

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, 
>tha

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[Christopher Morrow]

On Tue, Mar 13, 2018 at 10:58 AM, Templin, Fred L <fred.l.temp...@boeing.com
> wrote:

> 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
>
>
it's bad for bgp on the global scale, but in a VPN scenario you're talking
about ~10k routes? (number of planes concurrently in the air) and
transitions at a rate of 100/second? 500/second? (what rate is expected at
10k planes? at 100k planes?)

For quick/dirty numbers:
https://www.telegraph.co.uk/travel/travel-truths/how-many-planes-are-there-in-the-world/

says there are 25k planes (round numbers) planes that I think qualify in
your pool.


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

why would you change ip addressing on the plane? having them keep their
addressing seems simpler and more conducive to stability, no?


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

ok, other folk ought to chime in then.


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

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[Christopher Morrow]

On Mon, Mar 12, 2018 at 4:59 PM, Templin, Fred L <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]
> *Sent:* Monday, March 12, 2018 12:31 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
>
>
>
> (as a normal participant)
>
>
>
> On Thu, Mar 8, 2018 at 3:14 PM, Templin, Fred L <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

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[Templin, Fred L]

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.

Thanks - Fred

From: Christopher Morrow [mailto:christopher.mor...@gmail.com]
Sent: Monday, March 12, 2018 12:31 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

(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

Re: [GROW] A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network

[Christopher Morrow]

(as a normal participant)

On Thu, Mar 8, 2018 at 3:14 PM, Templin, Fred L 
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