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

Joe Touch <touch@isi.edu> Tue, 06 December 2016 21:59 UTC

Return-Path: <touch@isi.edu>
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 705C1129CC9 for <int-area@ietfa.amsl.com>; Tue, 6 Dec 2016 13:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.795
X-Spam-Level:
X-Spam-Status: No, score=-9.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 xX8n5lhgK3vF for <int-area@ietfa.amsl.com>; Tue, 6 Dec 2016 13:59:54 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D869129CD8 for <int-area@ietf.org>; Tue, 6 Dec 2016 13:59:54 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uB6Lx6Eo027425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Dec 2016 13:59:08 -0800 (PST)
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" <int-area@ietf.org>
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>
From: Joe Touch <touch@isi.edu>
Message-ID: <5d9713ed-87be-d956-c813-a7ff995cc740@isi.edu>
Date: Tue, 06 Dec 2016 13:59:06 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <ef0bd101057340a5b82b1a49e028932c@XCH15-06-08.nw.nos.boeing.com>
Content-Type: multipart/alternative; boundary="------------CBA38B872352D78DA23B4C32"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/PjEIJ2p4B0ELwVURqHMevPaIYCk>
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 21:59:59 -0000


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