Early Review of draft-templin-atn-bgp-07
review-templin-atn-bgp-07-rtgdir-early-bryant-2018-07-24-00

This is basically a well written draft, although it has has a lots of spelling
mistakes and needs to passed through a spell checker before a further version
is uploaded.

However, I have a number of issues that the chairs and authors should consider
before deciding how to proceed.

The first question to ask is whether the work belongs in RTGWG or in IDR since
with the exception of the reference to  the optimization described in
draft-templin-aerolink-82  this is a pure BGP solution. This is something that
the RTGWG chairs should discuss with the IDR chairs. They should also discuss
whether the draft needs to be looked at by a BGP specialist before RTGWG adopts
it.

The approach of building an overlay to separate the network from the main BGP
system is a sound one, indeed from both the numbers and a security point of
view, it would appear to be  essential in a safety critical application such as
this. What bothers me is whether the author is underestimating the risk of
running an application such as this over the public Internet. Whilst as they
explain in the security section, high profile civil users do understand how to
mitigate risk and minimize the effect of attack, none of these organizations
are as large a target as civil aviation flight safety, and thus I would expect
considerable resources, even to nation state level, to be directed at the
attachment points. Hopefully ICAO fully understands the risks in running this
on the public Internet as proposed. If ever there were an application for
inter-domain network slicing, this is it.

There is a suggestion in section 3 that for reasons of cost, globally unique
ASNs would not be used. It is difficult to believe that cost is an issue in an
SoF system. What is surely needed is the most robust approach, which in the 
long term is usually the cheapest anyway. Using global identifiers minimizes
the possibility of error and issues if ever there is a routing leak, and thus
the decision on whether to use private or global identifiers needs some careful
thought beyond that expressed in this version of the draft.

I am worried about the text towards the end of section three which proposes
splitting the network into two or more disjoint systems, since that will surely
lead to operation and integration issues.

In section 6 consideration is given to scaling the core, which looks basically
under control for the existing flight profile, but with relatively little
headroom for expansion.  Given the rise in UAVs, that will surely need to be
integrated into a common flight safety system, I am concerned as to whether the
authors have allowed sufficient room for expansion. Again hopefully the flight
specialists have taken this into account and this is not a problem.

Related to the above, presumably flight density if not uniform and the authors
have satisfied themselves with the scaling of the stub areas.