Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

"Templin, Fred L" <Fred.L.Templin@boeing.com> Sat, 10 December 2016 00:25 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E28A12954E for <int-area@ietfa.amsl.com>; Fri, 9 Dec 2016 16:25:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 8ItV2tlz4VF4 for <int-area@ietfa.amsl.com>; Fri, 9 Dec 2016 16:25:24 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 90B6D12943E for <int-area@ietf.org>; Fri, 9 Dec 2016 16:25:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id uBA0PNrV061987; Fri, 9 Dec 2016 17:25:23 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id uBA0PF8F061839 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 9 Dec 2016 17:25:15 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 9 Dec 2016 16:25:14 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1178.000; Fri, 9 Dec 2016 16:25:14 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Joe Touch <touch@isi.edu>, Lucy yong <lucy.yong@huawei.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels
Thread-Index: AQHSSfUTLZDjgwj4v06xdSRLJ7spf6DwdPtAgAFWbFCAAJuxAP//gxPAgACJCwD//3tEwIAAjWUA//+BhHAAFPoOgAAP0p/A//+omgD//4m84IABfSIAgACA9qD//51zgIAAhBJQ//+I0oAAEIbo0AAPI8IAAC4ZozAAgC5ygAAP6STgAA0LaIAAA1bQkAAMNEeAABCsZzAAD499gAAvpk1QAE3mNQAAqxMmAAFD+EsAApg69rAFHyD3gApOvMjgFIvsrgApJ2zYQFI9ksoAhR+SBeA=
Date: Sat, 10 Dec 2016 00:25:14 +0000
Message-ID: <e4f67d41d1414819a17ca9439bce3133@XCH15-06-08.nw.nos.boeing.com>
References: <2a8ef418-91dc-b0c5-1384-203b4fde3830@gmail.com> <e23fc6bd-c95d-9d38-74e1-c040bffe653f@isi.edu> <25503919e279426eb5fd827acf14d9c4@XCH15-06-08.nw.nos.boeing.com> <ceaf3563-ec86-8fe0-f67d-f50e9b9586ae@isi.edu> <05616d07ab3f420a8c0bd5556837d788@XCH15-06-08.nw.nos.boeing.com> <de82e183-f6dd-b872-eb21-981d57218a81@isi.edu> <a5713afee0f84c008e080f730350ed93@XCH15-06-08.nw.nos.boeing.com> <f69d6b1f-19fa-cb8d-f319-a18f7130bee6@isi.edu> <d9da3c70fcba42ddb6c7a60d8e80b6b4@XCH15-06-08.nw.nos.boeing.com> <622a5176-2b39-f08d-d31c-67aa076d52d6@isi.edu> <19fdababf617416ba19755fce7e2fcb7@XCH15-06-08.nw.nos.boeing.com> <c4cc5ab0-32b2-eff5-38de-803595263b21@isi.edu> <76d6861a032e444193553fe045a41eca@XCH15-06-08.nw.nos.boeing.com> <d6ef34df-3ff9-f989-1d5e-beafd512ff8a@isi.edu> <ef0bd101057340a5b82b1a49e028932c@XCH15-06-08.nw.nos.boeing.com> <5d9713ed-87be-d956-c813-a7ff995cc740@isi.edu> <c05d50bce73b467a9add53c95ec44100@XCH15-06-08.nw.nos.boeing.com> <75a147b0-86cf-04ae-188b-57d214865a50@isi.edu>
In-Reply-To: <75a147b0-86cf-04ae-188b-57d214865a50@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: multipart/alternative; boundary="_000_e4f67d41d1414819a17ca9439bce3133XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/j1RhnBFMvqNP1b0fwvLSRCENc6w>
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2016 00:25:27 -0000

Hi Joe,

I read your document and, for the applications I am concerned with, I still
think what I am doing is the better approach. One thing that you may not
have gathered is that the AERO interface does not maintain a replicated copy
of the entire IP forwarding table; it only keeps neighbor cache entries for its
currently active sets of neighbors. For AERO Clients, this would include the
default router(s) and any peers that it has recently received Redirects from.
For AERO Servers, the neighbor cache would include entries for the current
list of associated Clients. So, the AERO interface is not a full-blown IP router;
it is a neighbor discovery engine for its active set of neighbors.

So, unlike a dynamic routing protocol the AERO interface uses IPv6 Neighbor
Unreachability Detection (NUD) instead of routing protocol keepalives to
maintain reachability. There is also no routing protocol control messaging
going out over the underlying data links - it is simply data packets plus
occasional NUD messages.

I noticed that your document was from 1997, which is the same year I
started with SRI International. I think that was right around the time
you and I first met.

Thanks - Fred
fred.l.templin@boeing.com

From: Joe Touch [mailto:touch@isi.edu]
Sent: Tuesday, December 06, 2016 2:48 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; Lucy yong <lucy.yong@huawei.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; int-area@ietf.org
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels




On 12/6/2016 2:43 PM, Templin, Fred L wrote:
Hi Joe,

I am looking at multilink nodes like manned aircraft and unmanned aerial vehicles that
may have many active aviation data links, e.g., SATCOM, LDACS, 4G, AeroMACS etc.
The links will be either available or unavailable at various phases of flight. But, AERO
lays down a single IP layer interface (the aero0 interface) so that the aviation data
links are seen as underlying interfaces each having one or more addresses. These
underlying addresses are then seen as the L2 addresses for the AERO interface.

You can accomplish the same thing using virtual interfaces using dynamic routing. See the following:
J. Touch, T. Faber, "Dynamic Host Routing for Production Use of Developmental Networks<http://www.isi.edu/touch/pubs/icnp97/>," in Proc. ICNP '97, Atlanta, Oct. 1997, pp. 285-292.


 Underlying interfaces may come up and go down dynamically during a flight, and their
addresses may change dynamically, e.g., if they hand over from cell tower A to cell
tower B. It is AERO's job to take care of any mobility related links and always keep
neighbors informed of the current L2 addresses and availability. But, it all still looks
like a single interface (aero0) to the IP layer.
You can do the same thing using IP forwarding without needing to bury the forwarding decisions inside the link.

Joe