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

Joe Touch <touch@isi.edu> Tue, 06 December 2016 23:43 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 79F2A1295F7 for <int-area@ietfa.amsl.com>; Tue, 6 Dec 2016 15:43:18 -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 4ajAe2NZyLlf for <int-area@ietfa.amsl.com>; Tue, 6 Dec 2016 15:43:17 -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 0D9A91295EB for <int-area@ietf.org>; Tue, 6 Dec 2016 15:43:17 -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 uB6NgVMQ015216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Dec 2016 15:42:32 -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> <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> <09e2891ea6d4470681e04f162298a69f@XCH15-06-08.nw.nos.boeing.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <b2ca62af-cf10-d41a-03bb-9f56d00afd79@isi.edu>
Date: Tue, 06 Dec 2016 15:42:30 -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: <09e2891ea6d4470681e04f162298a69f@XCH15-06-08.nw.nos.boeing.com>
Content-Type: multipart/alternative; boundary="------------4B9E962BB163CAC0D2D11CFF"
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/d65JL5CG63tQdsSS2pTvpDGy7pk>
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 23:43:18 -0000


On 12/6/2016 3:39 PM, Templin, Fred L wrote:
>
> Hi Joe,
>
>  
>
> The areas I described are very much wrapped around mobility, and for AERO
>
> mobility is handled through dynamic neighbor cache updates over the AERO
>
> interface. It is very important that these mobility events do not get
> propagated
>
> into dynamic routing protocols like OSPF, which would clobber low data
> rate
>
> data links like LDACS and many varieties of SATCOM. Dynamic neighbor cache
>
> updates in the same manner as described in RFC4861 are the method employed
>
> by AERO.
>

Those can be integrated easily into updates to the IP forwarding table.
That need not propagate to other nodes, and the update can be via any
routing protocol you want (Aero's or otherwise).

The primary benefit of integration into existing IP forwarding is that
you CAN propagate these if you want, and you CAN integrate the impact of
those updates into IP forwarding decisions. If you have only one link,
that doesn't matter - but it does otherwise.

Joe