FW: Submitted for your approval: IRON
"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 17 December 2010 20:37 UTC
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: routing-discussion@core3.amsl.com
Delivered-To: routing-discussion@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E0E3A6BE5 for <routing-discussion@core3.amsl.com>; Fri, 17 Dec 2010 12:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.464
X-Spam-Level:
X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZMuxuJCZetT for <routing-discussion@core3.amsl.com>; Fri, 17 Dec 2010 12:37:18 -0800 (PST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id BC2953A6BC1 for <routing-discussion@ietf.org>; Fri, 17 Dec 2010 12:37:18 -0800 (PST)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id oBHKd3YU026173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <routing-discussion@ietf.org>; Fri, 17 Dec 2010 12:39:06 -0800 (PST)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id oBHKd3TX004131 for <routing-discussion@ietf.org>; Fri, 17 Dec 2010 12:39:03 -0800 (PST)
Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id oBHKd3Ja004126 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <routing-discussion@ietf.org>; Fri, 17 Dec 2010 12:39:03 -0800 (PST)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Fri, 17 Dec 2010 12:39:03 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "routing-discussion@ietf.org" <routing-discussion@ietf.org>
Date: Fri, 17 Dec 2010 12:39:01 -0800
Subject: FW: Submitted for your approval: IRON
Thread-Topic: Submitted for your approval: IRON
Thread-Index: AcuZvtMh3tC7vNZATBS1Ufdodlo+tgB/eBygAJttB9A=
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C68040295@XCH-NW-01V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: routing-discussion@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Area General mailing list <routing-discussion.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/routing-discussion>
List-Post: <mailto:routing-discussion@ietf.org>
List-Help: <mailto:routing-discussion-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Dec 2010 20:37:18 -0000
Fwd'd here from the intarea list. -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Tuesday, December 14, 2010 10:39 AM To: int-area@ietf.org Subject: [Int-area] Submitted for your approval: IRON Submitted for your approval, the Internet Routing Overlay Network (IRON) is a comprehensive new routing and addressing system for the Internet. The IRON architecture builds on the mechanisms of VET and SEAL, and expands upon the architectural principles established in RANGER. Relevant documents include: http://tools.ietf.org/html/draft-templin-iron http://tools.ietf.org/html/draft-templin-intarea-seal http://tools.ietf.org/html/draft-templin-intarea-vet http://www.rfc-editor.org/rfc/rfc5720.txt The IRON system uniquely combines a hybrid routing/mapping system that benefits from the both the shortest-path routing afforded by pure dynamic routing systems and the routing scaling suppression afforded by pure mapping systems. IRON therefore targets the elusive "sweet spot" that pure routing and pure mapping systems alone cannot satisfy. The IRON system requires a deployment of new routers/servers throughout the Internet and/or provider networks to maintain well-balanced virtual overlay networks. These routers/servers can be deployed incrementally without disruption to existing Internet infrastructure and appropriately managed to provide acceptable service levels to customers. End-to-end traffic that traverses an IRON virtual overlay network may experience delay variance between the initial packets and subsequent packets of a flow. This is due to the IRON system allowing longer path stretch for initial packets followed by timely route optimizations to utilize better next hop routers/servers for subsequent packets. Such delay variance is no different than for routing fluctuations that can occur within ordinary Internet routing. IRON virtual overlay networks also interact favorably with existing and emerging services within the native Internet. In particular, customers serviced by IRON virtual overlay networks will receive the same service enjoyed by customers serviced by non-IRON service providers. Internet services already deployed within the native Internet also need not make any changes to accommodate IRON virtual overlay network customers. The IRON system operates between routers within provider networks and end user networks. Within these networks, the underlying paths traversed by the virtual overlay networks may comprise links that accommodate varying MTUs. While the IRON system imposes an additional per-packet overhead that may cause the size of packets to become slightly larger than the underlying path can accommodate, IRON routers have a method for naturally detecting and tuning out all instances of path MTU underruns. In some cases, these MTU underruns may need to be reported back to the original hosts; however, the system will also allow for MTUs much larger than those typically available in current Internet paths to be discovered and utilized as more links with larger MTUs are deployed. Finally, and perhaps most importantly, the IRON system provides an in-built mobility management and multihoming capability that allows end user devices and networks to move about freely while both imparting minimal oscillations in the routing system and maintaining generally shortest-path routes. This mobility management is afforded through the very nature of the IRON customer/provider relationship, and therefore requires no adjunct mechanisms. The mobility management and multihoming capabilities are further supported by forward-path reachability detection that provides "hints of forward progress" in the same spirit as for IPv6 ND. What does all of this mean to the intarea? It means that there is now a unified solution proposal at hand that naturally accomodates the growth profiles and mobility/multihoming challenges that the Internet now faces. Moreover, it provides a comprehensive transition to IPv6 with full incremental deployment capability and with little or no disruption to the existing Internet. And finally, IRON is a complete solution rather than a piecemeal combination of adjunct mechanisms. IRON is therefore hereby submitted for your approval. Fred Templin fred.l.templin@boeing.com _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
- FW: Submitted for your approval: IRON Templin, Fred L
- FW: Submitted for your approval: IRON Templin, Fred L
- Re: FW: Submitted for your approval: IRON Masataka Ohta
- RE: FW: Submitted for your approval: IRON Templin, Fred L