Re: [Idr] Rtgdir early review of draft-templin-atn-bgp-07

["Templin (US), Fred L" <[e-mail]>]

Hello Stewart,

Thank you for your effort in reviewing the document. Please see below for
follow-up discussion:

Fred

> -----Original Message-----
> From: Idr [mailto:[e-mail]] On Behalf Of Stewart Bryant
> Sent: Tuesday, July 24, 2018 4:10 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: [Idr] Rtgdir early review of draft-templin-atn-bgp-07
> 
> Reviewer: Stewart Bryant
> Review result: Has Issues
> 
> 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.

Certainly we will fix that; apologies if it impacted the readability.

> 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 document has been presented at RTGWG at three different IETF meetings
now and seems to have been well received there. So, we would like to see it
become an RTGWG working group item so we would not have to start the
socialization process over again, but your point is well taken. I do not have
enough experience with routing area working groups to understand all of
the implications, so any guidance would be appreciated. 

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

For civil aviation, this is indeed a critical consideration. On the open public
Internet, for example, although IPsec could be used to establish secure
tunnels other threat vectors such as DDoS need to be considered. In my
understanding, ICAO is thinking about an underlay network comprising
secured physical links (e.g., fiber) and/or constructs like SD-WAN. But,
the construction of the underlay I think is something that has been
taken for granted and as you observe is pivotal to the design security.

> 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 don't mind dropping the assertion that private AS numbers could be used.
As you say, there is probably no downside to procuring real global AS
numbers up front even if the overlay is never connected to the global
public Internet.

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

Looking at that text with fresh eyes, I can see that a rewrite would help
bring across the point we are trying to make. What we want to have is
a means for supporting multiple independent RIBs and bounding the
numbers of prefixes each RIB will be sized to carry. So, if each RIB
supported up to 1M prefixes and we had 1K RIBs, we would be able
to service 1B prefixes or even a bit more. Does that help clarify? If so,
I will consult with co-authors to improve that text.

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

The upper bound in terms of scaling we were targeting was up to 1B
prefixes carried as BGP routes in order to allow for expansion. You are
right to observe that we are at the advent of wide-scale deployment of
UAVs, but this network would be only for those UAVs that fly to, from
or through airspace controlled by Air Traffic Controllers (ATCs) - meaning
it would only be for UAVs that take off and land at airports. For the future,
the types of UAVs that will eventually do that include unmanned cargo
delivery freighters and the like. But, we would only be expecting a few
thousands, ten-thousands, or hundred-thousansds of those; certainly
not millions and millions.

For small UAVs that stay away from the airports, however, there is
potential for many millions of those or more. For them, the FAA and
NASA have a concept known as "Unmanned (air) Traffic Management"
or "UTM". The UTM would need to be a separate network unto itself,
but we believe these same BGP principles could apply there.

> Related to the above, presumably flight density if not uniform and the authors
> have satisfied themselves with the scaling of the stub areas.
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr