HI Fred,
On 5/28/19, 9:59 AM, "Templin (US), Fred L" <[email protected]> wrote:
Hi Acee,
> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[email protected]]
> Sent: Thursday, May 23, 2019 1:40 PM
> To: Templin (US), Fred L <[email protected]>; Nick Slabakov
<[email protected]>; [email protected]
> 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"
<[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.
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
> > [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
