On 5/21/19, 12:53 PM, "rtgwg on behalf of Templin (US), Fred L"
<[email protected] on behalf of [email protected]> wrote:
Nick,
Thank you for your comments, and sorry for the delayed response:
> -----Original Message-----
> From: rtgwg [mailto:[email protected]] On Behalf Of Nick Slabakov
> Sent: Monday, April 01, 2019 8:00 AM
> To: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
