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

HI Fred, 

On 5/28/19, 9:59 AM, "Templin (US), Fred L" <Fred.L.Templin@boeing.com> wrote:

    Hi Acee,

    > -----Original Message-----
    > From: Acee Lindem (acee) [mailto:acee@cisco.com]
    > Sent: Thursday, May 23, 2019 1:40 PM
    > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; Nick Slabakov <nick@slabakov.com>; rtgwg@ietf.org
    > Subject: Re: Some comments on draft-ietf-rtgwg-atn-bgp-01.txt
    > 
    > 
    > 
    > On 5/21/19, 12:53 PM, "rtgwg on behalf of Templin (US), Fred L" <rtgwg-bounces@ietf.org on behalf of Fred.L.Templin@boeing.com>
    > wrote:
    > 
    >     Nick,
    > 
    >     Thank you for your comments, and sorry for the delayed response:
    > 
    >     > -----Original Message-----
    >     > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nick Slabakov
    >     > Sent: Monday, April 01, 2019 8:00 AM
    >     > To: rtgwg@ietf.org
    >     > 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.

    I remember now why we had the black hole route. If there is a shorter prefix that
    covers the MSP (e.g., "default") we do not want to forward packets destined to
    an unreachable MNP via the shorter prefix route. Instead, we need to drop those
    since it is required that all MNPs covered by an MSP are wholly contained within
    the overlay. So, I believe we need to keep that text, and perhaps include some
    supporting text as to why.

I didn't think we'd have any shorter route prefixes on the c-ASBRs. However, given that we are advertising these prefixes externally (and to even to other c-ASBRs in the scaled solution in section 3), we should have the black-hole route and is common with aother aggregated prefixes. 

Thanks,
Acee

    Thanks - Fred

    > 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
    >     > rtgwg@ietf.org
    >     > https://www.ietf.org/mailman/listinfo/rtgwg
    >     _______________________________________________
    >     rtgwg mailing list
    >     rtgwg@ietf.org
    >     https://www.ietf.org/mailman/listinfo/rtgwg
    > 