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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 06 December 2016 22:44 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 A905A1295E6 for <int-area@ietfa.amsl.com>; Tue, 6 Dec 2016 14:44:05 -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_H3=-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 qkv-xgccq079 for <int-area@ietfa.amsl.com>; Tue, 6 Dec 2016 14:44:02 -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 E08621295AD for <int-area@ietf.org>; Tue, 6 Dec 2016 14:44:02 -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 uB6Mi25v004209; Tue, 6 Dec 2016 15:44:02 -0700
Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id uB6MhpGO004136 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2016 15:43:51 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 6 Dec 2016 14:43:50 -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; Tue, 6 Dec 2016 14:43:50 -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+EsAApg69rAFHyD3gApOvMjgFIvsrgApJ2zYQA==
Date: Tue, 06 Dec 2016 22:43:50 +0000
Message-ID: <c05d50bce73b467a9add53c95ec44100@XCH15-06-08.nw.nos.boeing.com>
References: <2a8ef418-91dc-b0c5-1384-203b4fde3830@gmail.com> <137debc3-eb11-5c13-884e-d8f6598e8ec9@isi.edu> <30ad1018463746b3b7ef5d864abc9ff3@XCH15-06-08.nw.nos.boeing.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>
In-Reply-To: <5d9713ed-87be-d956-c813-a7ff995cc740@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_c05d50bce73b467a9add53c95ec44100XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/whYrkYv6dtk5HlG6ez3FXKRjGtw>
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: Tue, 06 Dec 2016 22:44:06 -0000

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.

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.

Thanks - Fred

From: Joe Touch [mailto:touch@isi.edu]
Sent: Tuesday, December 06, 2016 1:59 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 1:46 PM, Templin, Fred L wrote:

If there are multiple interfaces, why would it pick aero0? And what

would its QoS be? It can't have a single value, so the main IP

forwarding code can't decide between aero0 and other interfaces.

The IP forwarding table has an entry such as:



  2001:db8::/32 -> aero0



Meaning that any IPv6 packet with a destination that matches 2001:db8::/32

*and for which no more-specific route exists* goes out interface aero0

unconditionally. The packet will have a TOS value, and it is that TOS that

guides the aero0 interface on how to portion traffic over the underlying

interfaces.


The problem is that this makes it impossible for the IP forwarding table to control which aero0 encaps is used, thus which QoS it gets.

I.e., the main IP forwarding can't take QoS into account. I understand that Aero can do the right thing, but only with the packets it already has. It can't say "oh, I don't have a QOS for that, let me give it back to the main IP forwarding for another interface".

If you have only one link, sure - there's no problem. But if you have more than one (which is much more typical, even for hosts), then you do.

Joe