Some comments on draft-ietf-rtgwg-atn-bgp-01.txt

[Nick Slabakov <[e-mail]>]

Hi Fred, 

Thank you for publishing this very well written and informative draft.  As an aviation geek, I found it very educational.   Some questions/comments for you:

General:
------------
If I squint just a bit, and make the following replacements:
  - c-ASBR → PE
  - s-ASBR → eBGP-connected CE
  - IBGP → MP-BGP
… then the solution looks a lot like an IP-VPN (RFC4364) using some IP-based underlay.  Given the common knowledge of IP-VPNs, and how an IP-VPN will take care of a lot of the mechanics here (NH resolution across underlay, maintaining separation between underlay and overlay BGP instances, etc.) would it make sense to draw some analogies, or even suggest that this can actually be implemented with IP-VPNs?  Or, if there are specific reasons why the ATN/IPS is NOT analogous to an IP-VPN instance, then perhaps clarify what these are?  

Specific:
-----------
Section 3, paragraph 5:
"Each c-ASBR configures a black-hole route for each of its MSPs."
It is not clear to me why the blackhole route is necessary.  If the s-ASBR dynamically announces to the c-ASBR the MNPs that are active (as described in the Introduction), then the forwarding table of the c-ASBR should _only_ have entries to active MNP routes, and correct ICMP unreachable messages should still be sent (regardless of the presence or absence of blackhole routes).  How does the blackhole route improve this behavior?

Section 5 and 7:
The route optimization seems important, however the document lacks detail on how it will work.  Basically, how would Proxy1 and Proxy2 learn about the presence of the shortcut between them, and how would they make a routing decision to prefer it over the path via their respective s-ASBRs?  I guess for those well-versed with the references in Section 7 this might be obvious, but  after a quick skim through I-D.templin-intarea-6706bis I was still unclear.  I think the document will benefit from some elaboration on this optimization functionality of the Proxies, particularly because the definition of Proxies (in the Terminology section) does not imply any routing functionality there. 

Clearly out-of-scope, but still curious:
--------------------------------------------------
Simply a matter of curiosity, what device in the aircraft will be terminating those types of links?  Would this be a new, purpose-built device, or an enhancement of the function of an existing device?   Would have been nice if this was made part of the ongoing ADS-B upgrades but I don't think it was.  

Thanks,
Nick