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:[email protected]] On Behalf Of Templin, Fred L
Sent: Wednesday, March 14, 2018 2:19 PM
To: Christopher Morrow <[email protected]>
Cc: [email protected]; Saccone, Gregory T <[email protected]>; Gaurav
Dawra <[email protected]>
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:[email protected]] On Behalf Of Templin, Fred L
Sent: Tuesday, March 13, 2018 8:57 AM
To: Christopher Morrow
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Saccone, Gregory T
<[email protected]<mailto:[email protected]>>; Gaurav
Dawra <[email protected]<mailto:[email protected]>>
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_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3qhKphE8RnwJQ6u8MrAGeA&m=1in3Oz4sy5FNjimSBTapMQePTjFvBG-cVosjFEOCeoc&s=WQSPIejYgOPpbdGwqVI7BM6J4EqZPOSmpKsBMoFyyfo&e=>
>
>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:[email protected]]
Sent: Tuesday, March 13, 2018 8:24 AM
To: Templin, Fred L
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Saccone, Gregory T
<[email protected]<mailto:[email protected]>>; Gaurav
Dawra <[email protected]<mailto:[email protected]>>; Acee Lindem (acee)
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.telegraph.co.uk_travel_travel-2Dtruths_how-2Dmany-2Dplanes-2Dare-2Dthere-2Din-2Dthe-2Dworld_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3qhKphE8RnwJQ6u8MrAGeA&m=1in3Oz4sy5FNjimSBTapMQePTjFvBG-cVosjFEOCeoc&s=WQSPIejYgOPpbdGwqVI7BM6J4EqZPOSmpKsBMoFyyfo&e=>
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:[email protected]<mailto:[email protected]>]
Sent: Monday, March 12, 2018 7:16 PM
To: Templin, Fred L
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Saccone, Gregory T
<[email protected]<mailto:[email protected]>>; Gaurav
Dawra <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
Sent: Monday, March 12, 2018 12:31 PM
To: Templin, Fred L
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Saccone, Gregory T
<[email protected]<mailto:[email protected]>>; Gaurav
Dawra <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/grow
