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

Request Review of draft-templin-atn-bgp
Requested rev. no specific revision (document currently at 08)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-07-31
Requested 2018-07-16
Requested by Jeff Tantsura
Draft last updated 2018-07-24
Completed reviews Rtgdir Early review of -07 by Stewart Bryant (diff)
Assignment Reviewer Stewart Bryant
State Completed
Review review-templin-atn-bgp-07-rtgdir-early-bryant-2018-07-24
Reviewed rev. 07 (document currently at 08)
Review result Has Issues
Review completed: 2018-07-24

Review
review-templin-atn-bgp-07-rtgdir-early-bryant-2018-07-24

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.