RE: [DMM] BGP-based DMM for civil aviation

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 08 January 2019 20:02 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4D6131140; Tue, 8 Jan 2019 12:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLpVxfWgQCi0; Tue, 8 Jan 2019 12:02:09 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F60130FFC; Tue, 8 Jan 2019 12:02:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x08K25pZ018301; Tue, 8 Jan 2019 15:02:05 -0500
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x08K23qB018285 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 8 Jan 2019 15:02:03 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Tue, 8 Jan 2019 12:02:02 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.1591.012; Tue, 8 Jan 2019 12:02:02 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "ek@loon.co" <ek@loon.co>
CC: "dmm@ietf.org" <dmm@ietf.org>, RTGWG <rtgwg@ietf.org>
Subject: RE: [DMM] BGP-based DMM for civil aviation
Thread-Topic: [DMM] BGP-based DMM for civil aviation
Thread-Index: AdSi2rZqGDFASLW7Rw6eo40tPXgcrAEQEnKAABvxFmA=
Date: Tue, 08 Jan 2019 20:02:02 +0000
Message-ID: <e6341293b512454eaebe9da3c731f1df@boeing.com>
References: <44917fda8b414d45bed4cd40b1590b29@boeing.com> <CAAedzxqk7xbrbXYce6izpDCv2YVv54e5ySV2sTYRYw7eFwCEMQ@mail.gmail.com>
In-Reply-To: <CAAedzxqk7xbrbXYce6izpDCv2YVv54e5ySV2sTYRYw7eFwCEMQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 1B4A8D611B09AD15A150BE4B3DE3BFC06568485876596F577B65E74F7A9F3B7A2000:8
Content-Type: multipart/alternative; boundary="_000_e6341293b512454eaebe9da3c731f1dfboeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/4TiUBvyq9-0qfXtQdQYb2Z2viiw>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2019 20:02:18 -0000

Hi Erik,

Great questions. A MNP-bearing client locates candidate s-ASBRs either through a
static map (e.g., an “/etc/hosts” file) or via the DNS. The idea is to locate an s-ASBR
that is regionally “close” to the client. For example, a client in Seattle would want
to associate with an s-ASBR in the Pacific Northwest rather than one in Eastern
Europe (although it would still work – just with sub-optimal routes). Clients do
not locate Proxys, however; the Proxy is a transparent bump-in-the-wire on
the path to the s-ASBR.

About client associations with s-ASBRs, the mechanisms are not BGP-based but
instead use a mobile routing service like MIPv6, LISP or AERO. So, the s-ASBRs
shield the BGP routing system from mobility churn caused by clients moving
between data link attachment points.

About administrative boundaries, the assumption is that all s-ASBRs and
c-ASBRs would be deployed and managed by the Mobility Service Provider.
What may not have come across from the document, however is that all
*-ASBRs could live as VMs in the cloud and do not necessarily need to be
big-iron router or server hardware.

Thanks - Fred

From: Erik Kline [mailto:ek@loon.co]
Sent: Monday, January 07, 2019 2:26 PM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: dmm@ietf.org; RTGWG <rtgwg@ietf.org>
Subject: Re: [DMM] BGP-based DMM for civil aviation

Fred,

Happy New Year.

I'm not currently tracking rtgwg, so perhaps this is already addressed in discussion of there.  (And perhaps I should move dmm@ to bcc...)

How does a MNP-bearing node (client) locate candidate s-ASBRs (similarly how does it locate a proxy)? And does the client try to form an eBGP session with the s-ASBR or use something else?

I was also not clear on where administrative boundaries are in the various diagrams (though I assumed at least that c-ASBRs are within the MSP-owners administrative domain).

Thanks,
-Erik

On Wed, 2 Jan 2019 at 12:37, Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
Hello, and Happy New Year,

We have articulated what is essentially a Distributed Mobility Management (DMM)
service for the next-generation civil aviation Aeronautical Telecommunications
Network with Internet Protocol Services (ATN/IPS):

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-atn-bgp/

This work tracks the progress of the International Civil Aviation Organization
(ICAO), and is a working group item of the IETF RTGWG.

The way it works is that there is a hub-and-spokes BGP overlay routing service
that interconnects potentially many mobility anchor points. Each anchor point is
responsible for mobility management for a constituent set of mobile nodes
(e.g., aircraft), such that the system as a whole supports large-scale DMM.

We think this document is in the correct home in RTGWG, but I just thought
I would start out the year by sensitizing the DMM community. Any thoughts
or comments are welcome.

Thanks - Fred
_______________________________________________
dmm mailing list
dmm@ietf.org<mailto:dmm@ietf.org>
https://www.ietf.org/mailman/listinfo/dmm