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

["Acee Lindem (acee)" <[e-mail]>]

On 5/21/19, 12:53 PM, "rtgwg on behalf of Templin (US), Fred L" <[e-mail] on behalf of [e-mail]> wrote:

    Nick,
    
    Thank you for your comments, and sorry for the delayed response:
    
    > -----Original Message-----
    > From: rtgwg [mailto:[e-mail]] On Behalf Of Nick Slabakov
    > Sent: Monday, April 01, 2019 8:00 AM
    > To: [e-mail]
    > Subject: Some comments on draft-ietf-rtgwg-atn-bgp-01.txt
    > 
    > Hi Fred,
    > 
    > Thank you for publishing this very well written and informative draft.  As an aviation geek, I found it very educational.  
    
    Thank you.
    
    > Some questions/comments for you:
    
    See below:
    
    > 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?
    
    I think there are lots of applications of BGP that look a lot like other applications of BGP.
    In this case, based on my read of the RFC4364 introduction I would really prefer not to
    introduce new terminology such as VPN, MPLS, etc. All we are asking for is BGP running
    over tunnels arranged in a hub-and-spokes topology. To some people tunnels imply
    VPNs, whereas I prefer to think of them as "links". A link is any lower layer service that
    can transit an IP packet without decrementing the TTL/Hop-Limit, and tunnels qualify.
    So, my preference is no change.

I agree with Fred. This is a simple overlay and doesn't use the RFC 4364 machinery (e.g., RDs). 
    
    > 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?
    
    I'll take your word for it. It would simplify the text to remove the black hole route
    discussion if that is indeed unnecessary. Any other opinions?

I can't see a reason why we'd need the blackhole routes. 

Thanks,
Acee
    
    > 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 would prefer to leave this as out-of-scope for this document, since there are multiple
    approaches that are specific to the references in Section 7.
    
    > 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.
    
    That particular document has been updated since you have seen it last, I think. If you
    are interested, please check Section 3.17 of the version now in the repository. But again,
    I would prefer to leave the details as out of scope, since there are multiple approaches
    that could work based on the references in Section 7.
    
    > 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.
    
    I think we may be able to add something here. We will consider some text and
    propose it on the list. One thought for now - would it be helpful if we were to use
    some more "aviation-like" names? For example, what is meant by a Proxy is often
    referred to in aviation terms as an "Air-to-Ground (A/G) router". And, what is meant
    by a Client is often called a "Mobile Node" (which can be any form of ATN/IPS end
    system mobile or fixed, but is often an aircraft).
    
    > 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?
    
    The device on the aircraft is simply an IPv6 mobile router that communicates with
    the ground domain via an interface known as the "aero" interface:
    
    https://datatracker.ietf.org/doc/draft-templin-atn-aero-interface/
    
    > Would have been nice if this was made part of the ongoing ADS-B
    > upgrades but I don't think it was.
    
    Right, ADS-B is certainly going to be part of the aviation communications profile
    for a long time to come. But, the ATN/IPS is going to be a complimentary service
    that bring true Internetworking to the aviation domain.
    
    Regards - Fred
    
    > Thanks,
    > Nick
    > 
    > 
    > 
    > 
    > 
    > _______________________________________________
    > rtgwg mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/rtgwg
    _______________________________________________
    rtgwg mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/rtgwg