From wwwrun@rfc-editor.org Fri Nov 9 16:49:43 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D837B21F86CE; Fri, 9 Nov 2012 16:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.067 X-Spam-Level: X-Spam-Status: No, score=-102.067 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRSHATWwrjcD; Fri, 9 Nov 2012 16:49:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD6A21F8686; Fri, 9 Nov 2012 16:49:43 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E37DF72E039; Fri, 9 Nov 2012 16:43:00 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org From: rfc-editor@rfc-editor.org Message-Id: <20121110004300.E37DF72E039@rfc-editor.org> Date: Fri, 9 Nov 2012 16:43:00 -0800 (PST) Cc: rrg@irtf.org, rfc-editor@rfc-editor.org Subject: [rrg] RFC 6740 on Identifier-Locator Network Protocol (ILNP) Architectural Description X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:49:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6740 Title: Identifier-Locator Network Protocol (ILNP) Architectural Description Author: RJ Atkinson, SN Bhatti Status: Experimental Stream: IRTF Date: November 2012 Mailbox: rja.lists@gmail.com, saleem@cs.st-andrews.ac.uk Pages: 53 Characters: 126139 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-rrg-ilnp-arch-06.txt URL: http://www.rfc-editor.org/rfc/rfc6740.txt This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document is a product of the Routing Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Nov 9 16:49:54 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2D721F8825; Fri, 9 Nov 2012 16:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.961 X-Spam-Level: X-Spam-Status: No, score=-101.961 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw9FJNOm9hHA; Fri, 9 Nov 2012 16:49:54 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D794C21F8820; Fri, 9 Nov 2012 16:49:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C0868B1E009; Fri, 9 Nov 2012 16:43:10 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org From: rfc-editor@rfc-editor.org Message-Id: <20121110004310.C0868B1E009@rfc-editor.org> Date: Fri, 9 Nov 2012 16:43:10 -0800 (PST) Cc: rrg@irtf.org, rfc-editor@rfc-editor.org Subject: [rrg] RFC 6741 on Identifier-Locator Network Protocol (ILNP) Engineering Considerations X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:49:55 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6741 Title: Identifier-Locator Network Protocol (ILNP) Engineering Considerations Author: RJ Atkinson, SN Bhatti Status: Experimental Stream: IRTF Date: November 2012 Mailbox: rja.lists@gmail.com, saleem@cs.st-andrews.ac.uk Pages: 38 Characters: 93512 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-rrg-ilnp-eng-06.txt URL: http://www.rfc-editor.org/rfc/rfc6741.txt This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document is a product of the Routing Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Nov 9 16:50:06 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6099421F8814; Fri, 9 Nov 2012 16:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.834 X-Spam-Level: X-Spam-Status: No, score=-100.834 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFOXMZnwkSjx; Fri, 9 Nov 2012 16:50:04 -0800 (PST) Received: from rfc-editor.org (unknown [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id DD25E21F8855; Fri, 9 Nov 2012 16:50:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D4017B1E00D; Fri, 9 Nov 2012 16:43:22 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org From: rfc-editor@rfc-editor.org Message-Id: <20121110004322.D4017B1E00D@rfc-editor.org> Date: Fri, 9 Nov 2012 16:43:22 -0800 (PST) Cc: rrg@irtf.org, rfc-editor@rfc-editor.org Subject: [rrg] RFC 6742 on DNS Resource Records for the Identifier-Locator Network Protocol (ILNP) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:50:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6742 Title: DNS Resource Records for the Identifier-Locator Network Protocol (ILNP) Author: RJ Atkinson, SN Bhatti, S. Rose Status: Experimental Stream: IRTF Date: November 2012 Mailbox: rja.lists@gmail.com, saleem@cs.st-andrews.ac.uk, scottr.nist@gmail.com Pages: 20 Characters: 42996 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-rrg-ilnp-dns-06.txt URL: http://www.rfc-editor.org/rfc/rfc6742.txt This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document is a product of the Routing Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Nov 9 16:50:18 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1001221F8881; Fri, 9 Nov 2012 16:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.012 X-Spam-Level: X-Spam-Status: No, score=-101.012 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov0aTI3MKws5; Fri, 9 Nov 2012 16:50:17 -0800 (PST) Received: from rfc-editor.org (unknown [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 98DA021F887D; Fri, 9 Nov 2012 16:50:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 910AAB1E012; Fri, 9 Nov 2012 16:43:35 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org From: rfc-editor@rfc-editor.org Message-Id: <20121110004335.910AAB1E012@rfc-editor.org> Date: Fri, 9 Nov 2012 16:43:35 -0800 (PST) Cc: rrg@irtf.org, rfc-editor@rfc-editor.org Subject: [rrg] RFC 6743 on ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:50:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6743 Title: ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) Author: RJ Atkinson, SN Bhatti Status: Experimental Stream: IRTF Date: November 2012 Mailbox: rja.lists@gmail.com, saleem@cs.st-andrews.ac.uk Pages: 12 Characters: 24972 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-rrg-ilnp-icmpv6-06.txt URL: http://www.rfc-editor.org/rfc/rfc6743.txt This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document is a product of the Routing Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Nov 9 16:50:30 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20FF21F88B6; Fri, 9 Nov 2012 16:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.907 X-Spam-Level: X-Spam-Status: No, score=-100.907 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJCtUXeU9jAd; Fri, 9 Nov 2012 16:50:30 -0800 (PST) Received: from rfc-editor.org (unknown [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5778421F889B; Fri, 9 Nov 2012 16:50:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 48934B1E015; Fri, 9 Nov 2012 16:43:47 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org From: rfc-editor@rfc-editor.org Message-Id: <20121110004347.48934B1E015@rfc-editor.org> Date: Fri, 9 Nov 2012 16:43:47 -0800 (PST) Cc: rrg@irtf.org, rfc-editor@rfc-editor.org Subject: [rrg] RFC 6744 on IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:50:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6744 Title: IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) Author: RJ Atkinson, SN Bhatti Status: Experimental Stream: IRTF Date: November 2012 Mailbox: rja.lists@gmail.com, saleem@cs.st-andrews.ac.uk Pages: 14 Characters: 33737 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-rrg-ilnp-noncev6-06.txt URL: http://www.rfc-editor.org/rfc/rfc6744.txt The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document is a product of the Routing Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Nov 9 16:50:56 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F411B21F8964; Fri, 9 Nov 2012 16:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQDjNmPBv3y3; Fri, 9 Nov 2012 16:50:55 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C141421F8956; Fri, 9 Nov 2012 16:50:54 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2AF7BB1E01E; Fri, 9 Nov 2012 16:44:09 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org From: rfc-editor@rfc-editor.org Message-Id: <20121110004409.2AF7BB1E01E@rfc-editor.org> Date: Fri, 9 Nov 2012 16:44:09 -0800 (PST) Cc: rrg@irtf.org, rfc-editor@rfc-editor.org Subject: [rrg] RFC 6746 on IPv4 Options for the Identifier-Locator Network Protocol (ILNP) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:50:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6746 Title: IPv4 Options for the Identifier-Locator Network Protocol (ILNP) Author: RJ Atkinson, SN Bhatti Status: Experimental Stream: IRTF Date: November 2012 Mailbox: rja.lists@gmail.com, saleem@cs.st-andrews.ac.uk Pages: 11 Characters: 24866 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-rrg-ilnp-v4opts-06.txt URL: http://www.rfc-editor.org/rfc/rfc6746.txt This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document is a product of the Routing Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Nov 9 16:50:57 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3494421F896F; Fri, 9 Nov 2012 16:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Nxzad0E1guK; Fri, 9 Nov 2012 16:50:56 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B70C121F8954; Fri, 9 Nov 2012 16:50:54 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AA80FB1E015; Fri, 9 Nov 2012 16:43:58 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org From: rfc-editor@rfc-editor.org Message-Id: <20121110004358.AA80FB1E015@rfc-editor.org> Date: Fri, 9 Nov 2012 16:43:58 -0800 (PST) Cc: rrg@irtf.org, rfc-editor@rfc-editor.org Subject: [rrg] RFC 6745 on ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:50:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6745 Title: ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) Author: RJ Atkinson, SN Bhatti Status: Experimental Stream: IRTF Date: November 2012 Mailbox: rja.lists@gmail.com, saleem@cs.st-andrews.ac.uk Pages: 12 Characters: 25137 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-rrg-ilnp-icmpv4-06.txt URL: http://www.rfc-editor.org/rfc/rfc6745.txt This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). ILNP is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document is a product of the Routing Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Nov 9 16:51:03 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093DF21F8A13; Fri, 9 Nov 2012 16:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UofO02SB0SK6; Fri, 9 Nov 2012 16:51:02 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7A63021F89EE; Fri, 9 Nov 2012 16:51:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6D643B1E01E; Fri, 9 Nov 2012 16:44:20 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org From: rfc-editor@rfc-editor.org Message-Id: <20121110004420.6D643B1E01E@rfc-editor.org> Date: Fri, 9 Nov 2012 16:44:20 -0800 (PST) Cc: rrg@irtf.org, rfc-editor@rfc-editor.org Subject: [rrg] RFC 6747 on Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:51:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6747 Title: Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) Author: RJ Atkinson, SN Bhatti Status: Experimental Stream: IRTF Date: November 2012 Mailbox: rja.lists@gmail.com, saleem@cs.st-andrews.ac.uk Pages: 12 Characters: 24322 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-rrg-ilnp-arp-07.txt URL: http://www.rfc-editor.org/rfc/rfc6747.txt This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community. This document is a product of the Routing Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Nov 9 16:51:18 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B110E21F86FC; Fri, 9 Nov 2012 16:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.405 X-Spam-Level: X-Spam-Status: No, score=-100.405 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zdqWW6ml+1i; Fri, 9 Nov 2012 16:51:17 -0800 (PST) Received: from rfc-editor.org (unknown [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id CACE321F8ACA; Fri, 9 Nov 2012 16:51:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0014BB1E020; Fri, 9 Nov 2012 16:44:29 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org, irtf-announce@irtf.org From: rfc-editor@rfc-editor.org Message-Id: <20121110004430.0014BB1E020@rfc-editor.org> Date: Fri, 9 Nov 2012 16:44:29 -0800 (PST) Cc: rrg@irtf.org, rfc-editor@rfc-editor.org Subject: [rrg] RFC 6748 on Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 00:51:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6748 Title: Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP) Author: RJ Atkinson, SN Bhatti Status: Experimental Stream: IRTF Date: November 2012 Mailbox: rja.lists@gmail.com, saleem@cs.st-andrews.ac.uk Pages: 37 Characters: 86535 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-irtf-rrg-ilnp-adv-06.txt URL: http://www.rfc-editor.org/rfc/rfc6748.txt This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. This document defines an Experimental Protocol for the Internet community. This document is a product of the Routing Research Group of the IRTF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist http://www.irtf.org/mailman/listinfo/irtf-announce For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From rja.lists@gmail.com Fri Nov 9 17:03:00 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6691E21F8A26 for ; Fri, 9 Nov 2012 17:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOI0IZAq5sD5 for ; Fri, 9 Nov 2012 17:03:00 -0800 (PST) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id CDD2A21F86FC for ; Fri, 9 Nov 2012 17:02:57 -0800 (PST) Received: by mail-vb0-f53.google.com with SMTP id fc21so4607198vbb.40 for ; Fri, 09 Nov 2012 17:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=pGztIGZ/3VDj8RJY05PWGHD0R9atUwAvSxltdGj04Bc=; b=K/sPxo0LkNtkJFbM/k9+wDYhq+WTRZEcseerykMq8cpO+7PQdA6j7xMIUSlnBnq0tR i5RA67v4IMtEThGgiHLUt6RBxY7zZhOZvgR2FmsubMVdHSb8YusvB3kLc17Rn7KtueVS voHBqMN6UisVRgsUZyID3yslq0uR5udO4ZV902zG9QQFYKfzvvXXDoDniS5oz9L+LHQy I5eDAF8e3eCh5eEOQknLyEoMasAjxVdiT300yoGVc+xdDDB6WFitrSdXHUmjiiXFZZX6 2DXR+82doLdPYgpJvzKMSrrmzNInAZwTPNlK8KmbdggXktLGRmpZCGr9dzfUtr0ShiiI Xypw== Received: by 10.52.92.97 with SMTP id cl1mr11154541vdb.65.1352509377183; Fri, 09 Nov 2012 17:02:57 -0800 (PST) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id ct5sm150762vdb.6.2012.11.09.17.02.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Nov 2012 17:02:56 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 9 Nov 2012 20:02:54 -0500 Message-Id: <198C35FD-2109-4450-ABA7-AA83A33DF99A@gmail.com> To: IRTF Routing RG Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [rrg] ILNP RFCs published X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 01:03:00 -0000 RFC-6740 through RFC-6748, which collectively describe the ILNP Architecture, ILNP Engineering, ILNP Optional Advanced Deployment Scenarios, ILNP for IPv4, and ILNP for IPv6, have just been published. Yours, Ran From tony.li@tony.li Fri Nov 9 18:33:40 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0F221F850A for ; Fri, 9 Nov 2012 18:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7a1GEXCHZzAA for ; Fri, 9 Nov 2012 18:33:40 -0800 (PST) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 2353B21F84E3 for ; Fri, 9 Nov 2012 18:33:40 -0800 (PST) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta15.emeryville.ca.mail.comcast.net with comcast id Me831k00816AWCUAFeZgtP; Sat, 10 Nov 2012 02:33:40 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta06.emeryville.ca.mail.comcast.net with comcast id MeXV1k00B52qHCY8SeXXSN; Sat, 10 Nov 2012 02:31:37 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <198C35FD-2109-4450-ABA7-AA83A33DF99A@gmail.com> Date: Fri, 9 Nov 2012 18:31:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <36E7E3F5-B8AB-4F82-838B-DCDEB6995165@tony.li> References: <198C35FD-2109-4450-ABA7-AA83A33DF99A@gmail.com> To: IRTF Routing RG X-Mailer: Apple Mail (2.1499) Subject: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 02:33:40 -0000 On Nov 9, 2012, at 5:02 PM, RJ Atkinson wrote: >=20 > RFC-6740 through RFC-6748, which collectively describe > the ILNP Architecture, ILNP Engineering, ILNP Optional > Advanced Deployment Scenarios, ILNP for IPv4, and=20 > ILNP for IPv6, have just been published. The publication of these RFCs concludes our long standing work item on a = revised routing architecture. =20 I would like to thank all of our authors of all of our various = proposals; all of our other contributors to the group who kept our = conversations lively and provocative; our esteemed IRTF chairs, Lars and = Aaron; and most of all my co-chair Lixia. The group has produced a prodigious number of ideas, debated them = intensely, and helped push the boundaries of routing farther forward. = It's true that it was not an easy path, but then worthwhile goals are = seldom achieved without difficulty. We have helped to create an = architecture that provides a major improvement to the overall = scalability of routing, and thereby enhances the reach of the Internet = for generations to come. But what a long strange trip it has been. ;-) The Research Group now transitions to a state of hibernation. = Researchers interested in further progress within the group should = contact myself or the IRTF chair with proposals for significant research = initiatives within routing and a demonstration of a sizable community = sufficient to undertake the necessary research. Pax vobiscum, Tony From jnc@mercury.lcs.mit.edu Fri Nov 9 19:29:46 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8543221F8586 for ; Fri, 9 Nov 2012 19:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiSMgICKzyBc for ; Fri, 9 Nov 2012 19:29:45 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id CEBC321F8578 for ; Fri, 9 Nov 2012 19:29:45 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BD27018C113; Fri, 9 Nov 2012 22:29:42 -0500 (EST) To: rrg@irtf.org Message-Id: <20121110032942.BD27018C113@mercury.lcs.mit.edu> Date: Fri, 9 Nov 2012 22:29:42 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 03:29:46 -0000 > From: Tony Li > The publication of these RFCs concludes our long standing work item on > a revised routing architecture. Separation of location and identity is very desirable, but it has basically nothing to do with routing (other than removing identity functionality from the names used for routing, making them a bit more tractable). We still have the same old kludgy BGP global routing system we always had, and _nothing_ has been proposed to improve/replace it. > The group has ... helped push the boundaries of routing farther > forward. Nonsense. It has produced no routing work at all. Noel From swb@internet2.edu Fri Nov 9 19:40:08 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D13621F84DD for ; Fri, 9 Nov 2012 19:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5aFI31rK9K3 for ; Fri, 9 Nov 2012 19:40:07 -0800 (PST) Received: from int-proxy02.merit.edu (int-proxy02.merit.edu [207.75.116.231]) by ietfa.amsl.com (Postfix) with ESMTP id A67BB21F84CD for ; Fri, 9 Nov 2012 19:40:07 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy02.merit.edu (Postfix) with ESMTP id 78467120458; Fri, 9 Nov 2012 22:40:06 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy02.merit.edu Received: from int-proxy02.merit.edu ([127.0.0.1]) by localhost (int-proxy02.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWz2mWdMI8oA; Fri, 9 Nov 2012 22:40:05 -0500 (EST) Received: from int-mailstore01.merit.edu (int-mailstore01.merit.edu [10.108.1.232]) by int-proxy02.merit.edu (Postfix) with ESMTP id 128A026802E; Fri, 9 Nov 2012 22:40:05 -0500 (EST) Date: Fri, 9 Nov 2012 22:40:05 -0500 (EST) Message-ID: From: Scott Brim To: Noel Chiappa MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 X-Mailer: Zimbra 7.2.1_GA_2790 (MobileSync - Android/4.1.2-EAS-1.3) Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 03:40:08 -0000 Well, this will be fun. Yes Noel, you're right, this group didn't produce any routing revolutions, and loc/id separation is about problems on the identity function side, not routing ... but this group's best accomplishment imho was to understand that and spread the knowledge. Now I'll go back to doing good things with higher layer identities. Ciao. Scott jnc@mercury.lcs.mit.edu wrote: > From: Tony Li > The publication of these RFCs concludes our long standing work item on > a revised routing architecture. Separation of location and identity is very desirable, but it has basically nothing to do with routing (other than removing identity functionality from the names used for routing, making them a bit more tractable). We still have the same old kludgy BGP global routing system we always had, and _nothing_ has been proposed to improve/replace it. > The group has ... helped push the boundaries of routing farther > forward. Nonsense. It has produced no routing work at all. Noel _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg From jnc@mercury.lcs.mit.edu Fri Nov 9 19:55:16 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B722B21F8CBB for ; Fri, 9 Nov 2012 19:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q1zYfYXGmcG for ; Fri, 9 Nov 2012 19:55:16 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0702921F8C51 for ; Fri, 9 Nov 2012 19:55:15 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1C6FC18C115; Fri, 9 Nov 2012 22:55:15 -0500 (EST) To: rrg@irtf.org Message-Id: <20121110035515.1C6FC18C115@mercury.lcs.mit.edu> Date: Fri, 9 Nov 2012 22:55:15 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 03:55:16 -0000 > From: Scott Brim > this group's best accomplishment imho was to understand that and spread > the knowledge. I didn't say the group had produced nothing of value. Clearly, the work on location/identity was useful. (Although it is regrettable that the IETF didn't take the concept on board when RFC-1498 was produced, in 1993, instead of taking almost 20 years to recognize the necessity of separating location and identity - the Internet would be a lot further along at this point if it had.) I just dispute the contention that it produced notable routing work - because it didn't. Which means that, since there _are_ needs for improved routing, we're now going to see the same scenario as I referred to above, with loc-id-sep, repeated in the area of routing - the IETF taking forever to grudgingly admit that what one would hope are seemingly obvious improvements are, in fact, necessary. The only question is, are we again going to see very long delays before that happen (perhaps two decades again)? And better routing is an order of magnitude more complex, technically, than loc-id-sep. So the pain/cost of upgrading _that_ will be that much greater. Noel From wherrin@gmail.com Sat Nov 10 05:42:34 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0904E21F8587 for ; Sat, 10 Nov 2012 05:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu24RSA0y2lZ for ; Sat, 10 Nov 2012 05:42:29 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4248321F8529 for ; Sat, 10 Nov 2012 05:42:29 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id wc20so6196423obb.13 for ; Sat, 10 Nov 2012 05:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=JLgWbHRPEW8MuFbXiD/zMbEzuegC8LmIdlgRPSlvUDg=; b=lMLwELqBlfwuiyTZcKqZy/bEvu5Lmg/PP3YuJ6n/rPGQk8qAB5RhGN8N4hIvDa2xCY EX0ls9w+g7vn8QYGL+WizlCOU4WN62J0iux8vuJ/vzRXJDES8Wb/jrFcCAcgYiA70j4z RFgLLBIr9W1l00bIaagc4zWAwc34RJOmXCTg4UKMfpwotfLhCSXOzE2d4XPY3eCRkv8B fgmgcGvlwHNV3LvDGuXtCr7Scz7fQgIImErk+rTRf0UiXLFFTLib7qg2EUxyp+m7fpOj CV8uQ19Ql5ZKltcsxsmI8LKW+XSunXveZLWqyj1uAhoAIWahkw8Vy/MqgU8D+GuKdInP YQBw== Received: by 10.60.14.6 with SMTP id l6mr10355278oec.87.1352554948716; Sat, 10 Nov 2012 05:42:28 -0800 (PST) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.182.81.164 with HTTP; Sat, 10 Nov 2012 05:42:08 -0800 (PST) In-Reply-To: <20121110032942.BD27018C113@mercury.lcs.mit.edu> References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> From: William Herrin Date: Sat, 10 Nov 2012 08:42:08 -0500 X-Google-Sender-Auth: uEdPuUguu7x-daXM3uPz9Hrq0I0 Message-ID: To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 13:42:34 -0000 On Fri, Nov 9, 2012 at 10:29 PM, Noel Chiappa wrote: >> From: Tony Li > We still have the same old kludgy BGP global routing system we always had, > and _nothing_ has been proposed to improve/replace it. > >> The group has ... helped push the boundaries of routing farther >> forward. > > Nonsense. It has produced no routing work at all. Hi Noel, I have a notion for a "routing" protocol which manages link changes through dynamic readdressing and multiply addressing hosts. By and large the addresses change so that the trivially aggregable routes don't have to. Not just at the host level but all the way downstream from the link change. Even bumps automatic resizing requirements upstream so that over time any given router offers exactly one route outward which automatically aggregates with the route its upstream already holds. It does require a new suite of transport protocols where layer 4 is as loosely bound to layer 3 as layer 3 currently is to layer 2, along with a new suite of APIs which don't expect the application layer to manage remote addresses. It's fresh. Might even be a genuinely new approach to routing. Are you game to flesh it out and see how far we can run with it, even though the odds of ever reaching deployment on an approach which requires us to abandon TCP and UDP are not good? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From danny@tcb.net Sat Nov 10 08:23:01 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A04D21F8566 for ; Sat, 10 Nov 2012 08:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpjmGVzwEDg7 for ; Sat, 10 Nov 2012 08:23:01 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 07F8B21F855E for ; Sat, 10 Nov 2012 08:23:01 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 507E120BA for ; Sat, 10 Nov 2012 16:23:00 +0000 (UTC) Received: from [192.168.5.132] (ip-64-134-70-192.public.wayport.net [64.134.70.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id BF53120AE; Sat, 10 Nov 2012 09:22:57 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <20121110032942.BD27018C113@mercury.lcs.mit.edu> Date: Sat, 10 Nov 2012 11:23:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Nov 10 09:23:00 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 509e7f64199631928769353 X-DSPAM-Factors: 27, their+#+#+certainly, 0.40000, global+routing, 0.40000, order+#+#+#+smart, 0.40000, had+#+#+has, 0.40000, to+#+to, 0.40000, per+#+#+#+of, 0.40000, signing+#+of, 0.40000, in+short, 0.40000, always+#+and, 0.40000, and+#+#+#+updates, 0.40000, it+No, 0.40000, PM+Noel, 0.40000, BGPSEC+#+and, 0.40000, of+#+#+#+here, 0.40000, Mime-Version*Message+#+v1283, 0.40000, perspective+#+#+#+of, 0.40000, periodic+#+#+per, 0.40000, things+#+#+updates, 0.40000, replace+#+#+#+I, 0.40000, nothing+has, 0.40000, Subject*Re+#+#+#+hibernation, 0.40000, extensions+#+things, 0.40000, we+#+#+BGPSEC, 0.40000, replacement+#+#+order, 0.40000, nothing+#+#+#+to, 0.40000, proposed+to, 0.40000, BGPSEC+#+#+things, 0.40000 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 16:23:01 -0000 On Nov 9, 2012, at 10:29 PM, Noel Chiappa wrote: >=20 > We still have the same old kludgy BGP global routing system we always = had, > and _nothing_ has been proposed to improve/replace it. No, but I suspect if we bolt on BGPSEC extensions and things like = "periodic updates" and per router signing & validation of updates, we're = going to need to work on a replacement in short order. Some of the smart folks here applying their perspective would certainly = be of value, methinks. -danny= From tony.li@tony.li Sat Nov 10 09:24:21 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6B621F8660 for ; Sat, 10 Nov 2012 09:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdjSiqVihpBK for ; Sat, 10 Nov 2012 09:24:19 -0800 (PST) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 3319D21F8640 for ; Sat, 10 Nov 2012 09:24:18 -0800 (PST) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta13.emeryville.ca.mail.comcast.net with comcast id Mt461k0041wfjNsADtQJDX; Sat, 10 Nov 2012 17:24:18 +0000 Received: from [192.168.2.103] ([98.248.36.188]) by omta23.emeryville.ca.mail.comcast.net with comcast id MtQG1k00W43ZcXW8jtQHm3; Sat, 10 Nov 2012 17:24:17 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> Date: Sat, 10 Nov 2012 09:24:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 17:24:21 -0000 Amazing. For years, I unsuccessfully try to spark discussions. Then I = say that we're done and THAT sparks discussions. ;-) >> We still have the same old kludgy BGP global routing system we always = had, >> and _nothing_ has been proposed to improve/replace it. Blatantly not true. There's this thing called NIMROD that has been = proposed to replace it. Perhaps you've heard of it? ;-) > No, but I suspect if we bolt on BGPSEC extensions and things like = "periodic updates" and per router signing & validation of updates, we're = going to need to work on a replacement in short order. >=20 > Some of the smart folks here applying their perspective would = certainly be of value, methinks. I agree that some security needs to be deployed. I'm not convinced that = it needs to be BGPSEC. We've muddled along for many years and never = found the gumption to actually deploy anything. Must not be important = to people. I don't get it, but that's the observable behavior. =20 In any case, this doesn't seem like a research topic. This is pretty = clearly an engineering issue. Tony From danny@tcb.net Sat Nov 10 09:34:58 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD4B21F8567 for ; Sat, 10 Nov 2012 09:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAOhiJeDRh2j for ; Sat, 10 Nov 2012 09:34:58 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 5B56521F8566 for ; Sat, 10 Nov 2012 09:34:58 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D84AE20AD for ; Sat, 10 Nov 2012 17:34:57 +0000 (UTC) Received: from [192.168.5.132] (ip-64-134-70-192.public.wayport.net [64.134.70.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id DC59B2064; Sat, 10 Nov 2012 10:34:56 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Sat, 10 Nov 2012 12:35:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> To: Tony Li X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Nov 10 10:34:57 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 509e9041199638157514589 X-DSPAM-Factors: 27, an+engineering, 0.40000, routed+#+#+Internet, 0.40000, for+#+years, 0.40000, routing+#+#+#+Internet, 0.40000, update+#+#+#+serious, 0.40000, of+#+#+update, 0.40000, proposed+#+#+it, 0.40000, serious+#+#+on, 0.40000, that+SIDR, 0.40000, adoption+#+government, 0.40000, global+routing, 0.40000, Tony+#+#+#+still, 0.40000, what+#+designed, 0.40000, tomorrow+#+#+has, 0.40000, Perhaps+#+#+#+it, 0.40000, don't+#+#+engineering, 0.40000, to+#+#+in, 0.40000, pretty+clearly, 0.40000, an+#+#+scares, 0.40000, to+#+#+We've, 0.40000, thing+#+#+that, 0.40000, standards+#+#+like, 0.40000, hes+got, 0.40000, on+#+#+would, 0.40000, considering+#+they've, 0.40000, behavior+In, 0.40000, the+#+#+actually, 0.40000 Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 17:34:59 -0000 On Nov 10, 2012, at 12:24 PM, Tony Li wrote: >=20 >>> We still have the same old kludgy BGP global routing system we = always had, >>> and _nothing_ has been proposed to improve/replace it. >=20 > Blatantly not true. There's this thing called NIMROD that has been = proposed to replace it. Perhaps you've heard of it? ;-) That's Noel's comment, I suspect hes got some perspective on that :-) > I agree that some security needs to be deployed. I'm not convinced = that it needs to be BGPSEC. We've muddled along for many years and = never found the gumption to actually deploy anything. Must not be = important to people. I don't get it, but that's the observable = behavior. =20 >=20 > In any case, this doesn't seem like a research topic. This is pretty = clearly an engineering issue. I don't agree. The engineering solution that SIDR is actively working = (RPKI-enabled BGPSEC) is pumping out standards track RFCs like there's = no tomorrow. The USG has stated intentions of "expediting secure = routing work through the Internet standard process" and "fostering = adoption through government procurement vehicles". =20 As an operator this scares the hell out of me, especially considering = what they've designed is largely a system to control "what's routed on = the Internet and by whom". They can't seem to do anything in BGP(SEC) = without introducing the equivalent of "periodic updates", and undoing = all the goodness of things like update packing completely. =20 Some serious thinkers working on this problem would be goodness... -danny= From tony.li@tony.li Sat Nov 10 09:54:40 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF9F21F84AE for ; Sat, 10 Nov 2012 09:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2ZVyxagd5YL for ; Sat, 10 Nov 2012 09:54:40 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4107021F849B for ; Sat, 10 Nov 2012 09:54:39 -0800 (PST) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id Mqkr1k0061smiN4A1tuftz; Sat, 10 Nov 2012 17:54:39 +0000 Received: from [192.168.2.103] ([98.248.36.188]) by omta20.emeryville.ca.mail.comcast.net with comcast id Mtud1k00P43ZcXW8gtue7k; Sat, 10 Nov 2012 17:54:39 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Sat, 10 Nov 2012 09:54:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7CBB1514-5A26-4B12-BAA3-BF2AA3CC80F4@tony.li> References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 17:54:40 -0000 >> I agree that some security needs to be deployed. I'm not convinced = that it needs to be BGPSEC. We've muddled along for many years and = never found the gumption to actually deploy anything. Must not be = important to people. I don't get it, but that's the observable = behavior. =20 >>=20 >> In any case, this doesn't seem like a research topic. This is pretty = clearly an engineering issue. >=20 > I don't agree. The engineering solution that SIDR is actively working = (RPKI-enabled BGPSEC) is pumping out standards track RFCs like there's = no tomorrow. The USG has stated intentions of "expediting secure = routing work through the Internet standard process" and "fostering = adoption through government procurement vehicles". =20 >=20 > As an operator this scares the hell out of me, especially considering = what they've designed is largely a system to control "what's routed on = the Internet and by whom". They can't seem to do anything in BGP(SEC) = without introducing the equivalent of "periodic updates", and undoing = all the goodness of things like update packing completely. =20 >=20 > Some serious thinkers working on this problem would be goodness=85 I agree, but as you correctly point out, SIDR is an engineering = solution. If you dislike that particular solution, you're of course = free to propose others. However, the correct forum for engineering = solutions is the IETF. =20 Tony From shane@castlepoint.net Sat Nov 10 17:39:02 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7477021F850A for ; Sat, 10 Nov 2012 17:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzSFu4zS0SP2 for ; Sat, 10 Nov 2012 17:39:01 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id A770921F84F2 for ; Sat, 10 Nov 2012 17:39:01 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 429A9119 for ; Sun, 11 Nov 2012 01:39:00 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id CACE1EF for ; Sat, 10 Nov 2012 18:38:59 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Sat, 10 Nov 2012 18:38:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <81767641-8399-466D-A9F2-F2C07D3BBE0C@castlepoint.net> References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> To: rrg@irtf.org X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Nov 10 18:39:00 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 509f01b4199631755924084 X-DSPAM-Factors: 27, within+#+#+of, 0.40000, messaging+#+in, 0.40000, the+#+#+WG, 0.40000, an+engineering, 0.40000, a+#+mix, 0.40000, routed+#+#+Internet, 0.40000, for+#+years, 0.40000, size+#+coupled, 0.40000, and+#+recover, 0.40000, with+#+#+#+presents, 0.40000, routing+#+#+#+Internet, 0.40000, update+#+#+#+serious, 0.40000, of+#+#+update, 0.40000, if+#+downstream, 0.40000, bus+#+#+#+mechanism, 0.40000, serious+#+#+on, 0.40000, the+large, 0.40000, to+#+#+making, 0.40000, BGP+#+#+against, 0.40000, to+#+#+#+to, 0.40000, that+#+single, 0.40000, that+SIDR, 0.40000, ultimately+#+#+is, 0.40000, presents+#+#+#+a, 0.40000, application+#+#+#+describing, 0.40000, neighbor+#+#+AS, 0.40000, for+#+operational, 0.40000 Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 01:39:02 -0000 On Nov 10, 2012, at 10:35 AM, Danny McPherson wrote: > On Nov 10, 2012, at 12:24 PM, Tony Li wrote: [--snip--] >> I agree that some security needs to be deployed. I'm not convinced = that it needs to be BGPSEC. We've muddled along for many years and = never found the gumption to actually deploy anything. Must not be = important to people. I don't get it, but that's the observable = behavior. =20 >>=20 >> In any case, this doesn't seem like a research topic. This is pretty = clearly an engineering issue. >=20 > I don't agree. The engineering solution that SIDR is actively working = (RPKI-enabled BGPSEC) is pumping out standards track RFCs like there's = no tomorrow. The USG has stated intentions of "expediting secure = routing work through the Internet standard process" and "fostering = adoption through government procurement vehicles". =20 >=20 > As an operator this scares the hell out of me, especially considering = what they've designed is largely a system to control "what's routed on = the Internet and by whom". They can't seem to do anything in BGP(SEC) = without introducing the equivalent of "periodic updates", and undoing = all the goodness of things like update packing completely. =20 >=20 > Some serious thinkers working on this problem would be goodness... Let me add that I share Danny's concerns ... However, let me try to take a step back and share with everyone a much = broader set of, potentially, architectural concerns that I'm not sure = this RG considered during the last round. BGP was originally designed for flooding of reachability information. = But, reachability information is the end-result /after/ the application = of _routing_policy_, describing "intent", by operators of individual = networks based on various contractual agreements they have with parties = whom they directly interconnect. Assuming you agree with this premise, = this presents a paradox from a security PoV. Specifically, if a = downstream network does not have visibility into its upstream network's = routing policy is it practical/feasible for the downstream network to = understand the _intended_ propagation of reachability information and, = ultimately, connectivity? Furthermore, is it feasible to carry such = information within the control plane itself? Or, should the control = plane be relegated to carrying [strictly] reachability information in = real-time, while offboard systems carry accompanying routing policy and = security information in order to assist in making "optimal" Inter-Domain = routing/forwarding decisions? A second concern is also related to the original design of BGP and what = it has organically involved into, today. Specifically, BGP is /also/ = now being tasked as a generic "message bus" and service discovery = mechanism. Not to pick on anyone, in particular, but the following are = recent examples that come to my mind wrt this trend: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-01 http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 ... and, there may be others. Although, contrast those proposals with = what should be most concerning to people in this RG, and in the IETF: = http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling= -05 In short, operators (such as myself) are _extremely_ concerned that a = single erroneous update results in a complete reset of BGP sessions. = Due to the overwhelming success of BGP, it's now (and, has been for a = while) a mission-critical protocol, thus such catastrophic session = resets -- caused by a single malformed UPDATE -- are widely = visible/impactful. This impact is compounded by the 'cost to recover'. = Namely, due to the large and growing amount of information in the RIB = (again, not just reachability, but also service-discovery and completely = orthogonal information), it takes longer to exchange RIB information = and, ultimately, restore services. Is this really the best we, as an = industry, can do? While the IETF IDR WG has been looking at mechanisms for how BGP may = defend against certain types of erroneous BGP UPDATE's for external BGP = sessions: http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 ... there does not appear to be any [straightforward] answer with = respect to internal BGP sessions, given the requirement that BGP = speakers internal to an AS must have a globally consistent RIB and FIB, = otherwise packet forwarding loops will result. And, in my personal = operational experience it's _rarely_ the case that malformed UPDATE's = are detected at the first ASBR (attached to an eBGP neighbor) in my AS, = thus it concerns me that mechanisms such as = draft-ietf-idr-error-handling-02 are an adequate solution to the = problems we experience. IOW, as an operator I desire "defense in depth" = where a heterogeneous mix of vendor equipment (HW + SW), participating = as interior BGP speakers, have mechanisms to detect *and* automatically = recover from malformed UDPATE's received over iBGP sessions. This is = another area that I would point research colleagues toward. So, this raises the classic conundrum of: increasing complexity, = increasing RIB (and FIB) size information coupled with a contrasting = need from operators who are concerned about the robustness of the = protocol and the requirement to NOT sustain any failures[1]. = Something's got to give. Ultimately, this makes me question whether it's no longer _just_ growth = of RIB (and, FIB) size that this RG should be (primarily?) focused on. = Rather, will the requirements for: a) operational robustness, in the face of critical messaging errors in = an Inter-Domain Routing Protocol, which the IETF may be unable to = address on its own; b) designing security as a first-class principle of an Inter-Domain = Routing Protocol -- either carried within or outside of control-plane = reachability information c) increased scalability of RIB (and, other?) information ... lead us down a path of considering we may be approaching the = end-of-the-road for BGPv4 and we need something new? Does anyone on this list share similar concerns wrt operational = robustness, time to recovery and (then) scalability of BGPv4? -shane [1] It is not cool to suggest that operators should just stop asking for = new features and we wouldn't have this problem. :)= From lear@cisco.com Sun Nov 11 02:22:21 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C4621F8920 for ; Sun, 11 Nov 2012 02:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.593 X-Spam-Level: X-Spam-Status: No, score=-110.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhPHCTtYSTqv for ; Sun, 11 Nov 2012 02:22:20 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id CC1FB21F891F for ; Sun, 11 Nov 2012 02:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=722; q=dns/txt; s=iport; t=1352629340; x=1353838940; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HD1p920T5CGp0b1TPPSSZrCSXzchRJ8FHW3XHlxQIb4=; b=gcxh5/pHeOt8b87+mrsuhS31AIhykH+nCjKBP+7jPi0KI+lEzPWThkgB wk5SIs2qlPbwphuDQiVw3rHyQPO84MjSLyTE7jPYboBXMYsfc775JlpZw EmC8dG/gvjPoUUIK0/a9VlHIT8wOTjMegFS6WFnSiSHCgoGnf9zpOtf4D o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPR6n1CQ/khR/2dsb2JhbABEhhm9OoEIgh8BAQQSARAPAUUBEAsaAgUWCwICCQMCAQIBRQYNAQcBAR6HaJwcjSeRZIEikCqBEwOVfI5YgWuCcA X-IronPort-AV: E=McAfee;i="5400,1158,6892"; a="9486765" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 11 Nov 2012 10:22:18 +0000 Received: from dhcp-10-55-88-47.cisco.com (dhcp-10-55-88-47.cisco.com [10.55.88.47]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qABAMHwX010537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2012 10:22:18 GMT Message-ID: <509F7C59.7080900@cisco.com> Date: Sun, 11 Nov 2012 11:22:17 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tony Li References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> <7CBB1514-5A26-4B12-BAA3-BF2AA3CC80F4@tony.li> In-Reply-To: <7CBB1514-5A26-4B12-BAA3-BF2AA3CC80F4@tony.li> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 10:22:22 -0000 Tony, First, thanks for taking on and navigating work within the RRG for as long as you have done. I think people forget that this group has induced a tremendous amount of stress and turbulence over time, and that you were often the target of that stress. This having been said, I think this group like any other group – based on contributions and participation. If there are no contributions and if there is no participation, no work can continue. On the other hand, when there are contributions or participation, we shouldn't be hasty in closing the effort. Therefore, I would suggest a solicitation for new topics with the threat of closure, before actually closing – or going dormant. Eliot From tony.li@tony.li Sun Nov 11 09:45:48 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8C421F8555 for ; Sun, 11 Nov 2012 09:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27zM9ReDX834 for ; Sun, 11 Nov 2012 09:45:48 -0800 (PST) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by ietfa.amsl.com (Postfix) with ESMTP id 31C4F21F84CD for ; Sun, 11 Nov 2012 09:45:48 -0800 (PST) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta10.emeryville.ca.mail.comcast.net with comcast id NHYl1k0030vp7WLAAHlnSU; Sun, 11 Nov 2012 17:45:47 +0000 Received: from [192.168.2.103] ([98.248.36.188]) by omta05.emeryville.ca.mail.comcast.net with comcast id NHlZ1k00h43ZcXW8RHllrE; Sun, 11 Nov 2012 17:45:47 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <509F7C59.7080900@cisco.com> Date: Sun, 11 Nov 2012 09:45:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> <7CBB1514-5A26-4B12-BAA3-BF2AA3CC80F4@tony.li> <509F7C59.7080900@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:45:48 -0000 On Nov 11, 2012, at 2:22 AM, Eliot Lear wrote: > This having been said, I think this group like any other group =96 = based > on contributions and participation. If there are no contributions and > if there is no participation, no work can continue. On the other = hand, > when there are contributions or participation, we shouldn't be hasty = in > closing the effort. Therefore, I would suggest a solicitation for new > topics with the threat of closure, before actually closing =96 or = going > dormant. Eliot, Thanks, but as you may recall, we did do a solicitation of new topics = some time ago. It didn't provoke anything substantive and there has = been no additional input. Further, the transition to hibernation is easily reversed if and when a = new substantive topic presents itself. Tony From heinerhummel@aol.com Sun Nov 11 11:53:00 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE9B21F84DD for ; Sun, 11 Nov 2012 11:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJk8rQbsIko9 for ; Sun, 11 Nov 2012 11:52:59 -0800 (PST) Received: from imr-da02.mx.aol.com (imr-da02.mx.aol.com [205.188.105.144]) by ietfa.amsl.com (Postfix) with ESMTP id D851A21F84DA for ; Sun, 11 Nov 2012 11:52:58 -0800 (PST) Received: from mtaomg-mb02.r1000.mx.aol.com (mtaomg-mb02.r1000.mx.aol.com [172.29.41.73]) by imr-da02.mx.aol.com (Outbound Mail Relay) with ESMTP id 3B7391C000095; Sun, 11 Nov 2012 14:52:58 -0500 (EST) Received: from core-dqa002b.r1000.mail.aol.com (core-dqa002.r1000.mail.aol.com [172.29.211.197]) by mtaomg-mb02.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id 0554EE000088; Sun, 11 Nov 2012 14:52:58 -0500 (EST) To: swb@internet2.edu, jnc@mercury.lcs.mit.edu X-MB-Message-Source: WebUI Received: from 178.27.21.1 by webmail-m019.sysops.aol.com (64.12.101.103) with HTTP (WebMailUI); Sun, 11 Nov 2012 14:52:57 -0500 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CF8E5D483959BE_914_D9800_webmail-m019.sysops.aol.com" X-Mailer: Webmail 37130-STANDARD Message-Id: <8CF8E5D4815A51E-914-3A6E4@webmail-m019.sysops.aol.com> X-Originating-IP: [178.27.21.1] Date: Sun, 11 Nov 2012 14:52:57 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1352663578; bh=tgbjYdHQMcghSQmnNrP203qKoYWWIdSFTQV4moy1GCY=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=FutfE5WH49bqN/Lv1uNcoHupi3XDEV9McPHLsUkBqhn7GdScl5do8qipQ3Ar4g9Hl S0Ouw7+Z4hZG4nWJhsG9SYQ7oLfqE7YCmG93vP3oS/Es07F+2zgCx+QNMN9hcN4yZA zKrlUJFQHwCZZIUs0ir58vVnQgA6CbCwSHFvnR8o= X-AOL-SCOLL-SCORE: 0:2:481120192:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d294950a0021a225d Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 19:53:00 -0000 This is a multi-part message in MIME format. ----------MB_8CF8E5D483959BE_914_D9800_webmail-m019.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I an not pleased ether. One group goes ahead with LISP-DDT, which is doomed to fail ! With drums an= d trumpets! As sure as the Amen in church ! With no rescuing trick in sight= !=20 The other group believes in IPv6. I admit, I don't know what is special abo= ut IPv6. All I know is that the inventors came up with a crazy address spac= e and I do remember voices from many many years ago which proclaimed the ad= vent of the internet for our galaxy.I am sure, IPv6 would only create addit= ional scalability problems. Imagine a future where we have only IPv6. Hereb= y imagine New York at New Year's Eve and several hundred thousand people op= erating as mobile sender's of IPv6-multicast instances with multicast rece= ivers far away (which may as well be mobile) ! We wouldn't not only have a= scalability problem wrt forwarding but as well with respect to identifying= the individual entities. How many IPv6-addresses are needed to identify on= e single mobile multicast instance? 1? 2? 3? How should it be retrieved by = software? Loc/id-split: =20 Obviously what is a locator and whether there are several components thereo= f or not hasn't been understood. A unicast locator MUST BE location-indicating! A multicast -locator CANNOT = but this doesn't mean that there can't be any. Topology-aware BGP: Distance Vector versus Dijsktra. DV will never tell you about the upstream network (see also Shane Amante's = email). This is a disaster if you want to manage traffic load (balance/ dis= solve congestion) :-( Reachability: We don't need reachability. we only need to know where is the= indicated location !!! Location based routing means no user reachability = dissemination, only location reachability dissemination! Whenever I addressed these issues it was like I had sinned against some hol= y paradigm. And we are far away from better routing: I you only know the ALL-Nodes-Spanning-Tree (and not the All-Links-Spanning= -Tree) then you call it Spanning Tree per se. If you only know the Unicast-FIB (and not a Multicast-FIB, nor a Anycast-FI= B) then you call it FIB per se. To reach a higher level you must view things from a greater distance and so= metimes leave the old trails behind you. Ich habe fertig Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Scott Brim An: Noel Chiappa Cc: rrg Verschickt: Sa, 10 Nov 2012 4:40 am Betreff: Re: [rrg] RRG to hibernation Well, this will be fun. Yes Noel, you're right, this group didn't produce a= ny=20 routing revolutions, and loc/id separation is about problems on the identit= y=20 function side, not routing ... but this group's best accomplishment imho wa= s to=20 understand that and spread the knowledge.=20 Now I'll go back to doing good things with higher layer identities. Ciao. Scott jnc@mercury.lcs.mit.edu wrote: > From: Tony Li > The publication of these RFCs concludes our long standing work item o= n > a revised routing architecture. Separation of location and identity is very desirable, but it has basically nothing to do with routing (other than removing identity functionality from the names used for routing, making them a bit more tractable). We still have the same old kludgy BGP global routing system we always had, and _nothing_ has been proposed to improve/replace it. > The group has ... helped push the boundaries of routing farther > forward. Nonsense. It has produced no routing work at all. =09Noel _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg =20 =20 ----------MB_8CF8E5D483959BE_914_D9800_webmail-m019.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
I an not pleased ether.
One group goes ahead with LISP-DDT, which is doomed to fail ! With dru= ms and trumpets! As sure as the Amen in church ! With no rescuing trick in = sight! 
The other group believes in IPv6. I admit, I don't know what is specia= l about IPv6. All I know is that the inventors came up with a crazy address= space and I do remember voices from many many years ago which proclaimed t= he advent of the internet for our galaxy.I am sure, IPv6 would only create = additional scalability problems. Imagine a future where we have only IPv6. = Hereby imagine New York at New Year's Eve and several hundred thousand peop= le operating as mobile sender's of  IPv6-multicast instances with mult= icast receivers far away (which may as well be mobile) !  We wouldn't = not only have a scalability problem wrt forwarding but as well with respect= to identifying the individual entities. How many IPv6-addresses are needed= to identify one single mobile multicast instance? 1? 2? 3? How should it b= e retrieved by software?

Loc/id-split:  
Obviously what is a locator and whether there are several components t= hereof or not hasn't been understood.
A unicast locator MUST BE location-indicating! A multicast -locator CA= NNOT but this doesn't mean that there can't be any.

Topology-aware BGP:
Distance Vector versus Dijsktra.
DV will never tell you about the upstream network (see also Shane Aman= te's email). This is a disaster if you want to manage traffic load (balance= / dissolve congestion) :-(
Reachability: We don't need reachability. we only need to know where i= s the indicated location !!!  Location based routing means no user rea= chability dissemination,  only location reachability dissemination!

Whenever I addressed these issues it was like I had sinned against som= e holy paradigm.

And we are far away from better routing:
I you only know the ALL-Nodes-Spanning-Tree (and not the All-Links-Spa= nning-Tree) then you call it Spanning Tree per se.
If you only know the Unicast-FIB (and not a Multicast-FIB, nor a Anyca= st-FIB)  then you call it FIB per se.

To reach a higher level you must view things from a greater distance a= nd sometimes leave the old trails behind you.

Ich habe fertig
Heiner









-----= Urspr=C3=BCngliche Mitteilung-----
Von: Scott Brim <swb@internet2.edu>
An: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: rrg <rrg@irtf.org>
Verschickt: Sa, 10 Nov 2012 4:40 am
Betreff: Re: [rrg] RRG to hibernation

Well, this will be fun. Yes Noel, you're=
 right, this group didn't produce any=20
routing revolutions, and loc/id separation is about problems on the identit=
y=20
function side, not routing ... but this group's best accomplishment imho wa=
s to=20
understand that and spread the knowledge.=20

Now I'll go back to doing good things with higher layer identities.  Ciao.

Scott

jnc@me=
rcury.lcs.mit.edu wrote:

    > From: Tony Li <tony.li@tony.li>

    > The publication of these RFCs concludes our long standing work ite=
m on
    > a revised routing architecture.

Separation of location and identity is very desirable, but it has basically
nothing to do with routing (other than removing identity functionality from
the names used for routing, making them a bit more tractable).

We still have the same old kludgy BGP global routing system we always had,
and _nothing_ has been proposed to improve/replace it.

    > The group has ... helped push the boundaries of routing farther
    > forward.

Nonsense. It has produced no routing work at all.

=09Noel
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
----------MB_8CF8E5D483959BE_914_D9800_webmail-m019.sysops.aol.com-- From mahafaye@gmail.com Sun Nov 11 14:24:49 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2715721F84CD for ; Sun, 11 Nov 2012 14:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-9napbd5t9w for ; Sun, 11 Nov 2012 14:24:47 -0800 (PST) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id C1E3221F84B1 for ; Sun, 11 Nov 2012 14:24:46 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id k10so5219991iag.13 for ; Sun, 11 Nov 2012 14:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xwl0WV7xh1QbH+WiSlz0TZ58m9Y+06kao9S3Lp9htmE=; b=Bp8L0v6HKF2Jrqfr2Pzn6YJ9czOEl85J19KBhgDA3zVZo0ex8lztuG0e2xMvPTOPtu ws3iBqxVrF8w1MQ0hep479qgxYdoHQbY07sMfYxp+kVEP7LCkqhwm6jotRxH6EiWsqw8 3uXOL6cNoZLVH3q0dBPu2bG0eb7OQdj3rgPorKN/6KsTx26d3/wavRstyiAMy/xo46dK 5LdzzKN3NRwfJfYFNcJjvK2lCF/E3h1zw5uir9sEQMZpX5C62gRYtb3a5SweMtMzejt5 hMw3FmTzKPjUEVR7EJLLZEj5UKW5t6RZ9Tj2ne0MR5hwt4FYJFf1LvrOZsQ/kZ0FSpSN B+Dw== MIME-Version: 1.0 Received: by 10.43.97.8 with SMTP id ci8mr17273500icc.28.1352672686227; Sun, 11 Nov 2012 14:24:46 -0800 (PST) Received: by 10.64.98.101 with HTTP; Sun, 11 Nov 2012 14:24:46 -0800 (PST) Received: by 10.64.98.101 with HTTP; Sun, 11 Nov 2012 14:24:46 -0800 (PST) In-Reply-To: References: Date: Sun, 11 Nov 2012 22:24:46 +0000 Message-ID: From: Mohamed Faye To: rrg@irtf.org Content-Type: multipart/alternative; boundary=bcaec517ce76f5bf1504ce3fa6e8 Subject: Re: [rrg] rrg Digest, Vol 44, Issue 4 X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 22:24:49 -0000 --bcaec517ce76f5bf1504ce3fa6e8 Content-Type: text/plain; charset=ISO-8859-1 Hello all, Am new to this working group, and I found some of the topics been discuss are really good. But I will like to know what are the most recent topics to caught up with. Regards MFAYE On Nov 11, 2012 8:00 PM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > http://www.irtf.org/mailman/listinfo/rrg > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send rrg mailing list submissions to > rrg@irtf.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.irtf.org/mailman/listinfo/rrg > or, via email, send a message with subject or body 'help' to > rrg-request@irtf.org > > You can reach the person managing the list at > rrg-owner@irtf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of rrg digest..." > > > Today's Topics: > > 1. Re: RRG to hibernation (Shane Amante) > 2. Re: RRG to hibernation (Eliot Lear) > 3. Re: RRG to hibernation (Tony Li) > 4. Re: RRG to hibernation (heinerhummel@aol.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 10 Nov 2012 18:38:57 -0700 > From: Shane Amante > To: rrg@irtf.org > Subject: Re: [rrg] RRG to hibernation > Message-ID: <81767641-8399-466D-A9F2-F2C07D3BBE0C@castlepoint.net> > Content-Type: text/plain; charset=us-ascii > > > On Nov 10, 2012, at 10:35 AM, Danny McPherson wrote: > > On Nov 10, 2012, at 12:24 PM, Tony Li wrote: > [--snip--] > >> I agree that some security needs to be deployed. I'm not convinced > that it needs to be BGPSEC. We've muddled along for many years and never > found the gumption to actually deploy anything. Must not be important to > people. I don't get it, but that's the observable behavior. > >> > >> In any case, this doesn't seem like a research topic. This is pretty > clearly an engineering issue. > > > > I don't agree. The engineering solution that SIDR is actively working > (RPKI-enabled BGPSEC) is pumping out standards track RFCs like there's no > tomorrow. The USG has stated intentions of "expediting secure routing work > through the Internet standard process" and "fostering adoption through > government procurement vehicles". > > > > As an operator this scares the hell out of me, especially considering > what they've designed is largely a system to control "what's routed on the > Internet and by whom". They can't seem to do anything in BGP(SEC) without > introducing the equivalent of "periodic updates", and undoing all the > goodness of things like update packing completely. > > > > Some serious thinkers working on this problem would be goodness... > > Let me add that I share Danny's concerns ... > > However, let me try to take a step back and share with everyone a much > broader set of, potentially, architectural concerns that I'm not sure this > RG considered during the last round. > > BGP was originally designed for flooding of reachability information. > But, reachability information is the end-result /after/ the application of > _routing_policy_, describing "intent", by operators of individual networks > based on various contractual agreements they have with parties whom they > directly interconnect. Assuming you agree with this premise, this presents > a paradox from a security PoV. Specifically, if a downstream network does > not have visibility into its upstream network's routing policy is it > practical/feasible for the downstream network to understand the _intended_ > propagation of reachability information and, ultimately, connectivity? > Furthermore, is it feasible to carry such information within the control > plane itself? Or, should the control plane be relegated to carrying > [strictly] reachability information in real-time, while offboard systems > carry accompanying routing policy and security information in order to > assist in making "optimal" Inter-Domain rou > ting/forwarding decisions? > > A second concern is also related to the original design of BGP and what it > has organically involved into, today. Specifically, BGP is /also/ now > being tasked as a generic "message bus" and service discovery mechanism. > Not to pick on anyone, in particular, but the following are recent > examples that come to my mind wrt this trend: > http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-01 > http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 > ... and, there may be others. Although, contrast those proposals with > what should be most concerning to people in this RG, and in the IETF: > > http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 > In short, operators (such as myself) are _extremely_ concerned that a > single erroneous update results in a complete reset of BGP sessions. Due > to the overwhelming success of BGP, it's now (and, has been for a while) a > mission-critical protocol, thus such catastrophic session resets -- caused > by a single malformed UPDATE -- are widely visible/impactful. This impact > is compounded by the 'cost to recover'. Namely, due to the large and > growing amount of information in the RIB (again, not just reachability, but > also service-discovery and completely orthogonal information), it takes > longer to exchange RIB information and, ultimately, restore services. Is > this really the best we, as an industry, can do? > > While the IETF IDR WG has been looking at mechanisms for how BGP may > defend against certain types of erroneous BGP UPDATE's for external BGP > sessions: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 > ... there does not appear to be any [straightforward] answer with respect > to internal BGP sessions, given the requirement that BGP speakers internal > to an AS must have a globally consistent RIB and FIB, otherwise packet > forwarding loops will result. And, in my personal operational experience > it's _rarely_ the case that malformed UPDATE's are detected at the first > ASBR (attached to an eBGP neighbor) in my AS, thus it concerns me that > mechanisms such as draft-ietf-idr-error-handling-02 are an adequate > solution to the problems we experience. IOW, as an operator I desire > "defense in depth" where a heterogeneous mix of vendor equipment (HW + SW), > participating as interior BGP speakers, have mechanisms to detect *and* > automatically recover from malformed UDPATE's received over iBGP sessions. > This is another area that I would point research colleagues toward. > > So, this raises the classic conundrum of: increasing complexity, > increasing RIB (and FIB) size information coupled with a contrasting need > from operators who are concerned about the robustness of the protocol and > the requirement to NOT sustain any failures[1]. Something's got to give. > > Ultimately, this makes me question whether it's no longer _just_ growth of > RIB (and, FIB) size that this RG should be (primarily?) focused on. > Rather, will the requirements for: > a) operational robustness, in the face of critical messaging errors in an > Inter-Domain Routing Protocol, which the IETF may be unable to address on > its own; > b) designing security as a first-class principle of an Inter-Domain > Routing Protocol -- either carried within or outside of control-plane > reachability information > c) increased scalability of RIB (and, other?) information > ... lead us down a path of considering we may be approaching the > end-of-the-road for BGPv4 and we need something new? > > Does anyone on this list share similar concerns wrt operational > robustness, time to recovery and (then) scalability of BGPv4? > > -shane > > [1] It is not cool to suggest that operators should just stop asking for > new features and we wouldn't have this problem. :) > > > ------------------------------ > > Message: 2 > Date: Sun, 11 Nov 2012 11:22:17 +0100 > From: Eliot Lear > To: Tony Li > Cc: rrg@irtf.org, Noel Chiappa > Subject: Re: [rrg] RRG to hibernation > Message-ID: <509F7C59.7080900@cisco.com> > Content-Type: text/plain; charset=UTF-8 > > Tony, > > First, thanks for taking on and navigating work within the RRG for as > long as you have done. I think people forget that this group has > induced a tremendous amount of stress and turbulence over time, and that > you were often the target of that stress. > > This having been said, I think this group like any other group ? based > on contributions and participation. If there are no contributions and > if there is no participation, no work can continue. On the other hand, > when there are contributions or participation, we shouldn't be hasty in > closing the effort. Therefore, I would suggest a solicitation for new > topics with the threat of closure, before actually closing ? or going > dormant. > > Eliot > > > ------------------------------ > > Message: 3 > Date: Sun, 11 Nov 2012 09:45:33 -0800 > From: Tony Li > To: Eliot Lear > Cc: rrg@irtf.org, Noel Chiappa > Subject: Re: [rrg] RRG to hibernation > Message-ID: > Content-Type: text/plain; charset=windows-1252 > > > On Nov 11, 2012, at 2:22 AM, Eliot Lear wrote: > > > This having been said, I think this group like any other group ? based > > on contributions and participation. If there are no contributions and > > if there is no participation, no work can continue. On the other hand, > > when there are contributions or participation, we shouldn't be hasty in > > closing the effort. Therefore, I would suggest a solicitation for new > > topics with the threat of closure, before actually closing ? or going > > dormant. > > > Eliot, > > Thanks, but as you may recall, we did do a solicitation of new topics some > time ago. It didn't provoke anything substantive and there has been no > additional input. > > Further, the transition to hibernation is easily reversed if and when a > new substantive topic presents itself. > > Tony > > > > ------------------------------ > > Message: 4 > Date: Sun, 11 Nov 2012 14:52:57 -0500 (EST) > From: heinerhummel@aol.com > To: swb@internet2.edu, jnc@mercury.lcs.mit.edu > Cc: rrg@irtf.org > Subject: Re: [rrg] RRG to hibernation > Message-ID: <8CF8E5D4815A51E-914-3A6E4@webmail-m019.sysops.aol.com> > Content-Type: text/plain; charset="utf-8" > > > I an not pleased ether. > One group goes ahead with LISP-DDT, which is doomed to fail ! With drums > and trumpets! As sure as the Amen in church ! With no rescuing trick in > sight! > The other group believes in IPv6. I admit, I don't know what is special > about IPv6. All I know is that the inventors came up with a crazy address > space and I do remember voices from many many years ago which proclaimed > the advent of the internet for our galaxy.I am sure, IPv6 would only create > additional scalability problems. Imagine a future where we have only IPv6. > Hereby imagine New York at New Year's Eve and several hundred thousand > people operating as mobile sender's of IPv6-multicast instances with > multicast receivers far away (which may as well be mobile) ! We wouldn't > not only have a scalability problem wrt forwarding but as well with respect > to identifying the individual entities. How many IPv6-addresses are needed > to identify one single mobile multicast instance? 1? 2? 3? How should it be > retrieved by software? > > > Loc/id-split: > Obviously what is a locator and whether there are several components > thereof or not hasn't been understood. > A unicast locator MUST BE location-indicating! A multicast -locator CANNOT > but this doesn't mean that there can't be any. > > > Topology-aware BGP: > Distance Vector versus Dijsktra. > DV will never tell you about the upstream network (see also Shane Amante's > email). This is a disaster if you want to manage traffic load (balance/ > dissolve congestion) :-( > Reachability: We don't need reachability. we only need to know where is > the indicated location !!! Location based routing means no user > reachability dissemination, only location reachability dissemination! > > > Whenever I addressed these issues it was like I had sinned against some > holy paradigm. > > > And we are far away from better routing: > I you only know the ALL-Nodes-Spanning-Tree (and not the > All-Links-Spanning-Tree) then you call it Spanning Tree per se. > If you only know the Unicast-FIB (and not a Multicast-FIB, nor a > Anycast-FIB) then you call it FIB per se. > > > To reach a higher level you must view things from a greater distance and > sometimes leave the old trails behind you. > > > Ich habe fertig > Heiner > > > > > > > > > > > > > > > > > > -----Urspr?ngliche Mitteilung----- > Von: Scott Brim > An: Noel Chiappa > Cc: rrg > Verschickt: Sa, 10 Nov 2012 4:40 am > Betreff: Re: [rrg] RRG to hibernation > > > Well, this will be fun. Yes Noel, you're right, this group didn't produce > any > routing revolutions, and loc/id separation is about problems on the > identity > function side, not routing ... but this group's best accomplishment imho > was to > understand that and spread the knowledge. > > Now I'll go back to doing good things with higher layer identities. Ciao. > > Scott > > jnc@mercury.lcs.mit.edu wrote: > > > From: Tony Li > > > The publication of these RFCs concludes our long standing work item > on > > a revised routing architecture. > > Separation of location and identity is very desirable, but it has basically > nothing to do with routing (other than removing identity functionality from > the names used for routing, making them a bit more tractable). > > We still have the same old kludgy BGP global routing system we always had, > and _nothing_ has been proposed to improve/replace it. > > > The group has ... helped push the boundaries of routing farther > > forward. > > Nonsense. It has produced no routing work at all. > > Noel > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.irtf.org/mail-archive/web/rrg/attachments/20121111/fcb62568/attachment.htm > > > > ------------------------------ > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > > > End of rrg Digest, Vol 44, Issue 4 > ********************************** > --bcaec517ce76f5bf1504ce3fa6e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello all,

Am new to this working group, and I found some of the topics been discus= s are really good. But I will like to know what are the most recent topics = to caught up with.

Regards
MFAYE

On Nov 11, 2012 8:00 PM, <rrg-request@irtf.org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

http= ://www.irtf.org/mailman/listinfo/rrg

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send rrg mailing list submissions to
=A0 =A0 =A0 =A0 rrg@irtf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0 http://www.irtf.org/mailman/listinfo/rrg
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0 rrg-request@irtf.or= g

You can reach the person managing the list at
=A0 =A0 =A0 =A0 rrg-owner@irtf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of rrg digest..."


Today's Topics:

=A0 =A01. Re: RRG to hibernation (Shane Amante)
=A0 =A02. Re: RRG to hibernation (Eliot Lear)
=A0 =A03. Re: RRG to hibernation (Tony Li)
=A0 =A04. Re: RRG to hibernation (h= einerhummel@aol.com)


----------------------------------------------------------------------

Message: 1
Date: Sat, 10 Nov 2012 18:38:57 -0700
From: Shane Amante <shane@castl= epoint.net>
To: rrg@irtf.org
Subject: Re: [rrg] RRG to hibernation
Message-ID: <81767641-8399-466D-A9F2-F2C07D3BBE0C@castlepoint.net> Content-Type: text/plain; charset=3Dus-ascii


On Nov 10, 2012, at 10:35 AM, Danny McPherson <danny@tcb.net> wrote:
> On Nov 10, 2012, at 12:24 PM, Tony Li wrote:
[--snip--]
>> I agree that some security needs to be deployed. =A0I'm not co= nvinced that it needs to be BGPSEC. =A0We've muddled along for many yea= rs and never found the gumption to actually deploy anything. =A0Must not be= important to people. =A0I don't get it, but that's the observable = behavior.
>>
>> In any case, this doesn't seem like a research topic. =A0This = is pretty clearly an engineering issue.
>
> I don't agree. =A0The engineering solution that SIDR is actively w= orking (RPKI-enabled BGPSEC) is pumping out standards track RFCs like there= 's no tomorrow. =A0The USG has stated intentions of "expediting se= cure routing work through the Internet standard process" and "fos= tering adoption through government procurement vehicles".
>
> As an operator this scares the hell out of me, especially considering = what they've designed is largely a system to control "what's r= outed on the Internet and by whom". =A0They can't seem to do anyth= ing in BGP(SEC) without introducing the equivalent of "periodic update= s", and undoing all the goodness of things like update packing complet= ely.
>
> Some serious thinkers working on this problem would be goodness...

Let me add that I share Danny's concerns ...

However, let me try to take a step back and share with everyone a much broa= der set of, potentially, architectural concerns that I'm not sure this = RG considered during the last round.

BGP was originally designed for flooding of reachability information. =A0Bu= t, reachability information is the end-result /after/ the application of _r= outing_policy_, describing "intent", by operators of individual n= etworks based on various contractual agreements they have with parties whom= they directly interconnect. =A0Assuming you agree with this premise, this = presents a paradox from a security PoV. =A0Specifically, if a downstream ne= twork does not have visibility into its upstream network's routing poli= cy is it practical/feasible for the downstream network to understand the _i= ntended_ propagation of reachability information and, ultimately, connectiv= ity? =A0Furthermore, is it feasible to carry such information within the co= ntrol plane itself? =A0Or, should the control plane be relegated to carryin= g [strictly] reachability information in real-time, while offboard systems = carry accompanying routing policy and security information in order to assi= st in making "optimal" Inter-Domain rou
=A0ting/forwarding decisions?

A second concern is also related to the original design of BGP and what it = has organically involved into, today. =A0Specifically, BGP is /also/ now be= ing tasked as a generic "message bus" and service discovery mecha= nism. =A0Not to pick on anyone, in particular, but the following are recent= examples that come to my mind wrt this trend:
http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-0= 1
http://tools.ietf.org/html/draft-ietf-idr-operational-m= essage-00
... and, there may be others. =A0Although, contrast those proposals with wh= at should be most concerning to people in this RG, and in the IETF:
http://tools.ietf.org/html/draft-ietf-grow= -ops-reqs-for-bgp-error-handling-05
In short, operators (such as myself) are _extremely_ concerned that a singl= e erroneous update results in a complete reset of BGP sessions. =A0Due to t= he overwhelming success of BGP, it's now (and, has been for a while) a = mission-critical protocol, thus such catastrophic session resets -- caused = by a single malformed UPDATE -- are widely visible/impactful. =A0This impac= t is compounded by the 'cost to recover'. =A0Namely, due to the lar= ge and growing amount of information in the RIB (again, not just reachabili= ty, but also service-discovery and completely orthogonal information), it t= akes longer to exchange RIB information and, ultimately, restore services. = =A0Is this really the best we, as an industry, can do?

While the IETF IDR WG has been looking at mechanisms for how BGP may defend= against certain types of erroneous BGP UPDATE's for external BGP sessi= ons:
http://tools.ietf.org/html/draft-ietf-idr-error-handling-02<= /a>
... there does not appear to be any [straightforward] answer with respect t= o internal BGP sessions, given the requirement that BGP speakers internal t= o an AS must have a globally consistent RIB and FIB, otherwise packet forwa= rding loops will result. =A0And, in my personal operational experience it&#= 39;s _rarely_ the case that malformed UPDATE's are detected at the firs= t ASBR (attached to an eBGP neighbor) in my AS, thus it concerns me that me= chanisms such as draft-ietf-idr-error-handling-02 are an adequate solution = to the problems we experience. =A0IOW, as an operator I desire "defens= e in depth" where a heterogeneous mix of vendor equipment (HW + SW), p= articipating as interior BGP speakers, have mechanisms to detect *and* auto= matically recover from malformed UDPATE's received over iBGP sessions. = =A0This is another area that I would point research colleagues toward.

So, this raises the classic conundrum of: increasing complexity, increasing= RIB (and FIB) size information coupled with a contrasting need from operat= ors who are concerned about the robustness of the protocol and the requirem= ent to NOT sustain any failures[1]. =A0Something's got to give.

Ultimately, this makes me question whether it's no longer _just_ growth= of RIB (and, FIB) size that this RG should be (primarily?) focused on. =A0= Rather, will the requirements for:
a) operational robustness, in the face of critical messaging errors in an I= nter-Domain Routing Protocol, which the IETF may be unable to address on it= s own;
b) designing security as a first-class principle of an Inter-Domain Routing= Protocol -- either carried within or outside of control-plane reachability= information
c) increased scalability of RIB (and, other?) information
... lead us down a path of considering we may be approaching the end-of-the= -road for BGPv4 and we need something new?

Does anyone on this list share similar concerns wrt operational robustness,= time to recovery and (then) scalability of BGPv4?

-shane

[1] It is not cool to suggest that operators should just stop asking for ne= w features and we wouldn't have this problem. =A0:)


------------------------------

Message: 2
Date: Sun, 11 Nov 2012 11:22:17 +0100
From: Eliot Lear <lear@cisco.com&g= t;
To: Tony Li <tony.li@tony.li><= br> Cc: rrg@irtf.org, Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: Re: [rrg] RRG to hibernation
Message-ID: <509F7C59.7080= 900@cisco.com>
Content-Type: text/plain; charset=3DUTF-8

Tony,

First, thanks for taking on and navigating work within the RRG for as
long as you have done. =A0I think people forget that this group has
induced a tremendous amount of stress and turbulence over time, and that you were often the target of that stress.

This having been said, I think this group like any other group ? based
on contributions and participation. =A0If there are no contributions and if there is no participation, no work can continue. =A0On the other hand, when there are contributions or participation, we shouldn't be hasty in=
closing the effort. =A0Therefore, I would suggest a solicitation for new topics with the threat of closure, before actually closing ? or going
dormant.

Eliot


------------------------------

Message: 3
Date: Sun, 11 Nov 2012 09:45:33 -0800
From: Tony Li <tony.li@tony.li>= ;
To: Eliot Lear <lear@cisco.com>=
Cc: rrg@irtf.org, Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: Re: [rrg] RRG to hibernation
Message-ID: <DF11188A-3D05-4D75-8C07-7ED42B146E7E@tony.li>
Content-Type: text/plain; charset=3Dwindows-1252


On Nov 11, 2012, at 2:22 AM, Eliot Lear <lear@cisco.com> wrote:

> This having been said, I think this group like any other group ? based=
> on contributions and participation. =A0If there are no contributions a= nd
> if there is no participation, no work can continue. =A0On the other ha= nd,
> when there are contributions or participation, we shouldn't be has= ty in
> closing the effort. =A0Therefore, I would suggest a solicitation for n= ew
> topics with the threat of closure, before actually closing ? or going<= br> > dormant.


Eliot,

Thanks, but as you may recall, we did do a solicitation of new topics some = time ago. =A0It didn't provoke anything substantive and there has been = no additional input.

Further, the transition to hibernation is easily reversed if and when a new= substantive topic presents itself.

Tony



------------------------------

Message: 4
Date: Sun, 11 Nov 2012 14:52:57 -0500 (EST)
From: heinerhummel@aol.com
To: swb@internet2.edu, jnc@mercury.lcs.mit.edu
Cc: rrg@irtf.org
Subject: Re: [rrg] RRG to hibernation
Message-ID: <8CF8E5D4815A51E-914-3A6E4@webmail-m019.sysops.aol.com>=
Content-Type: text/plain; charset=3D"utf-8"


I an not pleased ether.
One group goes ahead with LISP-DDT, which is doomed to fail ! With drums an= d trumpets! As sure as the Amen in church ! With no rescuing trick in sight= !
The other group believes in IPv6. I admit, I don't know what is special= about IPv6. All I know is that the inventors came up with a crazy address = space and I do remember voices from many many years ago which proclaimed th= e advent of the internet for our galaxy.I am sure, IPv6 would only create a= dditional scalability problems. Imagine a future where we have only IPv6. H= ereby imagine New York at New Year's Eve and several hundred thousand p= eople operating as mobile sender's of =A0IPv6-multicast instances with = multicast receivers far away (which may as well be mobile) ! =A0We wouldn&#= 39;t not only have a scalability problem wrt forwarding but as well with re= spect to identifying the individual entities. How many IPv6-addresses are n= eeded to identify one single mobile multicast instance? 1? 2? 3? How should= it be retrieved by software?


Loc/id-split:
Obviously what is a locator and whether there are several components thereo= f or not hasn't been understood.
A unicast locator MUST BE location-indicating! A multicast -locator CANNOT = but this doesn't mean that there can't be any.


Topology-aware BGP:
Distance Vector versus Dijsktra.
DV will never tell you about the upstream network (see also Shane Amante= 9;s email). This is a disaster if you want to manage traffic load (balance/= dissolve congestion) :-(
Reachability: We don't need reachability. we only need to know where is= the indicated location !!! =A0Location based routing means no user reachab= ility dissemination, =A0only location reachability dissemination!


Whenever I addressed these issues it was like I had sinned against some hol= y paradigm.


And we are far away from better routing:
I you only know the ALL-Nodes-Spanning-Tree (and not the All-Links-Spanning= -Tree) then you call it Spanning Tree per se.
If you only know the Unicast-FIB (and not a Multicast-FIB, nor a Anycast-FI= B) =A0then you call it FIB per se.


To reach a higher level you must view things from a greater distance and so= metimes leave the old trails behind you.


Ich habe fertig
Heiner

















-----Urspr?ngliche Mitteilung-----
Von: Scott Brim <swb@internet2.edu<= /a>>
An: Noel Chiappa <jnc@mercury= .lcs.mit.edu>
Cc: rrg <rrg@irtf.org>
Verschickt: Sa, 10 Nov 2012 4:40 am
Betreff: Re: [rrg] RRG to hibernation


Well, this will be fun. Yes Noel, you're right, this group didn't p= roduce any
routing revolutions, and loc/id separation is about problems on the identit= y
function side, not routing ... but this group's best accomplishment imh= o was to
understand that and spread the knowledge.

Now I'll go back to doing good things with higher layer identities. =A0= Ciao.

Scott

jnc@mercury.lcs.mit.edu wrot= e:

=A0 =A0 > From: Tony Li <tony.li@t= ony.li>

=A0 =A0 > The publication of these RFCs concludes our long standing work= item on
=A0 =A0 > a revised routing architecture.

Separation of location and identity is very desirable, but it has basically=
nothing to do with routing (other than removing identity functionality from=
the names used for routing, making them a bit more tractable).

We still have the same old kludgy BGP global routing system we always had,<= br> and _nothing_ has been proposed to improve/replace it.

=A0 =A0 > The group has ... helped push the boundaries of routing farthe= r
=A0 =A0 > forward.

Nonsense. It has produced no routing work at all.

=A0 =A0 =A0 =A0 Noel
_______________________________________________
rrg mailing list
rrg@irtf.org
http= ://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
rrg@irtf.org
http= ://www.irtf.org/mailman/listinfo/rrg




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.irtf.org/mail-= archive/web/rrg/attachments/20121111/fcb62568/attachment.htm>

------------------------------

_______________________________________________
rrg mailing list
rrg@irtf.org
http= ://www.irtf.org/mailman/listinfo/rrg


End of rrg Digest, Vol 44, Issue 4
**********************************
--bcaec517ce76f5bf1504ce3fa6e8-- From surfer@mauigateway.com Sun Nov 11 15:03:55 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454A521F848D for ; Sun, 11 Nov 2012 15:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSfwCEE4EMqT for ; Sun, 11 Nov 2012 15:03:54 -0800 (PST) Received: from imta-38.everyone.net (imta-38.everyone.net [216.200.145.38]) by ietfa.amsl.com (Postfix) with ESMTP id C46B421F8476 for ; Sun, 11 Nov 2012 15:03:54 -0800 (PST) Received: from pps.filterd (omta003 [127.0.0.1]) by imta-38.everyone.net (8.14.4/8.14.4) with SMTP id qABN3swL015080 for ; Sun, 11 Nov 2012 15:03:54 -0800 X-Eon-Dm: dm0103 Received: by resin13.mta.everyone.net (EON-PICKUP) id resin13.50876290.2a4ca; Sun, 11 Nov 2012 15:03:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Message-Id: <20121111150354.90DE67C1@resin13.mta.everyone.net> Date: Sun, 11 Nov 2012 15:03:54 -0800 From: "Scott Weeks" To: X-Eon-Sig: AQLAznNQoC7azN1AqAEAAAAB,e47919903b2d43e8fe066ef979a128cc X-Originating-Ip: 199.211.157.2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-11_06:2012-11-10, 2012-11-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=39 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1211110286 Subject: Re: [rrg] rrg Digest, Vol 44, Issue 4 X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: surfer@mauigateway.com List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 23:03:55 -0000 --- mahafaye@gmail.com wrote: From: Mohamed Faye Am new to this working group, and I found some of the topics been discuss are really good. But I will like to know what are the most recent topics to caught up with. -------------------------------------------------------------- http://www.ietf.org/mail-archive/web/rrg/current/maillist.html scott From danny@tcb.net Sun Nov 11 15:45:05 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D419521F8518 for ; Sun, 11 Nov 2012 15:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpoXs9OUVm0f for ; Sun, 11 Nov 2012 15:45:02 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 4219A21F8502 for ; Sun, 11 Nov 2012 15:45:02 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id BC8C320DF for ; Sun, 11 Nov 2012 23:45:01 +0000 (UTC) Received: from dul1dmcphers-m2.home (pool-71-171-124-149.clppva.fios.verizon.net [71.171.124.149]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 7C33E20DC; Sun, 11 Nov 2012 16:45:00 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Danny McPherson In-Reply-To: <7CBB1514-5A26-4B12-BAA3-BF2AA3CC80F4@tony.li> Date: Sun, 11 Nov 2012 18:45:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <878C9E8D-D2B8-43CF-B338-15A341C399B0@tcb.net> References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> <7CBB1514-5A26-4B12-BAA3-BF2AA3CC80F4@tony.li> To: Tony Li X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Nov 11 16:45:01 2012 X-DSPAM-Confidence: 0.9898 X-DSPAM-Improbability: 1 in 9709 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50a0387d199632084684145 X-DSPAM-Factors: 27, Subject*Re+#+#+#+hibernation, 0.01000, Subject*to+hibernation, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Subject*Re+rrg, 0.01000, Subject*Re+#+RRG, 0.01000, Subject*Re+#+#+to, 0.01000, PM+#+#+wrote, 0.01000, Subject*rrg+#+#+hibernation, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*rrg+#+to, 0.01000, Subject*RRG+to, 0.01000, Subject*RRG+#+hibernation, 0.01000, Subject*rrg+RRG, 0.01000, Nov+#+#+at, 0.01000, On+Nov, 0.01000, Nov+#+2012, 0.01000, On+#+#+#+at, 0.01000, On+#+#+2012, 0.01000, an+engineering, 0.40000, the+#+forum, 0.40000, alternative+#+protocols, 0.40000, architectures+#+#+#+encouraged, 0.40000, and+#+#+#+the, 0.40000, out+#+#+#+necessary, 0.40000, As+#+#+benefit, 0.40000, autonomous+#+#+in, 0.40000 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 23:45:06 -0000 On Nov 10, 2012, at 12:54 PM, Tony Li wrote: >=20 >=20 > I agree, but as you correctly point out, SIDR is an engineering = solution. If you dislike that particular solution, you're of course = free to propose others. However, the correct forum for engineering = solutions is the IETF. =20 I was hoping for some research and fresh thinking related to = rate+state+autonomous operations &security in inter-domain routing, = hence my message here. I don't have a solution envisaged, I just know = what I'm seeing in current work is err.., going to present some = challenges. I was hoping for "architectural alternatives, research and = experimentation in secure routing architectures and algorithms being = encouraged, with an aim to understand whether new directions can provide = effective solutions, to work out candidate designs as necessary for a = complete solution, and to fully understand both the gains and the = tradeoffs that the new solutions may bring." (some of that text may = sound familiar :-) As a side benefit, whether the routed protocol changes or not, using = security as the fulcrum may well help foster broader consideration of = alternative routed protocols... Else -- some work into scalable *static* inter-domain routing techniques = and solutions might be a worthwhile endeavor *8^/ If that's not within RRG scope then I suppose I understand how we = arrived where we currently are... -danny From dykim6@gmail.com Sun Nov 11 16:50:10 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D89421F84A0 for ; Sun, 11 Nov 2012 16:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANYeApSb3sAZ for ; Sun, 11 Nov 2012 16:50:09 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2127E21F8460 for ; Sun, 11 Nov 2012 16:50:09 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id c10so1469615qae.13 for ; Sun, 11 Nov 2012 16:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=4D9KWoTWTky/uFlaWBK5DwK98hUg6yftvHjpK1w5YmY=; b=W5NsRinuEnoCjGYOyTM4EkYRiEQBTKPJgzUAn1pXprdm5cNmyK/e42B8rxXqV++LG9 J+R1AUacZfFMJ3ho9WqKiF/pHT/aShZsPe50lVjHzciW9B4VcytWTY87X7SMCooKhdnQ NLWVmGfy/mq5b86jDd68Vl591rQrTnZn2VHkogaq0oI3LNU92GWiiadK+F4LKXCLosg5 z6ND0cvTY48PVpbHl7XoQ9yjkiPoJEA/tw9rqYhreDCBTbaXQW4zL7rMi8WTNFvsFnsZ 6V83ye0CEeQpujiBo12A6LanW7UuIvdz/foz2+PtPVGBayZyE5mb9zzULJqPwY/nsUC7 xwnQ== Received: by 10.49.3.234 with SMTP id f10mr24533729qef.45.1352681408559; Sun, 11 Nov 2012 16:50:08 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Sun, 11 Nov 2012 16:49:48 -0800 (PST) In-Reply-To: <20121110032942.BD27018C113@mercury.lcs.mit.edu> References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> From: Dae Young KIM Date: Mon, 12 Nov 2012 09:49:48 +0900 X-Google-Sender-Auth: tIxtju64ydi3ZDRomL1dnHLPpbQ Message-ID: To: Noel Chiappa Content-Type: multipart/mixed; boundary=047d7bb03e68d9fc0504ce41aeec Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 00:50:10 -0000 --047d7bb03e68d9fc0504ce41aeec Content-Type: multipart/alternative; boundary=047d7bb03e68d9fc0204ce41aeea --047d7bb03e68d9fc0204ce41aeea Content-Type: text/plain; charset=ISO-8859-1 Dear Noel, As I know, the original rationale for RRG was to find a solution to mitigate the DFZ routing table explosion. LIS like ILNP was then proposed as a solution mechanism. One might argue that LIS does not help reduce the DFZ routing table size; please find the attachment. If there's any point in the argument, then we've not accomplished our original task wrt DFZ routing table explosion, echoing your point. On Sat, Nov 10, 2012 at 12:29 PM, Noel Chiappa wrote: > > From: Tony Li > > > The publication of these RFCs concludes our long standing work item > on > > a revised routing architecture. > > Separation of location and identity is very desirable, but it has basically > nothing to do with routing (other than removing identity functionality from > the names used for routing, making them a bit more tractable). > > We still have the same old kludgy BGP global routing system we always had, > and _nothing_ has been proposed to improve/replace it. > > > The group has ... helped push the boundaries of routing farther > > forward. > > Nonsense. It has produced no routing work at all. > > Noel > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > -- DY --047d7bb03e68d9fc0204ce41aeea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Noel,

As I know, the original rationale for RRG was to find a s= olution to mitigate the DFZ routing table explosion. LIS like ILNP was then= proposed as a solution mechanism.

One might argue that LIS does not= help reduce the DFZ routing table size; please find the attachment. If the= re's any point in the argument, then we've not accomplished our ori= ginal task wrt DFZ routing table explosion, echoing your point.

On Sat, Nov 10, 2012 at 12:29 PM, Noel Chiap= pa <jnc@mercury.lcs.mit.edu> wrote:
=A0 =A0 > From: Tony Li <tony.li@t= ony.li>

=A0 =A0 > The publication of these RFCs concludes our long standing work= item on
=A0 =A0 > a revised routing architecture.

Separation of location and identity is very desirable, but it has bas= ically
nothing to do with routing (other than removing identity functionality from=
the names used for routing, making them a bit more tractable).

We still have the same old kludgy BGP global routing system we always had,<= br> and _nothing_ has been proposed to improve/replace it.

=A0 =A0 > The group has ... helped push the boundaries of routing farthe= r
=A0 =A0 > forward.

Nonsense. It has produced no routing work at all.

=A0 =A0 =A0 =A0 Noel
_____________________= __________________________
rrg mailing list
rrg@irtf.org
http= ://www.irtf.org/mailman/listinfo/rrg



--
DY
--047d7bb03e68d9fc0204ce41aeea-- --047d7bb03e68d9fc0504ce41aeec Content-Type: text/plain; charset=US-ASCII; name="anti-LIS.txt" Content-Disposition: attachment; filename="anti-LIS.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9evdrl40 TGV0IHVzIHN1bW1hcml6ZSB0aGUgYXJndW1lbnQgZm9yIExJUzoKCiBvIFN5bXB0b206IFRoZSBE Rlogcm91dGluZyB0YWJsZSBpcyBleHBsb2RpbmcuCiBvIFByaW1hcnkgRGlhZ25vc2lzOiBJbmNv bXBldGVuY2UgaW4gbXVsdGlob21pbmcgaXMgdGhlIGNhdXNlLgogbyBTZWNvbmRhcnkgRGlhZ25v c2lzOiBTZW1hbnRpYyBvdmVybG9hZGluZyBvZiBJUCBhZGRyZXNzIGlzIHJlc3BvbnNpYmxlIGZv ciBtdWx0aWhvbWluZyBpbmNvbXBldGVuY2UuCiBvIFByZXNjcmlwdGlvbjogQXBwbHkgTElTLgoK V2UgYXJndWUgdGhhdCBMSVMgaXMgYSB3cm9uZyBwcmVzY3JpcHRpb24gdG8gdGhlIHByb2JsZW0g b2YgdGhlIERGWiByb3V0aW5nIHRhYmxlIGV4cGxvc2lvbi4KCkxldCB1cyBhc2sgb3Vyc2VsdmVz IHRoZSBmb2xsb3dpbmcgcXVlc3Rpb246CgogbyBEb2VzIExJUyBpbXByb3ZlIG11bHRpaG9taW5n PwoKT3VyIGZvY3VzIHdvdWxkIGJlIG9uIHRoZSBsb2NhdG9ycywgYW4gb3V0Y29tZSBvZiBMSVMu IFRoZSBERlogcm91dGluZyB0YWJsZSBleHBsb3Npb24gd2lsbCBub3QgZ28gYXdheSB1bmxlc3Mg bG9jYXRvcnMgYXJlIGFnZ3JlZ2F0YWJsZS4gVG8gYmUgYWdncmVnYXRhYmxlLCB0aGUgbG9jYXRv cnMgaGF2ZSB0byBiZSBwcm92aWRlci1hZ2dyZWdhdGFibGUoUEEpLiBXaXRoIG11bHRpcGxlIElu dGVybmV0IHNlcnZpY2UgcHJvdmlkZXJzKElTUHMpIHNlcnZpbmcgeW91ciBzaXRlIGluIG11bHRp aG9taW5nLCB3aGljaCBQQSBsb2NhdG9yIHNldHMgc2hvdWxkIHlvdSBsb2FkIHlvdXIgY2xpZW50 IG5vZGVzLCBhbGwgb2YgdGhlbSBvciBlaXRoZXIgb2YgdGhlbT8gWW91ciBwcmVmZXJlbmNlIHdv dWxkIGJlIHRvIHVzZSBwcm92aWRlci1pbmRlcGVuZGVudChQSSkgbG9jYXRvcnMgYW5kIGJlIGZy ZWUgb2YgdGhlIG1hbmFnZXJpYWwgaGVhZGFjaGUgd2l0aCBtdWx0aXBsZSBQQSBjaG9pY2VzLiBU aGlzIGlzIHRoZSBzYW1lIHNpdHVhdGlvbiB3aXRoIElQIGFkZHJlc3Nlczsgbm8gY2hhbmdlIGFu ZCBzbyBubyBpbXByb3ZlbWVudC4KCkhvdyBhYm91dCBJU1AgbWlncmF0aW9uIHdoaWNoIGlzIGEg ZGVnZW5lcmF0ZSBjYXNlIG9mIG11bHRpaG9taW5nPyBZb3UgaGF2ZSB0byByZW51bWJlciB5b3Vy IGxvY2F0b3JzIHdoZW5ldmVyIHlvdSdyZSB0byBtaWdyYXRlIHRvIGEgZGlmZmVyZW50IElTUC4g UmVudW1iZXJpbmcgaXMgc28gcGFpbmZ1bCB0aGF0IG5vIG5ldHdvcmsgbWFuYWdlcnMgd291bGQg bGlrZSB0byBkby4gWW91ciBwcmVmZXJlbmNlIGFnYWluIHdvdWxkIGJlIHRvIHVzZSBQSSBsb2Nh dG9ycyB0byBhdm9pZCByZW51bWJlcmluZzsgdGhlIHNhbWUgc2l0dWF0aW9uIHdpdGggSVAgYWRk cmVzc2VzIGFuZCBzbyBubyBpbXByb3ZlbWVudC4KClRoYXQgaXMsIHN3aXRjaGluZyB0byBsb2Nh dG9ycyBkb2VzIG5vdCBpbXByb3ZlIHlvdXIgY29tcGV0ZW5jZSBpbiBtdWx0aWhvbWluZywgaGVu Y2UgZG9lcyBub3QgY29udHJpYnV0ZSB0byBtaXRpZ2F0aW9uIG9mIHRoZSBERlogcm91dGluZyB0 YWJsZSBleHBsb3Npb24uIExJUyBpcyBhIHdyb25nIHByZXNjcmlwdGlvbi4KCklmIExJUyBpcyBu b3QgdGhlIHJpZ2h0IHNvbHV0aW9uLCBpdCBmb2xsb3dzIHRoYXQgYmxhbWluZyB0aGUgY29udGV4 dHVhbCBvdmVybG9hZGluZyBvZiBJUCBhZGRyZXNzIGlzIGlsbCBncm91bmRlZC4gQ29udGV4dHVh bCBvdmVybG9hZGluZyBvZiBJUCBhZGRyZXNzIGlzIG5vdCByZXNwb25zaWJsZSBmb3IgREZaIHJv dXRpbmcgdGFibGUgZXhwbG9zaW9uLg== --047d7bb03e68d9fc0504ce41aeec-- From jnc@mercury.lcs.mit.edu Sun Nov 11 17:55:56 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA0221F84DF for ; Sun, 11 Nov 2012 17:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6lnBeKlV6-n for ; Sun, 11 Nov 2012 17:55:56 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 018E521F84D8 for ; Sun, 11 Nov 2012 17:55:55 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DC3BA18C0C7; Sun, 11 Nov 2012 20:55:52 -0500 (EST) To: rrg@irtf.org Message-Id: <20121112015552.DC3BA18C0C7@mercury.lcs.mit.edu> Date: Sun, 11 Nov 2012 20:55:52 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 01:55:56 -0000 > From: William Herrin > I have a notion for a "routing" protocol I'm glad you put the 'routing' in quotations, because to me, 'routing' is i) the _selection of paths_, and ii) the distribution of the information needed to select paths. I'm not sure what definition other people are using, but it might be useful to come up with a standard one to prevent confusion. > which manages link changes through dynamic re-addressing and multiply > addressing hosts. By and large the addresses change so that the > trivially aggregable routes don't have to. Not just at the host level > but all the way downstream from the link change. If I understand you properly, this is a way of dealing with topology changes by re-numbering things? (To use the definition of 'routing' above, you wouldn't need to propogate new information, because the old data would still be valid - it's just that the things the old information would apply to have changed?) I need to go away and think about this for a while before I can have some really solid reaction, but off the top of my head I wonder if the work involved in keeping up with the changing addresses isn't as much (or possibly more) work than the usual approach. TANSTAAFL, after all... > Even bumps automatic resizing requirements upstream so that over time > any given router offers exactly one route outward which automatically > aggregates with the route its upstream already holds. Err, routing (in the sense given at the top) is trivial when there's only one path ("its upstream"). It's finding/selecting paths in arbitrary graphs with lots of alternate paths (i.e. ones with lots of 'cycles', to use the graph-theory term) which is the hard case. > It does require a new suite of transport protocols > ... > the odds of ever reaching deployment on an approach which requires us > to abandon TCP and UDP are not good? That's infeasible; you can't require changing all hosts. You need to see if you can come up with some approach that avoids that. (E.g. if we have location-identity separatation deployed, you could hide the new locators from the hosts.) > Are you game to flesh it out and see how far we can run with it Right at the moment, I personally don't have any spare time/energy. But you should think about it (and try and write something); even if it's not usable directly, there might be some aspects that could be useful to other designs. Noel From huitema@huitema.net Sun Nov 11 18:13:50 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15D321F8425 for ; Sun, 11 Nov 2012 18:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU59y1UwmBuH for ; Sun, 11 Nov 2012 18:13:50 -0800 (PST) Received: from xsmtp02.mail2web.com (xsmtp22.mail2web.com [168.144.250.185]) by ietfa.amsl.com (Postfix) with ESMTP id 3110121F841D for ; Sun, 11 Nov 2012 18:13:50 -0800 (PST) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1TXjX2-0005HY-Hn for rrg@irtf.org; Sun, 11 Nov 2012 21:13:49 -0500 Received: (qmail 27220 invoked from network); 12 Nov 2012 02:13:45 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.18.205.153]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Nov 2012 02:13:45 -0000 From: "Christian Huitema" To: "'Noel Chiappa'" , References: <20121112015552.DC3BA18C0C7@mercury.lcs.mit.edu> In-Reply-To: <20121112015552.DC3BA18C0C7@mercury.lcs.mit.edu> Date: Sun, 11 Nov 2012 18:13:44 -0800 Message-ID: <08d501cdc07b$582cbdd0$08863970$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQFAqZzhNrDcPeiDBggpGtwM+L0T95j/oPLw Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 02:13:51 -0000 > > It does require a new suite of transport protocols > > ... > > the odds of ever reaching deployment on an approach which requires us > > to abandon TCP and UDP are not good? > > That's infeasible; you can't require changing all hosts. You need to see if you can > come up with some approach that avoids that. > > (E.g. if we have location-identity separatation deployed, you could hide the new > locators from the hosts.) I think that we are giving up too early on the feasibility of updating all hosts. Indeed, any substantial change in routing and addressing would most probably end up changing all hosts, or at least most of them. I also think that a research group should not necessarily shy away from investigations that affect all hosts. If research comes out with a brilliant shiny star on the horizon, then engineering might follow. If the best we can do is hack on the edges of current solutions, then engineering groups can definitely do that, no need for a research group. -- Christian Huitema From jnc@mercury.lcs.mit.edu Sun Nov 11 18:18:48 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D712E21F842F for ; Sun, 11 Nov 2012 18:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iOyqhuccK98 for ; Sun, 11 Nov 2012 18:18:48 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id D2CF721F842E for ; Sun, 11 Nov 2012 18:18:47 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4EB0218C0C7; Sun, 11 Nov 2012 21:18:47 -0500 (EST) To: rrg@irtf.org Message-Id: <20121112021847.4EB0218C0C7@mercury.lcs.mit.edu> Date: Sun, 11 Nov 2012 21:18:47 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 02:18:49 -0000 > From: Tony Li >> We still have the same old kludgy BGP global routing system we always >> had, and _nothing_ has been proposed to improve/replace it. > Blatantly not true. There's this thing called NIMROD that has been > proposed to replace it. Perhaps you've heard of it? ;-) In my original message, I meant 'here in the RRG, recently'. And you could probably expand that to 'here in the I*, recently'. I don't think there's been any serious work in routing since Unified and Nimrod, right? > From: Shane Amante > let me try to take a step back and share with everyone a much broader > set of, potentially, architectural concerns > ... > if a downstream network does not have visibility into its upstream > network's routing policy is it practical/feasible for the downstream > network to understand the _intended_ propagation of reachability > information and, ultimately, connectivity? Furthermore, is it feasible > to carry such information within the control plane itself? Or, should > the control plane be relegated to carrying [strictly] reachability > information You ask a series of very interesting questions, ones I don't have an immediate answer to. On the first, I have heard people say that providers don't want to tell anyone anything about the policies, etc. As to the second, there has been some thinking along those lines, although I'm not sure it's all written down. E.g. in the context of Nimrod, I thought about the possibility of separating topology informtion from up/down information. E.g. a node might flood topology information (i.e. long-term, permanent changes), but it would not flood up/down information (i.e. short-term state changes). A distant node would find out that an asset that was listed in the map was actually 'down' when it tried to set up a path through it; the path setup would fail. I.e. that information would be propogated in 'pull' mode, to try and reduce overhead, and have that information only sent to those entities which actually needed it. (There's a lot of complictions, e.g. what happens when an asset fails when there's traffic using it, but I'm going to gloss over them all for the moment.) But I'm not sure that stuff got written down... :-( > {A long series of other very interesing comments, which I don't have > the time to reply to.} This is all very interesting stuff. Is there any chance you could expand this into a short note (an RFC might be too much work, but perhaps there's some other way to distribute it). This sort of information, from the operational commmunity, is very valuable to system architects. I personally am going to re-read this message several times to make sure I have really absorbed everything in it. > Does anyone on this list share similar concerns wrt operational > robustness, time to recovery and (then) scalability of BGPv4? Absolutely. And I also have 'tussle' issues; which is to say, right now, the users have little insight, and basically zero control (other than having multiple providers, and picking the outbound provider) over paths. I'd like to see the users have more insight and control, but the providers probably wouldn't like that (hence the 'tussle' reference). Noel From jmh@joelhalpern.com Sun Nov 11 18:48:35 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A267B21F841E for ; Sun, 11 Nov 2012 18:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9ElGYZxU1aY for ; Sun, 11 Nov 2012 18:48:34 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3978C21F8425 for ; Sun, 11 Nov 2012 18:48:34 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 981C1A68FB for ; Sun, 11 Nov 2012 18:48:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 501A61C02F3B; Sun, 11 Nov 2012 18:48:30 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-236.clppva.btas.verizon.net [71.161.52.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B60331C02F3A; Sun, 11 Nov 2012 18:48:29 -0800 (PST) Message-ID: <50A06376.5040002@joelhalpern.com> Date: Sun, 11 Nov 2012 21:48:22 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Christian Huitema References: <20121112015552.DC3BA18C0C7@mercury.lcs.mit.edu> <08d501cdc07b$582cbdd0$08863970$@huitema.net> In-Reply-To: <08d501cdc07b$582cbdd0$08863970$@huitema.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 02:48:35 -0000 I can well believe we can, for a reasonable value of all, update all host TCP and UDP engines with a small, migratable, change. We can't change all host applications. And we can not make a change that does not interoperate with existing hosts. Yours, Joel On 11/11/2012 9:13 PM, Christian Huitema wrote: >> > It does require a new suite of transport protocols >> > ... >> > the odds of ever reaching deployment on an approach which requires > us >> > to abandon TCP and UDP are not good? >> >> That's infeasible; you can't require changing all hosts. You need to see > if you can >> come up with some approach that avoids that. >> >> (E.g. if we have location-identity separatation deployed, you could hide > the new >> locators from the hosts.) > > I think that we are giving up too early on the feasibility of updating all > hosts. Indeed, any substantial change in routing and addressing would most > probably end up changing all hosts, or at least most of them. I also think > that a research group should not necessarily shy away from investigations > that affect all hosts. If research comes out with a brilliant shiny star on > the horizon, then engineering might follow. If the best we can do is hack on > the edges of current solutions, then engineering groups can definitely do > that, no need for a research group. > > -- Christian Huitema > > > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From pfrejborg@gmail.com Mon Nov 12 00:26:40 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCFF21F84BA for ; Mon, 12 Nov 2012 00:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZfk364S80Su for ; Mon, 12 Nov 2012 00:26:39 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9C44D21F84BB for ; Mon, 12 Nov 2012 00:26:36 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id bi1so4331454pad.13 for ; Mon, 12 Nov 2012 00:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QuCVe8VO06iZXR46jwyykT1LrNbr3pFKYe5jcaaiOYw=; b=lNOR+Y7T5fR9M1PCSvxqxyRl8TYEIs+nu6llay86kuExvNbT4PG08ySlDKZu437EIh 6BbN8HQl7WBMjawZV49/AoowWveWL2kX7ve5K/OHQUoSl17MiMsfahaWrIfrgRa/U8Cx kHQO1HT/Ax6G80SbcgRi0pomNOT2gTdz8tKbxAVjEI7Lo2XeurbkCvpxTxIfDMHtybR4 ek8eJACWRwTXqDfvEX7Yc3t9NGsI2e2rjxd1hWtVZPZI4ENyUC8HH3PwrCPBVnVZo8cf wBL9zLMCd2xJMTaS781rC2q8tvQ4f96sZo1aEI2k+mic6i24OcSHcfhaBWIg6NdK3URq QYUg== MIME-Version: 1.0 Received: by 10.68.213.6 with SMTP id no6mr49031135pbc.113.1352708796243; Mon, 12 Nov 2012 00:26:36 -0800 (PST) Received: by 10.66.218.37 with HTTP; Mon, 12 Nov 2012 00:26:36 -0800 (PST) In-Reply-To: <878C9E8D-D2B8-43CF-B338-15A341C399B0@tcb.net> References: <20121110032942.BD27018C113@mercury.lcs.mit.edu> <4C845B01-B282-46FB-A4B8-7ADDBCC9C6E5@tcb.net> <7CBB1514-5A26-4B12-BAA3-BF2AA3CC80F4@tony.li> <878C9E8D-D2B8-43CF-B338-15A341C399B0@tcb.net> Date: Mon, 12 Nov 2012 10:26:36 +0200 Message-ID: From: Patrick Frejborg To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 08:26:40 -0000 On Mon, Nov 12, 2012 at 1:45 AM, Danny McPherson wrote: > > On Nov 10, 2012, at 12:54 PM, Tony Li wrote: > >> >> >> I agree, but as you correctly point out, SIDR is an engineering solution= . If you dislike that particular solution, you're of course free to propos= e others. However, the correct forum for engineering solutions is the IETF. > > I was hoping for some research and fresh thinking related to rate+state+a= utonomous operations &security in inter-domain routing, hence my message he= re. I don't have a solution envisaged, I just know what I'm seeing in curr= ent work is err.., going to present some challenges. > > I was hoping for "architectural alternatives, research and experimentatio= n in secure routing architectures and algorithms being encouraged, with an = aim to understand whether new directions can provide effective solutions, t= o work out candidate designs as necessary for a complete solution, and to f= ully understand both the gains and the tradeoffs that the new solutions may= bring." (some of that text may sound familiar :-) > > As a side benefit, whether the routed protocol changes or not, using secu= rity as the fulcrum may well help foster broader consideration of alternati= ve routed protocols... > > Else -- some work into scalable *static* inter-domain routing techniques = and solutions might be a worthwhile endeavor *8^/ > > If that's not within RRG scope then I suppose I understand how we arrived= where we currently are... > > -danny > Hi Danny, if some of the RRG proposals (LISP, ILNP, IRON, hIPV4) gets globally implemented then the endpoint locators (EID, ELOC etc) will not show up in the DFZ and the global routing table should be more static than today. However, none of the RRG proposals have a proper solution for inter-domain traffic engineering, thus I think your concerns are right on spot. It would be interesting to take the IRS approach (as an interface to the FIB) and design from scratch an inter-domain traffic engineering architecture, where the ISPs can create explicit paths for certain traffic flows/bundles between domains without inserting more granular prefixes in the RIB of DFZ. This new inter-domain architecture would be designed as an additional control plane in parallel with the current control plane of the existing BGP based DFZ. Is this doable, what are the pros&cons? Patrick From heinerhummel@aol.com Mon Nov 12 01:23:49 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90D821F84BB for ; Mon, 12 Nov 2012 01:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaiahjmqZ+SI for ; Mon, 12 Nov 2012 01:23:47 -0800 (PST) Received: from imr-ma01.mx.aol.com (imr-ma01.mx.aol.com [64.12.206.39]) by ietfa.amsl.com (Postfix) with ESMTP id BD33721F8487 for ; Mon, 12 Nov 2012 01:23:47 -0800 (PST) Received: from mtaomg-mb06.r1000.mx.aol.com (mtaomg-mb06.r1000.mx.aol.com [172.29.41.77]) by imr-ma01.mx.aol.com (Outbound Mail Relay) with ESMTP id 1E4073800036B; Mon, 12 Nov 2012 04:23:47 -0500 (EST) Received: from core-dqa002b.r1000.mail.aol.com (core-dqa002.r1000.mail.aol.com [172.29.211.197]) by mtaomg-mb06.r1000.mx.aol.com (OMAG/Core Interface) with ESMTP id D0645E000081; Mon, 12 Nov 2012 04:23:46 -0500 (EST) References: <20121112015552.DC3BA18C0C7@mercury.lcs.mit.edu> <08d501cdc07b$582cbdd0$08863970$@huitema.net> To: huitema@huitema.net, rrg@irtf.org In-Reply-To: <08d501cdc07b$582cbdd0$08863970$@huitema.net> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CF8ECE8D24E7CF_C04_DB62A_webmail-m173.sysops.aol.com" X-Mailer: Webmail 37130-STANDARD Received: from 178.27.21.1 by webmail-m173.sysops.aol.com (64.12.78.179) with HTTP (WebMailUI); Mon, 12 Nov 2012 04:23:46 -0500 Message-Id: <8CF8ECE8D1B624F-C04-3AD82@webmail-m173.sysops.aol.com> X-Originating-IP: [178.27.21.1] Date: Mon, 12 Nov 2012 04:23:46 -0500 (EST) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1352712227; bh=EOP9t5RIKmhMy0jfDJrdlNpJ90tlFEs4hr+F3yCTP74=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=ocxrwZQEhJRqQ/S0rCZp8AwwAbtT5ESn1nzLQ6K/Qwo/oopQIRquddvqmEekDaMjF c4UoW61nwTvY6bHd+7O5DFi35Dr+IxB26ETex1OqdJOW9zgdUD1Zxl5duczqgquXi4 qkgsu3cbklhalZiM8IxK6/gIaIsvafYHRXSop0Lg= X-AOL-SCOLL-SCORE: 0:2:358541984:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d294d50a0c022034a Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 09:23:49 -0000 This is a multi-part message in MIME format. ----------MB_8CF8ECE8D24E7CF_C04_DB62A_webmail-m173.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Christian, you are absolutely right. However, avoiding any impact on the users has be= en the number ONE objective of LISP. And now, by moving even to LISP-DDT,i.e. dumping allegeable worse variants,= the consequences will be disasterous. Heiner -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Christian Huitema An: 'Noel Chiappa' ; rrg Verschickt: Mo, 12 Nov 2012 3:13 am Betreff: Re: [rrg] RRG to hibernation > > It does require a new suite of transport protocols > > ... > > the odds of ever reaching deployment on an approach which requires us > > to abandon TCP and UDP are not good? >=20 > That's infeasible; you can't require changing all hosts. You need to see if you can > come up with some approach that avoids that. >=20 > (E.g. if we have location-identity separatation deployed, you could hide the new > locators from the hosts.) I think that we are giving up too early on the feasibility of updating all hosts. Indeed, any substantial change in routing and addressing would most probably end up changing all hosts, or at least most of them. I also think that a research group should not necessarily shy away from investigations that affect all hosts. If research comes out with a brilliant shiny star on the horizon, then engineering might follow. If the best we can do is hack o= n the edges of current solutions, then engineering groups can definitely do that, no need for a research group. -- Christian Huitema _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg =20 ----------MB_8CF8ECE8D24E7CF_C04_DB62A_webmail-m173.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Christian,
you are absolutely right. However,  avoiding any impact on the us= ers has been the number ONE objective of LISP.
And now, by moving even to LISP-DDT,i.e. dumping allegeable worse vari= ants, the consequences will be disasterous.
Heiner


-----= Urspr=C3=BCngliche Mitteilung-----
Von: Christian Huitema <huitema@huitema.net>
An: 'Noel Chiappa' <jnc@mercury.lcs.mit.edu>; rrg <rrg@irtf.org>= ;
Verschickt: Mo, 12 Nov 2012 3:13 am
Betreff: Re: [rrg] RRG to hibernation

>     > It does require a new suit=
e of transport protocols
>     > ...
>     > the odds of ever reaching deployment on an approach which req=
uires
us
>     > to abandon TCP and UDP are not good?
>=20
> That's infeasible; you can't require changing all hosts. You need to s=
ee
if you can
> come up with some approach that avoids that.
>=20
> (E.g. if we have location-identity separatation deployed, you could hi=
de
the new
> locators from the hosts.)

I think that we are giving up too early on the feasibility of updating all
hosts. Indeed, any substantial change in routing and addressing would most
probably end up changing all hosts, or at least most of them. I also think
that a research group should not necessarily shy away from investigations
that affect all hosts. If research comes out with a brilliant shiny star on
the horizon, then engineering might follow. If the best we can do is hack o=
n
the edges of current solutions, then engineering groups can definitely do
that, no need for a research group.

-- Christian Huitema




_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
----------MB_8CF8ECE8D24E7CF_C04_DB62A_webmail-m173.sysops.aol.com-- From jnc@mercury.lcs.mit.edu Mon Nov 12 08:02:57 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C3921F85B4 for ; Mon, 12 Nov 2012 08:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNejvLbHtIWp for ; Mon, 12 Nov 2012 08:02:56 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id B8DFD21F84D8 for ; Mon, 12 Nov 2012 08:02:56 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id ECDBD18C0C3; Mon, 12 Nov 2012 11:02:54 -0500 (EST) To: rrg@irtf.org Message-Id: <20121112160254.ECDBD18C0C3@mercury.lcs.mit.edu> Date: Mon, 12 Nov 2012 11:02:54 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 16:02:57 -0000 > From: Dae Young KIM > the original rationale for RRG was to find a solution to mitigate the > DFZ routing table explosion. That's a good point. However, I think the routing system has more problems 'coming down the road' (as the English expression goes) than just routing table explosion, and it would be good to 'get out in front of them' (i.e. start working on solutions before they become incredibly painful). However, as _deploying_ those solutions will be considerable work, I don't think we'll be able to deploy a solution before they do become painful (since nobody will want to do the work unless/until it's absolutely necessary). However, the 'routing' community could at least think about the problems, and solutions, so that when the larger community turns to us for a solution, we have agreed what the road forward is. > One might argue that LIS does not help reduce the DFZ routing table > size > ... > With multiple Internet service providers(ISPs) serving your site in > multihoming, which PA locator sets should you load your client nodes, > all of them or either of them? You don't configure nodes with locators (for all the very good reasons you give). They are configured with identifiers. > How about ISP migration which is a degenerate case of multihoming? You > have to renumber your locators whenever you're to migrate to a > different ISP. Renumbering is so painful that no network managers would > like to do. Which is why it is identifiers which are configured, not locators. Those are _not_ changed when a site moves to a different ISP. Noel From jnc@mercury.lcs.mit.edu Mon Nov 12 08:15:39 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8A421F8561 for ; Mon, 12 Nov 2012 08:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFk9Af8rZeAD for ; Mon, 12 Nov 2012 08:15:38 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id D7A3721F8531 for ; Mon, 12 Nov 2012 08:15:38 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4BC8418C0C3; Mon, 12 Nov 2012 11:15:36 -0500 (EST) To: rrg@irtf.org Message-Id: <20121112161536.4BC8418C0C3@mercury.lcs.mit.edu> Date: Mon, 12 Nov 2012 11:15:36 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 16:15:39 -0000 > From: "Christian Huitema" > Indeed, any substantial change in routing and addressing would most > probably end up changing all hosts, or at least most of them. Not necessarily, provided that the identity/location mapping layer is deployed as a set of middleboxes (as opposed to being instantiated in all the hosts). One of the benefits from that deployment model is that a new location namespace can be deployed invisibly to the hosts. And of course the routing is invisible to the hosts at the moment anyway, so changing that without the hosts noticing is almost inevitable. > I also think that a research group should not necessarily shy away from > investigations that affect all hosts. If research comes out with a > brilliant shiny star on the horizon, then engineering might follow. You're correct about that. I guess I didn't clearly distinguish in my previous message between research and engineering. From the engineering perspective, a design which requires changes to all hosts is, IMO, a non-starter. But at the same time, I definitely am already a follower of the model that, if all we do is "hack on the edges of current solutions" without some larger vision of where we are going in the long term (and that's often, or usually, missing, in many of the incremental changes), those many small incremental changes will result in nothing more than 'architecture cancer'. So, to me, a "brilliant shiny star on the horizon" really is a requirement; you have to know where you're going in the long term, and that destination has to be a clear, clean, functional architecture. So perhaps we're not so far apart, actually? But in the end, as a practical matter, to get anything done, the path there has to consist of many small steps, each of incremental nature... Noel From tony.li@tony.li Mon Nov 12 09:33:46 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720EE21F86CB for ; Mon, 12 Nov 2012 09:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw7MOLs8imRW for ; Mon, 12 Nov 2012 09:33:46 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAD921F862E for ; Mon, 12 Nov 2012 09:33:41 -0800 (PST) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta01.emeryville.ca.mail.comcast.net with comcast id NfNy1k00J0FhH24A1hZhUy; Mon, 12 Nov 2012 17:33:41 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta08.emeryville.ca.mail.comcast.net with comcast id NhXW1k00E52qHCY8UhXYP1; Mon, 12 Nov 2012 17:31:39 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <20121112161536.4BC8418C0C3@mercury.lcs.mit.edu> Date: Mon, 12 Nov 2012 09:31:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <99F58C68-2C89-40C8-A655-1B5AF72E810E@tony.li> References: <20121112161536.4BC8418C0C3@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:33:46 -0000 On Nov 12, 2012, at 8:15 AM, Noel Chiappa = wrote: > =46rom the engineering > perspective, a design which requires changes to all hosts is, IMO, a > non-starter. Why? Now that upgrades are automated, the work effort involved for the = average end user is not particularly high. And the lifetime of end = hosts seems to be somewhat limited, especially now that the bulk of the = end hosts have become smart phones. And if we subscribe to your proposal that we have and end-goal that's a = clean architecture, then it seems like having a natural fit between the = end host and the architecture is only natural. Tony From jnc@mercury.lcs.mit.edu Mon Nov 12 10:01:18 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117B621F8614 for ; Mon, 12 Nov 2012 10:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.604 X-Spam-Level: X-Spam-Status: No, score=-6.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCmCIZ2oj3wR for ; Mon, 12 Nov 2012 10:01:17 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 344A921F84CF for ; Mon, 12 Nov 2012 10:01:17 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A303B18C0D1; Mon, 12 Nov 2012 13:01:12 -0500 (EST) To: rrg@irtf.org Message-Id: <20121112180112.A303B18C0D1@mercury.lcs.mit.edu> Date: Mon, 12 Nov 2012 13:01:12 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:01:18 -0000 > From: Tony Li >> a design which requires changes to all hosts is, IMO, a non-starter. > Why? Practise shows that it doesn't work. We can speculate as to why: my theory is that it increases the cost (in a broader sense than just $/Euros/etc), and I think you need to have a pretty low cost threshold to get new stuff out. YMMV. Noel From tony.li@tony.li Mon Nov 12 10:51:03 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE4821F8686 for ; Mon, 12 Nov 2012 10:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH9V5Zgj9Q8e for ; Mon, 12 Nov 2012 10:51:03 -0800 (PST) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by ietfa.amsl.com (Postfix) with ESMTP id 335B021F85BB for ; Mon, 12 Nov 2012 10:51:03 -0800 (PST) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta14.emeryville.ca.mail.comcast.net with comcast id NgtK1k0020mlR8UAEir30W; Mon, 12 Nov 2012 18:51:03 +0000 Received: from [10.155.35.198] ([128.107.239.234]) by omta11.emeryville.ca.mail.comcast.net with comcast id Nios1k009547xYo8XiouFN; Mon, 12 Nov 2012 18:49:01 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <20121112180112.A303B18C0D1@mercury.lcs.mit.edu> Date: Mon, 12 Nov 2012 10:48:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <272D6936-F0F3-4E4D-B9D1-516ADAE5CB46@tony.li> References: <20121112180112.A303B18C0D1@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:51:03 -0000 >>> a design which requires changes to all hosts is, IMO, a non-starter. >=20 >> Why? >=20 > Practise shows that it doesn't work. >=20 > We can speculate as to why: my theory is that it increases the cost = (in a > broader sense than just $/Euros/etc), and I think you need to have a = pretty > low cost threshold to get new stuff out. >=20 > YMMV. Past experiences need not be a predictor of future failure. ;-) The cost of software changes to the end user are now pretty much lost in = the churn of maintenance releases and new devices. Thus, the real hurdle that has to be accomplished is to woo the OS = providers. Convince them to implement and distribute and that solves = the deployment problem. And to convince the OS providers, you have to = show them the killer app. Without a value add, it's not in their = interest. But once you do have that value add, it would seem to be all downhill. Tony From mark@townsley.net Mon Nov 12 14:36:08 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCCC21F87AA for ; Mon, 12 Nov 2012 14:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUD8AsWuM6Zw for ; Mon, 12 Nov 2012 14:36:07 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD2621F87C5 for ; Mon, 12 Nov 2012 14:36:07 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id c13so764807eek.13 for ; Mon, 12 Nov 2012 14:36:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=AnHhdiNtkeW/GtMXEgJswAzXaZ5SZm+1qOlUPkETeao=; b=PtOz4bq8sE4SN2t4nhjcUij/SvinT0+KnU6pn14MqVuW5Le0mO0dmiBZRhzpeEW+GR PQfSOP//ihRQ+aR4fu0cguNpsal6MfQ/lbY0Tj06tN0FBdz70L2N4scL1V3M/hv1diL6 FU2H0MPEmlXmnL5m8om9TqdGzePGHDUbeTOWqSNlVHP+VZkedL60EwmgpFnAK89uv5Br JUk4fAbLIjUPvYKv2tuQgDz/rama0pTKudn8ORi4FcVumB1Ax6//JRrCCqJXuGT9n6pB 7DXoBv8xrVgQR4S7O8RORcbhvsBUlJMSYtGLWquO+A+PekMxz3C+1C0afyCHQe6UwMQj MVJw== Received: by 10.14.174.194 with SMTP id x42mr67992513eel.22.1352759766334; Mon, 12 Nov 2012 14:36:06 -0800 (PST) Received: from ams-townsley-8915.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id f2sm18656640eep.2.2012.11.12.14.36.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 14:36:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <272D6936-F0F3-4E4D-B9D1-516ADAE5CB46@tony.li> Date: Mon, 12 Nov 2012 23:15:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121112180112.A303B18C0D1@mercury.lcs.mit.edu> <272D6936-F0F3-4E4D-B9D1-516ADAE5CB46@tony.li> To: Tony Li X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnFPUNp3oyGC4RMoH21ziGb4cRnvhc8wLTJC6JGjy09bgJNio9EQgpGDt+EghCxIQ+q/g8a Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:36:08 -0000 On Nov 12, 2012, at 7:48 PM, Tony Li wrote: >=20 >>>> a design which requires changes to all hosts is, IMO, a = non-starter. >>=20 >>> Why? >>=20 >> Practise shows that it doesn't work. >>=20 >> We can speculate as to why: my theory is that it increases the cost = (in a >> broader sense than just $/Euros/etc), and I think you need to have a = pretty >> low cost threshold to get new stuff out. >>=20 >> YMMV. >=20 >=20 > Past experiences need not be a predictor of future failure. ;-) >=20 > The cost of software changes to the end user are now pretty much lost = in the churn of maintenance releases and new devices. >=20 > Thus, the real hurdle that has to be accomplished is to woo the OS = providers. Convince them to implement and distribute and that solves = the deployment problem. And to convince the OS providers, you have to = show them the killer app. Without a value add, it's not in their = interest. >=20 > But once you do have that value add, it would seem to be all downhill. As a data point - we squashed 6to4 mostly by actively rooting it out in = the hosts. We started talking about how it should go away in 2008-9. = Modifications came out in 2010. It was essentially dead by the end of = 2011. 3 years. But, only a subset of hosts and apps were causing the = bulk of the problem to begin with - a subset that happened to already = respond well to updates.=20 The real question is whether "some hosts" is good enough or not. If you = really need "all hosts" to participate, you have to ask if and when you = are willing to throw the previous generation of non-self-updating = webcams, TVs, Windows XP, etc. under the bus.=20 - Mark >=20 > Tony >=20 > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg From rja.lists@gmail.com Mon Nov 12 15:25:27 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9708A21F84F3 for ; Mon, 12 Nov 2012 15:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSRj5Kb6gchx for ; Mon, 12 Nov 2012 15:25:26 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id AC7EE21F84BC for ; Mon, 12 Nov 2012 15:25:26 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so8895849vba.13 for ; Mon, 12 Nov 2012 15:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=RZSuwoy8j05wHdcc9IvFB91iot3Gsyl3X+Kq5b9voV8=; b=aB4yoF70eK750GNZ//+tOFKYwLDqTIpMsBsXTlwmfJcUGRbI9Yz4igvmDbURPxQLCE 0EcUyw+answ+jJHZT8jJP6mJAcyNgJ6vyoTbaW1x7xknlDf+X9sentkdkzmRNXlsLvGx hHNYSafsBVfUxjP31eyTWdmbIyT+VI9b333t4OLSXyF0kfQetEwjRoGmWFq09cJzqlJi EdoiPJvKcNOxp7z3FZr+jBetjvhFNf28t6CYSgVkaQzfYT01kscOBs6ZD08SPzRVfFBk MvNUVtlQr/qQt486B9y9p1YQro9YaIaTtWjHKQbaeeKiNLL8PSJd3Z/3IDdLdZRpQBKM aBQg== Received: by 10.52.33.130 with SMTP id r2mr23911639vdi.43.1352762725891; Mon, 12 Nov 2012 15:25:25 -0800 (PST) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id y15sm8290519vdt.9.2012.11.12.15.25.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 15:25:25 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 12 Nov 2012 18:25:23 -0500 Message-Id: To: IRTF Routing RG Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [rrg] Updating hosts X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:25:27 -0000 On Sunday, 11 Nov 2012, Christian Huitema wrote, in part: > I think that we are giving up too early on the feasibility > of updating all hosts. [...] I also think that a research group > should not necessarily shy away from investigations that > affect all hosts. +1 Later on Sunday, 11 Nov 2012, Joel M Halpern wrote, in part: > I can well believe we can, for a reasonable value of all, > update all host TCP and UDP engines with a small, migratable, > change. > > We can't change all host applications. > > And we can not make a change that does not interoperate > with existing hosts. +1 Indeed, ILNP does update hosts, but does so with a clearly documented "backwards compatibility" mechanism and also a clearly documented "incremental deployment" scheme. At least one ILNP prototype already has shown an *un-modified* (i.e. no source code changes, no recompilation) FreeBSD ping6 binary using ILNPv6 between a pair of ILNPv6-enabled hosts. (NB: I'm aware of 2 independent implementations of ILNP that are underway, one for Linux and one for FreeBSD.) This is a good initial step towards showing that ILNP will enable existing "host applications" to be used with ILNP -- without requiring application changes. On Monday, 12 November 2012, Tony Li wrote, in part: > The cost of software changes to the end user are now pretty much > lost in the churn of maintenance releases and new devices. > > Thus, the real hurdle that has to be accomplished is to woo > the OS providers. Convince them to implement and distribute > and that solves the deployment problem. And to convince the > OS providers, you have to show them the killer app. Without > a value add, it's not in their interest. +1 The market makes its own determinations about what might be sufficient "value add" to be worthwhile to distribute. My crystal ball ('palantir') is cloudy, but here are some candidates, as a thought exercise: 1) Handset Mobility The ability to migrate TCP (or UDP or ...) sessions of a mobile handset (or Surface or iPad or similar) between the (usually lower cost per bit) WiFi interface and the (usually higher cost per bit) GSM/LTE/CDMA2000 interface, as desired, without losing the application-layer session, and without requiring deployment of special Mobile-IP routers, might be such a killer app. [See MILCOM 2008 paper and the "mobile networks" paper from MILCOM 2009 for how this works] 2) VM migration across routed IP subnetworks The ability to move an entire VM across routed IP subnets might be another such application. Certainly some large multi-site data centre operators (e.g. folks who measure computing in CPU-Acres or CPU-Hectares) very much would like that capability. [See our MILCOM 2012 paper for how] 3) Site-Driven Multi-homing (w/o adding prefixes to DFZ) The ability of sites to multi-home, without having to coordinate with all of their upstream providers, and without having to add site-specific routing prefixes into the world-wide DFZ RIB appeals to many. [See our MILCOM 2009 paper on site-Controlled multi-homing for how] Yours, Ran PS: All of these MILCOM papers are available from U. St Andrews, along with nearly all of the other ILNP papers. :-) From wherrin@gmail.com Mon Nov 12 15:30:35 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A34A21F84D0 for ; Mon, 12 Nov 2012 15:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkzMDhH5sNfk for ; Mon, 12 Nov 2012 15:30:34 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 30C7421F86B8 for ; Mon, 12 Nov 2012 15:30:34 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id 16so1104683obc.13 for ; Mon, 12 Nov 2012 15:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=4Pv6XI9r1FeM1JyUBrYxddbUKDztjLsv5LdJQ6ilM0c=; b=Nnfr6vo15Y+Yo7zb3Um0w0YVh1fiC3d6SaSq8SL32/2Iv2UZp6YkPMEhzZHImIOWiE nfKjmOD5M+3YEzi0zAu0QJj2FIKEb9q8ErRLOGZldDoxoTIMEDNWGodjIsPFKs662Y3c 6R6BMcYPEFr0XJ+7xCEwzlz3kiGJDDfre+mUGsUoZK0/SDE6ygdD6LFPO1mYlMEMeNd0 wwljUQSYvcgLUD+jZVNpLbq4j0btwKLTowZptZfji+ZVZRoM3AHWNBqdtzhhWTDMBoiD XWibaPPIOrkp4ks6UPb3/zheHM/pHztrv3E3H8Zdj4gFLbfAGdCnXnJD6UNYpkVSIU+D Re6g== Received: by 10.60.172.171 with SMTP id bd11mr16386428oec.4.1352763033666; Mon, 12 Nov 2012 15:30:33 -0800 (PST) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.182.81.164 with HTTP; Mon, 12 Nov 2012 15:30:12 -0800 (PST) From: William Herrin Date: Mon, 12 Nov 2012 18:30:12 -0500 X-Google-Sender-Auth: x0fLGnWMZnzBSZFPWAcSWk_ZkPI Message-ID: To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Cc: rrg@irtf.org Subject: [rrg] Rerouting by readdressing X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:30:35 -0000 On Sun, Nov 11, 2012 at 8:55 PM, Noel Chiappa wrote: > > From: William Herrin > > > I have a notion for a "routing" protocol > > I'm glad you put the 'routing' in quotations, because to me, 'routing' is i) > the _selection of paths_, and ii) the distribution of the information needed > to select paths. Hi Noel, Well, I figure: we've been trying for 20 years to come up with a BGP replacement that scales. In that time we've discovered that: 1. Algorithmically determining the netmask instead of passing it as a separate datum is a bad idea. 2. Building layer 4 protocols with a static dependence on the layer 3 address requires any network that isn't part of a perfect heirarchy to blast destination knowledge to every other network that isn't a strict hierarchy. 3. Because the FIB has distinctly different outputs than the RIB, its possible to aggregate it where it wasn't possible to aggregate the RIB. 4. Disaggregation = bad. If all of that is correct, and it does seem to be, then maybe there just aren't any good answers to be found within the "box" bounded by TCP's need to have a stable IP address. So, lets set that box aside for a while and think about what routing might look like without it. What can we do if we don't care whether the endpoint has a stable layer-3 address so long as it has some layer-3 address at any given time? > I'm not sure what definition other people are using, but it might be useful > to come up with a standard one to prevent confusion. At its most abstract, the routing process figures out how to get packets from A to B via C. Everything at a finer level of detail is subject to detail-level rules. Some of them can be bent. Others can be broken. > > which manages link changes through dynamic re-addressing and multiply > > addressing hosts. By and large the addresses change so that the > > trivially aggregable routes don't have to. Not just at the host level > > but all the way downstream from the link change. > > If I understand you properly, this is a way of dealing with topology changes > by re-numbering things? (To use the definition of 'routing' above, you > wouldn't need to propogate new information, because the old data would still > be valid - it's just that the things the old information would apply to have > changed?) That's the gist of it, yeah. Any given node has three types of links: coreward, hostward and sideward. A coreward link is one from which this node accepts a block of addresses tied to a "default route." Not necessarily 0/0. 2000::/3 is a default route. A hostward link is one on which this node offers blocks of addresses tied to a default route and the neighboring node has accepted assignment of those addresses. A sideward link is one on which an offer of addresses has been made but rejected by the neighbor as it already has a satisfactory coreward path, yet this node has also rejected the neighbors offer of addresses. Each address block you hold (and you don't hold many) is tied to a single coreward path which immediately aggregates into a larger block of addresses held by your coreward neighbor. If any element of the coreward path fails, you send a message hostward instructing every router and host in that direction that the address block is no longer valid. >From your hostward neighbor, you'll receive a notification that the assigned address block has reached its utilization high water mark. If you have enough addresses, you'll assign it a new bigger block and tell it to schedule release of the existing block in 300 seconds. And in 300 seconds you send another message hostward declaring the old block invalid. If you need more addresses to fulfill the request, you send a message coreward indicating that you've reached your high water mark and need a bigger address block. Same process when your hostward neighbor advises that his address utilization has reached his low water mark. Sideward you send disaggregated routes which create shortcuts through the network so it need not operate as a strict heirarchy. But these routes are needed only for efficiency, not connectedness. They can be discarded at any distance without harm. It's probably even practical to implement a short-term tunneled reroute via a formerly sideward now coreward link so that you can release the old addresses gracefully after a link failure. > I need to go away and think about this for a while before I can have some > really solid reaction, but off the top of my head I wonder if the work > involved in keeping up with the changing addresses isn't as much (or possibly > more) work than the usual approach. TANSTAAFL, after all... Overall, it's more work for a certainty. In terms of the maximum work required for any particular node, my SWAG puts it far smaller than it is now. And it seems to exhibit negligible growth with the number of links and nodes in the network -- more than a couple hops away you're dealing with a single aggregate regardless. > > Even bumps automatic resizing requirements upstream so that over time > > any given router offers exactly one route outward which automatically > > aggregates with the route its upstream already holds. > > Err, routing (in the sense given at the top) is trivial when there's only one > path ("its upstream"). It's finding/selecting paths in arbitrary graphs with > lots of alternate paths (i.e. ones with lots of 'cycles', to use the > graph-theory term) which is the hard case. We have excellent solutions for the hard case provided the graph-like component to the network contains a sufficiently small number of prefixes. If we can find a solution for a sufficiently large portion of the network which looks as much like a heirarchy as a graph, and that solution plays nicely with the purely graphy parts, then pragmatically speaking the scalability problem is solved. > > It does require a new suite of transport protocols > > ... > > the odds of ever reaching deployment on an approach which requires us > > to abandon TCP and UDP are not good? > > That's infeasible; you can't require changing all hosts. You need to see if > you can come up with some approach that avoids that. > > (E.g. if we have location-identity separatation deployed, you could hide the > new locators from the hosts.) Perhaps. But maybe it's worth setting aside that question long enough to determine whether an internally consistent technical solution can be built at all. A transport protocol which doesn't require a stable address should work equally well on a network which does provide one and on a network which does not. Maybe that's the way in. >> Are you game to flesh it out and see how far we can run with it > > Right at the moment, I personally don't have any spare time/energy. Well, lack of spare time/energy is a problem. But if there's only time to consider ideas within the box bounded by a TCP-required stable host address then it hardly seems fair to criticize the research process for not finding anything new or insightful. > But you > should think about it (and try and write something); even if it's not usable > directly, there might be some aspects that could be useful to other designs. As it happens, I've spent a few dozens of hours pondering it. But it's only so much fun to play with one's self and my participation here is not paid (hire me please!) The research we've done wants to lead us in a direction where the host address isn't stable. I respectfully suggest we follow and see what there is to be seen. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dykim6@gmail.com Mon Nov 12 15:31:10 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD8721F8625 for ; Mon, 12 Nov 2012 15:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjQmYcxX1KP8 for ; Mon, 12 Nov 2012 15:31:10 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2A49021F8529 for ; Mon, 12 Nov 2012 15:31:10 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so3502264qcs.13 for ; Mon, 12 Nov 2012 15:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=qHeG7uBg73gmBtsTsazqU+q0nUiXgupUc4AJQprtRcQ=; b=AZmUCV0pTd/rIdOo9RpwL2t9Wb01nVAffq3V/63dJlwlYpQfkGQk/eDKd8zLOzYUJR /D/DYm0utb6Lr97ov6qvpFUe5Tcgtvq/KEVyWia4wxti5mPSp3+EaolTjGOeYGVHW2xq CD9GTtpyDP+cQ4zH4aXGiMgVbq9eo9jqKxmZwbCAucb9VhXZz4SL8nUCbaPzUg273XkM PimX9k1xcym4ipmzXAuaHlpvA9jLZOCpyC8GsTQRCquIV7Hg0vokOhLihX4hsm9xIEHf 4nxIXVT0zWHHF8g2k5q84RbltAv9WBGfIWllXdakaMKg0g1VN3WREIQYscf9hx5R8CzA YXHA== Received: by 10.49.4.168 with SMTP id l8mr26111023qel.57.1352763069589; Mon, 12 Nov 2012 15:31:09 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Mon, 12 Nov 2012 15:30:48 -0800 (PST) In-Reply-To: <20121112160254.ECDBD18C0C3@mercury.lcs.mit.edu> References: <20121112160254.ECDBD18C0C3@mercury.lcs.mit.edu> From: Dae Young KIM Date: Tue, 13 Nov 2012 08:30:48 +0900 X-Google-Sender-Auth: aA98gZFdNsrsZXhhxTC-57a8Gik Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary=047d7bb04f223a6a0b04ce54b2ae Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:31:10 -0000 --047d7bb04f223a6a0b04ce54b2ae Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 13, 2012 at 1:02 AM, Noel Chiappa wrote: > > However, I think the routing system has more problems 'coming down the > road' > (as the English expression goes) than just routing table explosion, and it > would be good to 'get out in front of them' (i.e. start working on > solutions > before they become incredibly painful). > Indeed. You don't configure nodes with locators (for all the very good reasons you > give). They are configured with identifiers. > Which is why it is identifiers which are configured, not locators. Those > are > _not_ changed when a site moves to a different ISP. By taking ILNP as an example, locators are subnet identifiers, a host is associated with multiple locators at multi-homing. This multiplicity of the locators, although the ID is single, implies multiple I-L vectors for a host and also affects DNS entries. This is equivalent to requiring IP hosts to be configured with multiple PA addresses. Have we solved the problem? Any improvement over the current IP situation? I'm afraid not. Multi-homing is not improved. -- DY --047d7bb04f223a6a0b04ce54b2ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 1:02 AM, Noel Chiappa <jnc@mercury.lcs.mit.e= du> wrote:

However, I think the routing system has more problems 'coming down the = road'
(as the English expression goes) than just routing table explosion, and it<= br> would be good to 'get out in front of them' (i.e. start working on = solutions
before they become incredibly painful).

Indeed.
You don't configure nodes with locators (for all the very good reasons = you
give). They are configured with identifiers.
=A0
Which is why it is identifiers which are config= ured, not locators. Those are
_not_ changed when a site moves to a different ISP.

By= taking ILNP as an example, locators are subnet identifiers, a host is asso= ciated with multiple locators at multi-homing. This multiplicity of the loc= ators, although the ID is single, implies multiple I-L vectors for a host a= nd also affects DNS entries.

This is equivalent to requiring IP hosts to be configured with multiple= PA addresses.

Have we solved the problem? Any improvement over the = current IP situation? I'm afraid not. Multi-homing is not improved.

--
DY
--047d7bb04f223a6a0b04ce54b2ae-- From jnc@mercury.lcs.mit.edu Mon Nov 12 15:40:18 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D53821F8487 for ; Mon, 12 Nov 2012 15:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.604 X-Spam-Level: X-Spam-Status: No, score=-6.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DQgslkHPY2T for ; Mon, 12 Nov 2012 15:40:18 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0D421F84FC for ; Mon, 12 Nov 2012 15:40:13 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 05F8E18C0CA; Mon, 12 Nov 2012 18:40:12 -0500 (EST) To: rrg@irtf.org Message-Id: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> Date: Mon, 12 Nov 2012 18:40:12 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:40:18 -0000 > From: Dae Young KIM > This multiplicity of the locators, although the ID is single ... also > affects DNS entries. Not necessarily. If the DNS only contains IDs (which is the way some designs work), then there no DNS/locator issues. Noel From dykim6@gmail.com Mon Nov 12 15:59:49 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDB721F86EC for ; Mon, 12 Nov 2012 15:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i1iiAFTh-PG for ; Mon, 12 Nov 2012 15:59:48 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAF421F86E4 for ; Mon, 12 Nov 2012 15:59:48 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so3516501qcs.13 for ; Mon, 12 Nov 2012 15:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=/DtIkLY6NXc8UFNhhBs+ZFRmHxXLSkD9RIJ7bKuI/s4=; b=BSsUuhU8N2Fjt6vL/Rk1mq2ICWklkn3Vt7QbkE1z26RBFV6gWQ/dvCn/xIteqTojYM UJ7xWc1bhUFygAyUBwZhshnDt+blntDxYdXnd8M2kDR8IaZa36QwKmEiWNm3pjI91fbr Eaf86U5cJDR9tJGM1VM7DDr9jSacqm181Il2nHgqJPkUkdGrxJw/F9usYFj7rzq7V10D l6qe2Fgds+DJJ7bTlHsczk8HzcZ6SYFPBVxclY5NET990xMTyht8znr50+5xLAmnGzLg 9FpXv7AviA81qtQj+hPtnA7IRFvqUahMDjMDdmh81bPUwgOH5qdrgd2xhQAE/DJZVDHQ 10EA== Received: by 10.224.146.74 with SMTP id g10mr22050049qav.93.1352764788018; Mon, 12 Nov 2012 15:59:48 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Mon, 12 Nov 2012 15:59:27 -0800 (PST) In-Reply-To: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> From: Dae Young KIM Date: Tue, 13 Nov 2012 08:59:27 +0900 X-Google-Sender-Auth: lSmMXPCTsjeI9P3mNWwnM6YbjDY Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary=089e0111ce9ea78d6d04ce551824 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:59:49 -0000 --089e0111ce9ea78d6d04ce551824 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 13, 2012 at 8:40 AM, Noel Chiappa wrote: > > From: Dae Young KIM > > > This multiplicity of the locators, although the ID is single ... also > > affects DNS entries. > > Not necessarily. If the DNS only contains IDs (which is the way some > designs > work), then there no DNS/locator issues. > The description on servers in Sec. 4.1 of ILNP, p. 20, implies that. The DNS concern is, however, a secondary thing. That a host has to be associated with multiple PA locators inserted by multiple ISPs at ILNP multi-homing is the real problem I'm pointing to. This is exactly the same situation you might require with the current IP. Where's the improvement on multi-homing? If there's no such improvement, have we solve the table explosion problem? -- DY --089e0111ce9ea78d6d04ce551824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 8:40 AM, Noel Chiappa <jnc@mercury.lcs.mit.e= du> wrote:
=A0 =A0 > From: Dae Young KIM <dykim@cnu.kr>

=A0 =A0 > This multiplicity of the locators, although the ID is si= ngle ... also
=A0 =A0 > affects DNS entries.

Not necessarily. If the DNS only contains IDs (which is the way some design= s
work), then there no DNS/locator issues.

The description on servers in Sec. 4.1 of ILNP, p. 20, implies that.
The DNS concern is, however, a secondary thing. That a host has to be= associated with multiple PA locators inserted by multiple ISPs at ILNP mul= ti-homing is the real problem I'm pointing to. This is exactly the same= situation you might require with the current IP.

Where's the improvement on multi-homing? If there's no such imp= rovement, have we solve the table explosion problem?

-- =
DY
--089e0111ce9ea78d6d04ce551824-- From jmh@joelhalpern.com Mon Nov 12 16:08:31 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36921F87A6 for ; Mon, 12 Nov 2012 16:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5ZzdND5Qpcd for ; Mon, 12 Nov 2012 16:08:31 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id F08E121F8775 for ; Mon, 12 Nov 2012 16:08:30 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 40FB0558C57 for ; Mon, 12 Nov 2012 16:08:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A02EC1C08E0; Mon, 12 Nov 2012 16:08:23 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-236.clppva.btas.verizon.net [71.161.52.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 082211C08F0; Mon, 12 Nov 2012 16:08:22 -0800 (PST) Message-ID: <50A18F75.8060001@joelhalpern.com> Date: Mon, 12 Nov 2012 19:08:21 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dae Young KIM References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:08:31 -0000 I do not see the difficulty. We already have the IPv6 mechanisms to advertise the prefixes. And we have the IPv6 mechanisms for hosts to combne the prefixes with teir IDs. We also have the dynamic DNS mechanisms (with security) needed to advertise the results. With ILP, these combinations can be changed during sessions, and traffic can change paths during sessions without impact. With the current architecture, sessions can not change paths, and changes to the connectivity are hard to discover or utilize. Thee are other multi-homing problems that are not solved. Working out how to manage prefix assignments in an enterprise when external assignments change is one example of such issues (LISP takes a different tack, and thus the costs and benefits are different.) Yours, Joel On 11/12/2012 6:59 PM, Dae Young KIM wrote: > On Tue, Nov 13, 2012 at 8:40 AM, Noel Chiappa > wrote: > > > From: Dae Young KIM > > > > This multiplicity of the locators, although the ID is single > ... also > > affects DNS entries. > > Not necessarily. If the DNS only contains IDs (which is the way some > designs > work), then there no DNS/locator issues. > > > The description on servers in Sec. 4.1 of ILNP, p. 20, implies that. > > The DNS concern is, however, a secondary thing. That a host has to be > associated with multiple PA locators inserted by multiple ISPs at ILNP > multi-homing is the real problem I'm pointing to. This is exactly the > same situation you might require with the current IP. > > Where's the improvement on multi-homing? If there's no such improvement, > have we solve the table explosion problem? > > -- > DY > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From dykim6@gmail.com Mon Nov 12 16:12:59 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14AD21F879C for ; Mon, 12 Nov 2012 16:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwCHu9RqwpJ3 for ; Mon, 12 Nov 2012 16:12:59 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4A321F8614 for ; Mon, 12 Nov 2012 16:12:59 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so3523455qcs.13 for ; Mon, 12 Nov 2012 16:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Qr5tEGbncY80aJbtyxWOm0gdV46JYu2rQe13ZjfOj6M=; b=GKzGV+dWOv7aFtlQG9ik85X95SKoYhCHlS50VQnwGVPKBbLNL4g8EzfU8xYhrcFFpP STFplTPbY0Kmdm84+pxNpL6hc/wfe4V60vlHlM6lF32a4yb+z8e5H+AmGv3JNo8LLQzZ uxF02nF5l0xhkloT5zu5bCEJcYm8hZw6z74+HMFc2oOoXhz3jtv9AENhbWZSnUh0VBbA aXlwJMY1Uh+aEL4siQwPJPRaZp3zk3n3lBfFE1uqCdxbmA1omYceQqFR5kB0TN+As7xX wFth5QkmWDFcFFoAHx7YlfJ5Yj0lrAqngqgcS5xQfuji5BbIm1a0gjWA94yE2XbOzTf1 /Mcg== Received: by 10.224.146.74 with SMTP id g10mr22062354qav.93.1352765578658; Mon, 12 Nov 2012 16:12:58 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Mon, 12 Nov 2012 16:12:38 -0800 (PST) In-Reply-To: <50A18F75.8060001@joelhalpern.com> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> From: Dae Young KIM Date: Tue, 13 Nov 2012 09:12:38 +0900 X-Google-Sender-Auth: LO33OEgx_t6A6y1r0HTDERnZbu0 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=089e0111ce9ec7c2da04ce5547ab Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:13:00 -0000 --089e0111ce9ec7c2da04ce5547ab Content-Type: text/plain; charset=ISO-8859-1 Hi, Joel, Perhaps a more direct question might serve here: o How has ILNP solved the problem of the DFZ routing table explosion? On Tue, Nov 13, 2012 at 9:08 AM, Joel M. Halpern wrote: > I do not see the difficulty. We already have the IPv6 mechanisms to > advertise the prefixes. And we have the IPv6 mechanisms for hosts to > combne the prefixes with teir IDs. > We also have the dynamic DNS mechanisms (with security) needed to > advertise the results. > > With ILP, these combinations can be changed during sessions, and traffic > can change paths during sessions without impact. > With the current architecture, sessions can not change paths, and changes > to the connectivity are hard to discover or utilize. > > Thee are other multi-homing problems that are not solved. Working out how > to manage prefix assignments in an enterprise when external assignments > change is one example of such issues (LISP takes a different tack, and thus > the costs and benefits are different.) > > Yours, > Joel > -- DY --089e0111ce9ec7c2da04ce5547ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Joel,

Perhaps a more direct question might serve here:

= =A0=A0 o How has ILNP solved the problem of the DFZ routing table explosion= ?

On Tue, Nov 13, 2012 at 9:08 AM, Joel M= . Halpern <jmh@joelhalpern.com> wrote:
I do not see the difficulty. =A0We already h= ave the IPv6 mechanisms to advertise the prefixes. =A0And we have the IPv6 = mechanisms for hosts to combne the prefixes with teir IDs.
We also have the dynamic DNS mechanisms (with security) needed to advertise= the results.

With ILP, these combinations can be changed during sessions, and traffic ca= n change paths during sessions without impact.
With the current architecture, sessions can not change paths, and changes t= o the connectivity are hard to discover or utilize.

Thee are other multi-homing problems that are not solved. =A0Working out ho= w to manage prefix assignments in an enterprise when external assignments c= hange is one example of such issues (LISP takes a different tack, and thus = the costs and benefits are different.)

Yours,
Joel

--
DY
--089e0111ce9ec7c2da04ce5547ab-- From tony.li@tony.li Mon Nov 12 16:30:31 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B4221F849A for ; Mon, 12 Nov 2012 16:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcHoZ9E-X2AZ for ; Mon, 12 Nov 2012 16:30:31 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 3712521F846F for ; Mon, 12 Nov 2012 16:30:31 -0800 (PST) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta01.emeryville.ca.mail.comcast.net with comcast id No0t1k04X0S2fkCA1oWX5a; Tue, 13 Nov 2012 00:30:31 +0000 Received: from [10.155.35.198] ([128.107.239.234]) by omta09.emeryville.ca.mail.comcast.net with comcast id NoUJ1k00Q547xYo8VoULGU; Tue, 13 Nov 2012 00:28:29 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Mon, 12 Nov 2012 16:28:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> To: Dae Young KIM X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:30:32 -0000 On Nov 12, 2012, at 4:12 PM, Dae Young KIM wrote: > o How has ILNP solved the problem of the DFZ routing table = explosion? Simple: one of the contributors to the explosion is the drive for PI = prefixes. This is driven by sites that choose to be multi-homed and = want failover semantics that BGP can provide. With ILNP, a site can get this semantics with multiple PA prefixes. I hope that this is clear. If not, this has been discussed ad nauseum = in the mailing list archives. Can we please move on? Cheers, Tony From jakob.heitz@ericsson.com Mon Nov 12 16:38:00 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C658021F87BD for ; Mon, 12 Nov 2012 16:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yURrN4K9Dplj for ; Mon, 12 Nov 2012 16:38:00 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 286B921F86EB for ; Mon, 12 Nov 2012 16:38:00 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAD0hpW2014026; Mon, 12 Nov 2012 18:43:52 -0600 Received: from EUSAAHC002.ericsson.se (147.117.188.78) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 12 Nov 2012 19:37:48 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 19:37:48 -0500 From: Jakob Heitz To: Tony Li , Dae Young KIM Thread-Topic: [rrg] RRG to hibernation Thread-Index: AQHNwS8OxfFwT5HrcEGBsoF0IYRxMZfnNPKAgAACfICAAAEzAIAABGAA//+uKlA= Date: Tue, 13 Nov 2012 00:37:47 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E0D8EAF@EUSAAMB109.ericsson.se> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rrg@irtf.org" Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:38:00 -0000 What explosion? http://ripe63.ripe.net/archives/video/178 http://ripe63.ripe.net/presentations/61-2011-10-31-bgp2011.pdf On , Tony Li <> wrote: > On Nov 12, 2012, at 4:12 PM, Dae Young KIM wrote: >=20 >> o How has ILNP solved the problem of the DFZ routing table >> explosion?=20 >=20 >=20 > Simple: one of the contributors to the explosion is the drive > for PI prefixes. This is driven by sites that choose to be > multi-homed and want failover semantics that BGP can provide. >=20 > With ILNP, a site can get this semantics with multiple PA prefixes. >=20 > I hope that this is clear. If not, this has been discussed > ad nauseum in the mailing list archives. >=20 > Can we please move on? >=20 > Cheers, > Tony >=20 --=20 Jakob Heitz. From dykim6@gmail.com Mon Nov 12 16:53:05 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CCE21F87DF for ; Mon, 12 Nov 2012 16:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlwJOX2OhiYZ for ; Mon, 12 Nov 2012 16:53:03 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6628321F878C for ; Mon, 12 Nov 2012 16:53:03 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so3542075qcs.13 for ; Mon, 12 Nov 2012 16:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=P6NZs0WW+3JvyNmX3zRvamGaSNsbwScTxtMgRjZ7kvs=; b=cS0KsEut65/pwPn/3AURGPu4a1a01Pm9JhFIww1EzmTqcHv0ICoy0fK+IEPEjgJNlk ubEL/jDoUp09r3S8QTZ1iG+JqgWYoWMblwwabWGPljTOwWjN1HHsY0F73X+Az7F8DLjO XuE7hHaJV8zezszTziuhCpo5Skxuqv50u+XfRLLd359GqOmVu6HF5GXFDvJwk7lj+QmH JHy7cNxu8yYslOngpYoHBBDkDrAKnCHAexIwmyK+UeqUxxyJt3a/6CF0XssjKYwYlOWz 5Kqo77CQvjAPlNWKBpoDhVOctINwm3YYzpcbEI6jcPWpzRmUzIdjrkn2Nakjn+mdPMls JrbQ== Received: by 10.49.13.202 with SMTP id j10mr26335660qec.27.1352767982725; Mon, 12 Nov 2012 16:53:02 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Mon, 12 Nov 2012 16:52:42 -0800 (PST) In-Reply-To: References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> From: Dae Young KIM Date: Tue, 13 Nov 2012 09:52:42 +0900 X-Google-Sender-Auth: 0TBIr2fq-bR9xszpMUvPuYWCFU0 Message-ID: To: Tony Li Content-Type: multipart/alternative; boundary=047d7b6da7e812ea6704ce55d7e0 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:53:05 -0000 --047d7b6da7e812ea6704ce55d7e0 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 13, 2012 at 9:28 AM, Tony Li wrote: > > Simple: one of the contributors to the explosion is the drive for PI > prefixes. This is driven by sites that choose to be multi-homed and want > failover semantics that BGP can provide. > > With ILNP, a site can get this semantics with multiple PA prefixes. > Hold a second before you vomit. Isn't the description the same with the current IP Internet? Can't the current Internet do the same? Any change? -- DY --047d7b6da7e812ea6704ce55d7e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 9:28 AM, Tony Li <tony.li@tony.li> wro= te:

Simple: one of the contributors to the explosion is the drive for PI = prefixes. =A0This is driven by sites that choose to be multi-homed and want= failover semantics that BGP can provide.

With ILNP, a site can get this semantics with multiple PA prefixes.

Hold a second before you vomit.

Isn&= #39;t the description the same with the current IP Internet? Can't the = current Internet do the same? Any change?

--
DY
--047d7b6da7e812ea6704ce55d7e0-- From rw@firstpr.com.au Mon Nov 12 17:05:24 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DA621F84F8 for ; Mon, 12 Nov 2012 17:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdfZ5PXBhk3A for ; Mon, 12 Nov 2012 17:05:23 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by ietfa.amsl.com (Postfix) with ESMTP id C572721F8476 for ; Mon, 12 Nov 2012 17:05:22 -0800 (PST) Received: from [127.0.0.1] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 8C32B1759F7; Tue, 13 Nov 2012 12:05:20 +1100 (EST) Message-ID: <50A19CA4.8000007@firstpr.com.au> Date: Tue, 13 Nov 2012 12:04:36 +1100 From: Robin Whittle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: RRG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: RJ Atkinson Subject: [rrg] ILNP: existing applications & other critiques X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 01:05:24 -0000 Hi Ran, In your "Updating hosts" message you wrote, in part: > Indeed, ILNP does update hosts, but does so with a > clearly documented "backwards compatibility" mechanism > and also a clearly documented "incremental deployment" > scheme. > > At least one ILNP prototype already has shown an *un-modified* > (i.e. no source code changes, no recompilation) FreeBSD ping6 > binary using ILNPv6 between a pair of ILNPv6-enabled hosts. > (NB: I'm aware of 2 independent implementations of ILNP > that are underway, one for Linux and one for FreeBSD.) > > This is a good initial step towards showing that ILNP > will enable existing "host applications" to be used with > ILNP -- without requiring application changes. In I tried to figure out how ILNP could work with existing applications, as it was claimed to do. The thread is: ILNP: stack behavior to work with IPv6 apps? 2010-07-13 http://www.ietf.org/mail-archive/web/rrg/current/thrd2.html#07108 Neither I nor anyone else was able to show how it could be done. Sections 10.4 to 10.6 of RFC6741 seem to be relevant: http://tools.ietf.org/html/rfc6741#section-10.5 Those applications that directly use IP Address values in application state or configuration will need to be modified for operation over ILNP. My guess is that this would involve most applications. This thread: Fwd: I-D Action:draft-irtf-rrg-recommendation-09.txt - ILNP problems http://www.ietf.org/mail-archive/web/rrg/current/thrd2.html#07185 2010-08-01 contains further critiques of ILNP including the need for an extra lookup (compared to the existing host protocols, DNS, IP addressing etc.) when the responding host needs to ensure its return packet will either go to the purported sending host (as represented by the initial packet, which might be from another host) or be dropped by the routing system if no such host exists. There was no rebuttal of these critiques, but one RRG participant agreed they were important. Also, I can't see how ILNP can adapt securely or rapidly enough to a host getting a new IP address to support 3G/4G/WiFi-style mobility of IP address, especially for voice applications. As far as I know, ILNP is only practical for IPv6. Despite a decade and a half of faith on the part of many IETF people and repeated "real soon now" statements about IPv6's imminent widespread adoption, I see no sign of it. If a 2012-11-07 statement by Nick Hilliard is to be believed: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-November/007374.html then excluding "the top 10% of the v6 talkers", IPv6 traffic volumes are an order of 1/100,000 of IPv4 traffic volumes. I think ILNP represents a logical approach to Locator Identifier Separation. (LISP, my Ivip and Fred Templin's IRON are not Locator Identifier Separation architectures - they are Core Edge Separation architectures.) If you accept the impossibility of rapid response to host mobility, the need for an extra lookup in the common circumstances I mentioned above, and reliance on the IPv6 Internet, I think it is a good approach. The existing BGP system could be retained and there would be no need to add prefixes to the DFZ for the purposes of multihoming or mobility. However I don't believe it can provide the host mobility we need - and it can't help at all with the IPv4 Internet which everyone uses now and for the foreseeable future. I think the IP-address-based host communications and DNS arrangements we have now are a good thing, in part because it means the recipient host doesn't have to muck around with costly and time-consuming lookups every time it replies to a packet in the many cases where that reply must go only to the host which is identified by the source IP address of the original packet. I believe that host mobility (for both IPv4 and IPv6) can be provided robustly with my TTR Mobility proposal, which is apparently used, in principle, by IRON for all communications and which could work well with LISP. http://www.firstpr.com.au/ip/ivip/#mobile - Robin From dykim6@gmail.com Mon Nov 12 17:21:55 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75BC21F87EA for ; Mon, 12 Nov 2012 17:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id She3Wq1CDMly for ; Mon, 12 Nov 2012 17:21:55 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id DD0E421F87E7 for ; Mon, 12 Nov 2012 17:21:54 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so3555069qcs.13 for ; Mon, 12 Nov 2012 17:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=DNheu2iCbbckTXCNjZMetX1d1NI8U2kgxY5OYctBph4=; b=JK0b7jcjADpGcZPRIE2xC8lsV3rBiF4wj/AxHRtfG60+j/X3ZtF06/CAAil+l3cEme YVMgrPsvvPyl9pHvoMwBJaNUfQK7gUdxnFavY5bzp95IR2dOWdNSSWs531dV9PcZdScU KYZSvB23J2lbn349gvEhnsYLqOr8SdPKv2RBsoSlycXSzj33MwYM9b4JrvBt43wtLMov XZl5JazalorXrMeC6ZQZb0jPtEHKXzbuYTcaqlWWYQmdd+S8tFdDzjd1lVcJWQBPlZlZ AR1bA+F5k2oS7FmgFomNWJBzTU6G4Vxe5zFrIC5TyH6NtGDSv3pO5OOU2Z8nyMx/CIys /pxw== Received: by 10.224.182.12 with SMTP id ca12mr22742058qab.73.1352769714335; Mon, 12 Nov 2012 17:21:54 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Mon, 12 Nov 2012 17:21:34 -0800 (PST) In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E0D8EAF@EUSAAMB109.ericsson.se> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E0D8EAF@EUSAAMB109.ericsson.se> From: Dae Young KIM Date: Tue, 13 Nov 2012 10:21:34 +0900 X-Google-Sender-Auth: O9UvosKEaIOGPii6i0wZXekb_yI Message-ID: To: Jakob Heitz Content-Type: multipart/alternative; boundary=20cf302ef98a492f8904ce563e72 Cc: "rrg@irtf.org" Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 01:21:55 -0000 --20cf302ef98a492f8904ce563e72 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 13, 2012 at 9:37 AM, Jakob Heitz wrote: > What explosion? > > http://ripe63.ripe.net/archives/video/178 > http://ripe63.ripe.net/presentations/61-2011-10-31-bgp2011.pdf > OK, the explosion may not be dreadful as we thought in 2006: - The IPv4 growth has rounded up. - The growth is now with IPv6. - The Moor's Law is still saving us. The RRG charter lists four focus items: scalability, mobility, multi-homing, and inter-domain traffic engineering. Then, according to your point, scalability is not an issue anymore...? How then has LIS improved multi-homing than the status quo? How significantly has LISP helped inter-domain traffic engineering? It might help mobility a bit, but as far as connection resilience is concerned, the same effect could have been met by a session layer; your session does not break at transient breakage of transport connections. I do take ILNP as one of the smartest LIS solution; no reservation. My question is rather why we've indulged in LIS if routing scalability were not an issue? -- DY --20cf302ef98a492f8904ce563e72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 9:37 AM, Jakob Heitz <jakob.heitz@ericsson= .com> wrote:
What explosion?

htt= p://ripe63.ripe.net/archives/video/178
http://ripe63.ripe.net/presentations/61-2011-10-31-bgp201= 1.pdf

OK, the explosion may not = be dreadful as we thought in 2006:

=A0 - The IPv4 growth has rounded up.
=A0 - The growth is now with = IPv6.
=A0 - The Moor's Law is still saving us.

The RRG charte= r lists four focus items: scalability, mobility, multi-homing, and inter-do= main traffic engineering.

Then, according to your point, scalability is not an issue anymore...?<= br>
How then has LIS improved multi-homing than the status quo? How sign= ificantly has LISP helped inter-domain traffic engineering?

It might= help mobility a bit, but as far as connection resilience is concerned, the= same effect could have been met by a session layer; your session does not = break at transient breakage of transport connections.

I do take ILNP as one of the smartest LIS solution; no reservation.
=
My question is rather why we've indulged in LIS if routing scalabil= ity were not an issue?

--
DY
--20cf302ef98a492f8904ce563e72-- From shane@castlepoint.net Mon Nov 12 17:54:25 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E207E21F8804 for ; Mon, 12 Nov 2012 17:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+QJG7bUTeYh for ; Mon, 12 Nov 2012 17:54:25 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2D27121F86EB for ; Mon, 12 Nov 2012 17:54:25 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 1B76A20DD for ; Tue, 13 Nov 2012 01:54:24 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 9B2BD20C7; Mon, 12 Nov 2012 18:54:18 -0700 (MST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D401B5DB-DD81-445A-8E99-E63B6FA6B03D" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Mon, 12 Nov 2012 18:54:16 -0700 Message-Id: <61783025-83F3-4D21-96DC-EB12AC899E05@castlepoint.net> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> To: Dae Young KIM X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Nov 12 18:54:24 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50a1a850199637872915013 X-DSPAM-Factors: 27, Subject*Re+#+#+#+hibernation, 0.01000, Subject*to+hibernation, 0.01000, 2012+at, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, at+#+#+PM, 0.01000, Subject*Re+rrg, 0.01000, Subject*Re+#+RRG, 0.01000, Subject*Re+#+#+to, 0.01000, Subject*rrg+#+#+hibernation, 0.01000, 2012+#+#+#+PM, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*rrg+#+to, 0.01000, Cc*rrg+irtf.org, 0.01000, Subject*RRG+to, 0.01000, Subject*RRG+#+hibernation, 0.01000, Subject*rrg+RRG, 0.01000, Nov+#+#+at, 0.01000, Nov+#+#+at, 0.01000, On+Nov, 0.01000, On+Nov, 0.01000, the+#+and, 0.01000, the+#+and, 0.01000, Nov+#+2012, 0.01000, Nov+#+2012, 0.01000, On+#+#+#+at, 0.01000, On+#+#+#+at, 0.01000 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 01:54:26 -0000 --Apple-Mail=_D401B5DB-DD81-445A-8E99-E63B6FA6B03D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dae, On Nov 12, 2012, at 5:12 PM, Dae Young KIM wrote: > Hi, Joel, >=20 > Perhaps a more direct question might serve here: >=20 > o How has ILNP solved the problem of the DFZ routing table = explosion? First, let me remind you that there *are* FIB aggregation techniques = that may work to squelch some of the most egregious deaggregation that = occurs out there. IMHO, the following are the most promising, but there = are others: http://tools.ietf.org/html/draft-uzmi-smalta-01 More work needs to be done, specifically trials in _production_networks_ = to qualify how good (or, bad) it really works. I've asked several = vendors to develop a prototype implementation of the above to test in my = network, but have yet to see any takers, unfortunately. (Someone please = prove me wrong :-). Also, more importantly, let me add that "DFZ routing table explosion" is = not the only concern that operators solely care about. Yes, it's an = important factor, but it's not the _sole_ factor. As I alluded to in a = previous e-mail just recently to this list, there are additional things = to care about: - inter-domain routing protocol robustness, i.e.: one malformed UPDATE = will not cause BGP session to reset - ensuring "routing security" is a first-class design principle - allowing for _additional_ routing metrics to be learned *and* used in = terms of path selection. Note, this is likely not a panacea, but most = likely (in the end) *may* provide "hints" to end-hosts as to "path = quality" so that they don't waste time hunting/exploring bad paths. - and, yes, scalability of the RIB/FIB So, let's not solely focus on one aspect of the problem-space, to the = detriment of other useful areas that need to get solved. -shane >=20 > On Tue, Nov 13, 2012 at 9:08 AM, Joel M. Halpern = wrote: > I do not see the difficulty. We already have the IPv6 mechanisms to = advertise the prefixes. And we have the IPv6 mechanisms for hosts to = combne the prefixes with teir IDs. > We also have the dynamic DNS mechanisms (with security) needed to = advertise the results. >=20 > With ILP, these combinations can be changed during sessions, and = traffic can change paths during sessions without impact. > With the current architecture, sessions can not change paths, and = changes to the connectivity are hard to discover or utilize. >=20 > Thee are other multi-homing problems that are not solved. Working out = how to manage prefix assignments in an enterprise when external = assignments change is one example of such issues (LISP takes a different = tack, and thus the costs and benefits are different.) >=20 > Yours, > Joel >=20 > --=20 > DY > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg --Apple-Mail=_D401B5DB-DD81-445A-8E99-E63B6FA6B03D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 dykim@cnu.kr> = wrote:
Hi, Joel,

Perhaps a more = direct question might serve here:

   o How has ILNP = solved the problem of the DFZ routing table = explosion?

First, let me remind you that there *are* FIB aggregation = techniques that may work to squelch some of the most egregious = deaggregation that occurs out there.  IMHO, the following are the = most promising, but there are others:
More work needs to be done, specifically trials in = _production_networks_ to qualify how good (or, bad) it really works. =  I've asked several vendors to develop a prototype implementation = of the above to test in my network, but have yet to see any takers, = unfortunately.  (Someone please prove me wrong :-).

Also, more importantly, let me add that "DFZ routing table = explosion" is not the only concern that operators solely care about. =  Yes, it's an important factor, but it's not the _sole_ factor. =  As I alluded to in a previous e-mail just recently to this list, = there are additional things to care about:
- inter-domain routing protocol robustness, i.e.: one = malformed UPDATE will not cause BGP session to reset
- ensuring "routing security" is a = first-class design principle
- and, yes, = scalability of the RIB/FIB
So, let's not solely = focus on one aspect of the problem-space, to the detriment of other = useful areas that need to get solved.




On Tue, Nov 13, 2012 at = 9:08 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
I do not see the = difficulty.  We already have the IPv6 mechanisms to advertise the = prefixes.  And we have the IPv6 mechanisms for hosts to combne the = prefixes with teir IDs.
We also have the dynamic DNS mechanisms (with security) needed to = advertise the results.

With ILP, these combinations can be changed during sessions, and traffic = can change paths during sessions without impact.
With the current architecture, sessions can not change paths, and = changes to the connectivity are hard to discover or utilize.

Thee are other multi-homing problems that are not solved.  Working = out how to manage prefix assignments in an enterprise when external = assignments change is one example of such issues (LISP takes a different = tack, and thus the costs and benefits are different.)

Yours,
Joel

--
DY
_______________________________________________
rrg mailing = list
rrg@irtf.org
http://www.irtf.org/mailm= an/listinfo/rrg

= --Apple-Mail=_D401B5DB-DD81-445A-8E99-E63B6FA6B03D-- From dykim6@gmail.com Mon Nov 12 18:11:55 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9515221F87CF for ; Mon, 12 Nov 2012 18:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ6usRgEEUwX for ; Mon, 12 Nov 2012 18:11:54 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8B61121F8753 for ; Mon, 12 Nov 2012 18:11:54 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so3576601qcs.13 for ; Mon, 12 Nov 2012 18:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=opn8uyRAvNbr99TDEImR/guXIt0dADcH6fmbL+XggJM=; b=VGRY6rKyEIEB/AAtchoQZ0IIElWTUrDRyxqo+A4zeMw+PHho8xhvHfYC4UslBq0Z6A bX4w2s0SbEOkkAb7AkGahHGCWVmwFDbQ5vH39+23NQW4/0NmnaHc0CpfBuKK6BZlI86v YEKd7Szog2IRCr7oyn61g2WIeIZirNooky3z7XAP9arig3eC0tPpDLLqgr9bTk9bl+Cl kL/1yHeCCCgBdkYlznKYb/NCJ/pvuhyhyTJh3H/ipQHx6RwCMbAIXrc6dGcRwHvfqZla fHftg99SGoiWBcL6174fPvqrgttz7eQGBMrkitKB5I1llSrI/VkA2HZO8DEiyE9dOJz8 4pBw== Received: by 10.229.196.195 with SMTP id eh3mr5396671qcb.82.1352772713965; Mon, 12 Nov 2012 18:11:53 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Mon, 12 Nov 2012 18:11:33 -0800 (PST) In-Reply-To: <61783025-83F3-4D21-96DC-EB12AC899E05@castlepoint.net> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <61783025-83F3-4D21-96DC-EB12AC899E05@castlepoint.net> From: Dae Young KIM Date: Tue, 13 Nov 2012 11:11:33 +0900 X-Google-Sender-Auth: BVDOOZtUIctSW7gS20Ess4md0CQ Message-ID: To: Shane Amante Content-Type: multipart/alternative; boundary=0016e6d2660813ea0d04ce56f1c7 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 02:11:55 -0000 --0016e6d2660813ea0d04ce56f1c7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 13, 2012 at 10:54 AM, Shane Amante wrote: > Dae, > > On Nov 12, 2012, at 5:12 PM, Dae Young KIM wrote: > > Hi, Joel, > > Perhaps a more direct question might serve here: > > o How has ILNP solved the problem of the DFZ routing table explosion? > > > First, let me remind you that there *are* FIB aggregation techniques that > may work to squelch some of the most egregious deaggregation that occurs > out there. IMHO, the following are the most promising, but there are > others: > http://tools.ietf.org/html/draft-uzmi-smalta-01 > More work needs to be done, specifically trials in _production_networks_ > to qualify how good (or, bad) it really works. I've asked several vendors > to develop a prototype implementation of the above to test in my network, > but have yet to see any takers, unfortunately. (Someone please prove me > wrong :-). > Good to know there are other ways to combat the problem. > > Also, more importantly, let me add that "DFZ routing table explosion" is > not the only concern that operators solely care about. Yes, it's an > important factor, but it's not the _sole_ factor. As I alluded to in a > previous e-mail just recently to this list, there are additional things to > care about: > - inter-domain routing protocol robustness, i.e.: one malformed UPDATE > will not cause BGP session to reset > - ensuring "routing security" is a first-class design principle > - allowing for _additional_ routing metrics to be learned *and* used in > terms of path selection. Note, this is likely not a panacea, but most > likely (in the end) *may* provide "hints" to end-hosts as to "path quality" > so that they don't waste time hunting/exploring bad paths. > - and, yes, scalability of the RIB/FIB > > So, let's not solely focus on one aspect of the problem-space, to the > detriment of other useful areas that need to get solved. > > -shane > Agreed. Then why did we indulge in LIS? Was it a consensus that LIS is the way to solve the 'other problems' that you mention above? I was trying to echo Noel's comment like 'what routing problems has INLP solved?' If the 'other problems' you mention were our major problem space, weren't there any other approaches than LIS? Any other more generic approach? If I'm not wrong, LIS was introduced to this community through the following arguments, out of the 2006 workshop: o Symptom: The DFZ routing table is exploding. o Primary Diagnosis: Incompetence in multihoming is the cause. o Secondary Diagnosis: Semantic overloading of IP address is responsible for multihoming incompetence. o Prescription: Apply LIS. So, if not for the problem of routing table explosion, why have we indulged in LIS? (As long as migration and mobility are degenerate cases of multihoming, the same arguments and the question apply to them, too.) Was LIS conceived fat beyond that quality from the beginning? An all-mighty to solve all routing problems? Then, what routing problems has it solved? -- DY --0016e6d2660813ea0d04ce56f1c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 10:54 AM, Shane Amante <shane@castlepoint.net<= /a>> wrote:
Dae,

Hi, Joel,

Perhaps a more direct question m= ight serve here:

=A0=A0 o How has ILNP solved the problem of the DFZ= routing table explosion?

First, let me remind you that there *are* FIB aggregation techniques that m= ay work to squelch some of the most egregious deaggregation that occurs out= there. =A0IMHO, the following are the most promising, but there are others= :
More work needs = to be done, specifically trials in _production_networks_ to qualify how goo= d (or, bad) it really works. =A0I've asked several vendors to develop a= prototype implementation of the above to test in my network, but have yet = to see any takers, unfortunately. =A0(Someone please prove me wrong :-).

Good to know there are other ways t= o combat the problem.

Also, more importantly, let me add that "DFZ routin= g table explosion" is not the only concern that operators solely care = about. =A0Yes, it's an important factor, but it's not the _sole_ fa= ctor. =A0As I alluded to in a previous e-mail just recently to this list, t= here are additional things to care about:
- inter-domain routing protocol robust= ness, i.e.: one malformed UPDATE will not cause BGP session to reset
<= div style=3D"font-family:monospace">- ensuring "routing security"= is a first-class design principle
- allowing for _additional_ routing me= trics to be learned *and* used in terms of path selection. =A0Note, this is= likely not a panacea, but most likely (in the end) *may* provide "hin= ts" to end-hosts as to "path quality" so that they don't= waste time hunting/exploring bad paths.
- and, yes, scalability of the RIB/FIB=

So, let's not solely focus on one aspect of the problem-= space, to the detriment of other useful areas that need to get solved.

-shane

Agreed.
Then why did we indulge in LIS? Was it a consensus that LIS is the way to s= olve the 'other problems' that you mention above?

I was trying to echo Noel's comment like 'what routing problems= has INLP solved?'

If the 'other problems' you mention w= ere our major problem space, weren't there any other approaches than LI= S? Any other more generic approach?

If I'm not wrong, LIS was introduced to this community through the = following arguments, out of the 2006 workshop:

=A0o Symptom: The DFZ= routing table is exploding.
=A0o Primary Diagnosis: Incompetence in mul= tihoming is the cause.
=A0o Secondary Diagnosis: Semantic overloading of IP address is responsible= for multihoming incompetence.
=A0o Prescription: Apply LIS.

So, = if not for the problem of routing table explosion, why have we indulged in = LIS?

(As long as migration and mobility are degenerate cases of multihoming,= the same arguments and the question apply to them, too.)

Was LIS co= nceived fat beyond that quality from the beginning? An all-mighty to solve = all routing problems? Then, what routing problems has it solved?

--
DY
--0016e6d2660813ea0d04ce56f1c7-- From shane@castlepoint.net Mon Nov 12 18:16:03 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E7121F8808 for ; Mon, 12 Nov 2012 18:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2njjf+e9MLW for ; Mon, 12 Nov 2012 18:16:02 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id A3E5021F85C0 for ; Mon, 12 Nov 2012 18:16:02 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 4A0C720DE for ; Tue, 13 Nov 2012 02:16:01 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 2C44920C7; Mon, 12 Nov 2012 19:15:59 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: <50A19CA4.8000007@firstpr.com.au> Date: Mon, 12 Nov 2012 19:15:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net> References: <50A19CA4.8000007@firstpr.com.au> To: Robin Whittle X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Nov 12 19:16:01 2012 X-DSPAM-Confidence: 0.9898 X-DSPAM-Improbability: 1 in 9709 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50a1ad61199631447464159 X-DSPAM-Factors: 27, 2012+at, 0.01000, at+#+#+PM, 0.01000, Subject*Re+rrg, 0.01000, that+#+#+to, 0.01000, the+#+of, 0.01000, the+#+of, 0.01000, 2012+#+#+#+PM, 0.01000, to+be, 0.01000, Cc*rrg+irtf.org, 0.01000, Nov+#+#+at, 0.01000, On+Nov, 0.01000, of+the, 0.01000, of+#+#+#+to, 0.01000, Nov+#+2012, 0.01000, On+#+#+#+at, 0.01000, On+#+#+2012, 0.01000, Url*83, 0.40000, IPv6+#+#+are, 0.40000, are+#+#+of, 0.40000, To*Robin+#+rw, 0.40000, IPv6's+imminent, 0.40000, 100+#+of, 0.40000, point+#+#+slide, 0.40000, volumes+Perhaps, 0.40000, for+#+#+#+decade, 0.40000, Nick+Hilliard, 0.40000, for+#+Despite, 0.40000 Cc: RRG , RJ Atkinson Subject: Re: [rrg] ILNP: existing applications & other critiques X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 02:16:03 -0000 Robin, On Nov 12, 2012, at 6:04 PM, Robin Whittle wrote: > As far as I know, ILNP is only practical for IPv6. Despite a decade = and > a half of faith on the part of many IETF people and repeated "real = soon > now" statements about IPv6's imminent widespread adoption, I see no = sign > of it. If a 2012-11-07 statement by Nick Hilliard is to be believed: >=20 >=20 > = https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-November/00= 7374.html >=20 >=20 > then excluding "the top 10% of the v6 talkers", IPv6 traffic volumes = are > an order of 1/100,000 of IPv4 traffic volumes. Perhaps you missed the following? = http://www.ietf.org/proceedings/83/slides/slides-83-iab-5-technical-plenar= y.pdf = http://www.extremetech.com/mobile/127213-ipv6-now-deployed-across-entire-t= -mobile-us-network = http://conference.apnic.net/__data/assets/pdf_file/0017/50813/vzw_apnic_13= 462152832-2.pdf In fact, I would point you to slide 13 + 14 of that PDF as to the = success of IPv6 traffic growth. = http://comcast6.net/index.php/8-ipv6-trial-news-and-information/92-deploym= ent-update Those are just a sampling of recent announcements/activity I can recall = recently. I'm sure if you looked around, you'd see similar activity by = other wireless networks and residential broadband providers. Admittedly, we're still quite a ways from when IPv6 traffic volume will = exceed IPv4 traffic growth. Regardless, it's illogical to (continue to) = assume that IPv6 is not being widely deployed in the real-world, right = now. -shane= From rw@firstpr.com.au Mon Nov 12 20:23:29 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D4821F8870 for ; Mon, 12 Nov 2012 20:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.111 X-Spam-Level: X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrVEflOcR0xu for ; Mon, 12 Nov 2012 20:23:29 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by ietfa.amsl.com (Postfix) with ESMTP id 0117521F83EF for ; Mon, 12 Nov 2012 20:23:28 -0800 (PST) Received: from [127.0.0.1] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 4BBFB1759F7; Tue, 13 Nov 2012 15:23:27 +1100 (EST) Message-ID: <50A1CB11.4050809@firstpr.com.au> Date: Tue, 13 Nov 2012 15:22:41 +1100 From: Robin Whittle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: RRG References: <50A19CA4.8000007@firstpr.com.au> <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net> In-Reply-To: <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: RJ Atkinson Subject: Re: [rrg] ILNP: existing applications & other critiques X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 04:23:30 -0000 Hi Shane, Thanks for these links. The Verizon Wireless slide 14 had no information on how the IPv6 traffic volume compared with that of IPv4. Maybe such information was implied in slide 13 but I couldn't clearly understand it. Comcast stated that "approximately 6% of the 2012 Olympics served over YouTube to Comcast customers was over IPv6." This is a substantial share of real ordinary user traffic. I wonder what the impetus for this was - why didn't the hosts use IPv4? There will always be IPv4 space available for servers - unless the world needs a billion or more servers with unique IP addresses, which is not the case with many websites sharing a single IP address. That being the case, as long as mobile devices can be made to work acceptably well behind IPv4 NAT (maybe this is not the case, but for the foreseeable future, a unicast IPv6 address is no substitute for a unicast or NATed IPv4 address), it is hard for me to imagine a commercially compelling reason for anyone making services available on IPv6. If there had been such reasons, there wouldn't be a need for campaigns to improve IPv6 network availability and end-user adoption. A still more remote development would be anyone making services available only on IPv6, or in some way better on IPv6 than on IPv4. That, or the impossibility of mobile and home/office customers being happy with NATed service, seems to be a pre-requisite for widespread adoption of IPv6 by end-users who don't run servers - except for one scenario: The development of some popular applications which require true host-to-host communications, especially for mobile devices, which can't be done with one or the other host behind NAT. Then, this would be an impetus for giving such customers (too many customers to accommodate on their own IPv4 addresses) native IPv6, so each device, or each of the user's multiple devices, has its own public unicast IP address. Such applications are most likely to be intensive real-time end-user-host to end-user-host communications such as voice, video or gaming. With most new developments happening in physically mobile devices, such applications would need to work smoothly with one or both devices suddenly getting a whole new /64 and therefore a new IP address. This could happen when the device transitions from one base-station to another (if the base-stations and their controllers have different IP gateways) - which can happen without the device physically moving at all. It could also happen as the device comes into range of one or more 3G/4G/WiFi services come into range - and the ranges can fluctuate without the device moving. As far as I know, only TTR mobility can provide this - and it doesn't require any changes to host stacks or applications (other than the addition of a TTR tunnelling module alongside or as part of the stack). LISP or ILNP would not be able to maintain connectivity in a sufficiently responsive manner to support any real-time application. Unless each application handled these mobility problems on its own, I can't imagine this scenario developing with the current addressing and routing arrangements, with or without ILNP or LISP. That's the limit of my current imagination and understanding. - Robin From shane@castlepoint.net Mon Nov 12 20:44:17 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A4E21F88A0 for ; Mon, 12 Nov 2012 20:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.029 X-Spam-Level: X-Spam-Status: No, score=0.029 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMnQUYjPjsao for ; Mon, 12 Nov 2012 20:44:17 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0CA21F87DF for ; Mon, 12 Nov 2012 20:44:17 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 1EC0020E3 for ; Tue, 13 Nov 2012 04:44:16 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 454C3CD; Mon, 12 Nov 2012 21:44:15 -0700 (MST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: <50A1CB11.4050809@firstpr.com.au> Date: Mon, 12 Nov 2012 21:44:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78553EF9-D0D4-4914-89CC-E9CC1F435FDB@castlepoint.net> References: <50A19CA4.8000007@firstpr.com.au> <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net> <50A1CB11.4050809@firstpr.com.au> To: Robin Whittle X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Nov 12 21:44:16 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50a1d020199635765521236 X-DSPAM-Factors: 27, Mime-Version*OS+X, 0.01000, From*Amante+shane, 0.01000, 2012+at, 0.01000, Mime-Version*Mail+#+1499, 0.01000, at+#+#+PM, 0.01000, Mime-Version*6.2+1499, 0.01000, Subject*Re+rrg, 0.01000, Mime-Version*OS+#+#+#+1499, 0.01000, Mime-Version*X+#+6.2, 0.01000, Mime-Version*1.0+Mac, 0.01000, Mime-Version*Mail+6.2, 0.01000, From*Shane+#+shane, 0.01000, From*Shane Amante , 0.01000, Mime-Version*Mac+#+#+#+6.2, 0.01000, From*Amante+#+castlepoint.net, 0.01000, Mime-Version*Mac+OS, 0.01000, Mime-Version*1.0+#+OS, 0.01000, Mime-Version*X+Mail, 0.01000, Mime-Version*1.0+#+#+X, 0.01000, 2012+#+#+#+PM, 0.01000, From*shane+castlepoint.net, 0.01000, From*Shane+#+#+castlepoint.net, 0.01000, Mime-Version*1.0+#+#+#+Mail, 0.01000, Mime-Version*Mac+#+X, 0.01000, Cc*rrg+irtf.org, 0.01000, Nov+#+#+at, 0.01000, On+Nov, 0.01000 Cc: RRG RG Subject: Re: [rrg] ILNP: existing applications & other critiques X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 04:44:17 -0000 Robin, On Nov 12, 2012, at 9:22 PM, Robin Whittle wrote: > Hi Shane, >=20 > Thanks for these links. The Verizon Wireless slide 14 had no > information on how the IPv6 traffic volume compared with that of IPv4. > Maybe such information was implied in slide 13 but I couldn't clearly > understand it. No operators share traffic volume statistics publicly, for competitive = reasons. I work as an operator, I should know. :-) > Comcast stated that "approximately 6% of the 2012 Olympics served over > YouTube to Comcast customers was over IPv6." This is a substantial > share of real ordinary user traffic. I wonder what the impetus for = this > was - why didn't the hosts use IPv4? Ask Comcast? But, if I were to guess, I would suspect that = implementation of "Happy Eyeballs" = in client Operating = Systems (Mac OS X) and browsers (i.e.: Chrome, Firefox, etc.) *slightly* = favors IPv6 transport compared to IPv4 transport during DNS resolution = and connection set-up. Viola: more v6 traffic than v4. -shane= From swmike@swm.pp.se Mon Nov 12 21:29:37 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3A821F88B2 for ; Mon, 12 Nov 2012 21:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DldMwvkwhOad for ; Mon, 12 Nov 2012 21:29:36 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 405BA21F88B1 for ; Mon, 12 Nov 2012 21:29:35 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 260769C; Tue, 13 Nov 2012 06:29:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1FA2F9A; Tue, 13 Nov 2012 06:29:31 +0100 (CET) Date: Tue, 13 Nov 2012 06:29:31 +0100 (CET) From: Mikael Abrahamsson To: Robin Whittle In-Reply-To: <50A19CA4.8000007@firstpr.com.au> Message-ID: References: <50A19CA4.8000007@firstpr.com.au> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: RRG , RJ Atkinson Subject: Re: [rrg] ILNP: existing applications & other critiques X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 05:29:37 -0000 On Tue, 13 Nov 2012, Robin Whittle wrote: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-November/007374.html > > then excluding "the top 10% of the v6 talkers", IPv6 traffic volumes are > an order of 1/100,000 of IPv4 traffic volumes. Yes, that is the current state of affairs. However, IPv6 is happening. There is no other plan, people are looking into NAT44, NAT444 or equivalent, to bridge the gap until IPv6 is supported on enough edge devices, so we then can go dual stacked (basically add IPv6 to the beforementioned IPv4 infrastructure), and then phase out IPv4 over time. People have stopped saying "if" and started asking "how" and "when". This is a good sign. It tooks us more than 10 years to get here. Anything being discussed right now should look 10 years into the future and see itself influensing the future, but rely on IPv6 in the current incarnation being the basic infrastructure. We already have multiple IPv4 mobility protocols. 3GPP style tunneling is one (I've seen it being re-invented to handle large enterprise Wifi networks, at least in the presentations it looks almost identical). It's my strong opinion that anything that wants to get deployed in the real world needs to be "compatible" with the basic IPv6 infrastructure as seen today, and overlay on it somehow. It can be host-style like SHIM6, it can be tunneling, it can be anything, but I firmly believe the core routers need to stay the way they are right now when it comes to destination based forwarding with the help of BGP. The possibility to do rapid adoption of new tech on L3 is over. Anything from now on needs to be able to get incrementally implemented using IPv6. IPv4 is carrying the bulk of real life traffic but IPv6 is where everybody is going, that's at least what I see from the operational world. So for designing for the 3+ year future, IPv6 is what it needs to handle. Stop beating the dying IPv4 horse, it's done a great job but it's being replaced and from a design point of view, designing with IPv6 as a requirement is a sane assumption. -- Mikael Abrahamsson email: swmike@swm.pp.se From rw@firstpr.com.au Mon Nov 12 21:49:30 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E01021F8430 for ; Mon, 12 Nov 2012 21:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=1.003, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR7is2hV1KpR for ; Mon, 12 Nov 2012 21:49:29 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by ietfa.amsl.com (Postfix) with ESMTP id 76DD821F841C for ; Mon, 12 Nov 2012 21:49:29 -0800 (PST) Received: from [127.0.0.1] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id C0657175A02; Tue, 13 Nov 2012 16:49:26 +1100 (EST) Message-ID: <50A1DF3F.6020801@firstpr.com.au> Date: Tue, 13 Nov 2012 16:48:47 +1100 From: Robin Whittle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: RRG References: <50A19CA4.8000007@firstpr.com.au> <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net> <50A1CB11.4050809@firstpr.com.au> <78553EF9-D0D4-4914-89CC-E9CC1F435FDB@castlepoint.net> In-Reply-To: <78553EF9-D0D4-4914-89CC-E9CC1F435FDB@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rrg] Happy Eyeballs RFC6555: app changes so dual-stack IPv4/6 is usable X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 05:49:30 -0000 Hi Shane, Thanks very much for your Happy Eyeballs answer in the "Re: [rrg] ILNP: existing applications & other critiques" thread to my question about why people watching the Olympics on a Comcast HFC network would sometimes have their browser, player or whatever access the videos via IPv6 servers: http://en.wikipedia.org/wiki/Happy_Eyeballs http://tools.ietf.org/html/rfc6555 April 2012 If the IPv4 connection is behind NAT, including with the NAT box in the provider network, and if the individual hosts have their own public unicast IPv6 addresses, then this can reduce the traffic through the IPv4 NAT box. The algorithm is designed to generally favor IPv6, with the long-term intention of reducing the use of IPv4. "... the client sends two TCP SYNs at the same time over IPv6 and IPv4." If an ACK is received for both, the client selects whether to use IPv4 or IPv6, and caches this for 10 minutes. "The simplest venue for the implementation of Happy Eyeballs is within the application itself." It seems that applications need to be altered, by the addition of a Happy Eyeballs algorithm, to provide reliable performance when the dual-stack host is connected to both IPv4 and IPv6. This is unfortunate, but not surprising - since these are two separate Internets. - Robin From shane@castlepoint.net Mon Nov 12 22:11:36 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDAB21F88C6 for ; Mon, 12 Nov 2012 22:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcWFgUdwDwyJ for ; Mon, 12 Nov 2012 22:11:35 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 44B8221F88C1 for ; Mon, 12 Nov 2012 22:11:27 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 71FA920E2 for ; Tue, 13 Nov 2012 06:11:26 +0000 (UTC) Received: from [172.16.15.40] (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id F18066F1; Mon, 12 Nov 2012 23:11:25 -0700 (MST) References: <50A19CA4.8000007@firstpr.com.au> <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net> <50A1CB11.4050809@firstpr.com.au> <78553EF9-D0D4-4914-89CC-E9CC1F435FDB@castlepoint.net> <50A1DF3F.6020801@firstpr.com.au> Mime-Version: 1.0 (1.0) In-Reply-To: <50A1DF3F.6020801@firstpr.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <05AD8FE9-B1D1-4694-9F69-61260B0FC1DA@castlepoint.net> X-Mailer: iPad Mail (10A523) From: Shane Amante Date: Mon, 12 Nov 2012 23:11:23 -0700 To: Robin Whittle X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Nov 12 23:11:26 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50a1e48e199638145918272 X-DSPAM-Factors: 27, From*Amante+shane, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, 12+#+at, 0.01000, Nov+12, 0.01000, that+#+#+to, 0.01000, From*Shane+#+shane, 0.01000, the+#+#+#+the, 0.01000, the+#+#+#+the, 0.01000, the+#+of, 0.01000, the+#+of, 0.01000, in+the, 0.01000, in+the, 0.01000, From*Shane Amante , 0.01000, From*Amante+#+castlepoint.net, 0.01000, 2012+#+#+#+PM, 0.01000, From*shane+castlepoint.net, 0.01000, This+is, 0.01000, to+be, 0.01000, From*Shane+#+#+castlepoint.net, 0.01000, Cc*rrg+irtf.org, 0.01000, 12+2012, 0.01000, Url*http, 0.01000, Url*http, 0.01000, Nov+#+#+at, 0.01000 Cc: RRG Subject: Re: [rrg] Happy Eyeballs RFC6555: app changes so dual-stack IPv4/6 is usable X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 06:11:36 -0000 On Nov 12, 2012, at 10:48 PM, Robin Whittle wrote: > Hi Shane, >=20 > Thanks very much for your Happy Eyeballs answer in the "Re: [rrg] ILNP: > existing applications & other critiques" thread to my question about why > people watching the Olympics on a Comcast HFC network would sometimes > have their browser, player or whatever access the videos via IPv6 servers:= >=20 > http://en.wikipedia.org/wiki/Happy_Eyeballs > http://tools.ietf.org/html/rfc6555 April 2012 >=20 > If the IPv4 connection is behind NAT, including with the NAT box in the > provider network, and if the individual hosts have their own public > unicast IPv6 addresses, then this can reduce the traffic through the > IPv4 NAT box. The algorithm is designed to generally favor IPv6, with > the long-term intention of reducing the use of IPv4. >=20 > "... the client sends two TCP SYNs at the same time over IPv6 and > IPv4." >=20 > If an ACK is received for both, the client selects whether to use IPv4 > or IPv6, and caches this for 10 minutes. >=20 > "The simplest venue for the implementation of Happy Eyeballs is > within the application itself." >=20 > It seems that applications need to be altered, by the addition of a > Happy Eyeballs algorithm, to provide reliable performance when the > dual-stack host is connected to both IPv4 and IPv6. This is > unfortunate, but not surprising - since these are two separate Internets. No. Note that Mac OS X _operating_system_ implements a form of Happy Eyebal= ls. Thus, there is no need for apps on top of OS X to implement it. IMO, th= e only reason apps such as Firefox & Chrome have implemented Happy Eyeballs i= s because Windows does not implement Happy Eyeballs, so the apps vendors wer= e forced to work around it. This illustrates the fundamental conundrum we're facing. Apps vendors are ma= king up for the deficiencies of the underlying operating system network stac= ks. If we give the O/S vendors something to latch on to, then it makes ever= yone's lives improved. -shane >=20 > - Robin >=20 >=20 From tony.li@tony.li Mon Nov 12 22:27:39 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF78A21F88D1 for ; Mon, 12 Nov 2012 22:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlEd0tCtrQl8 for ; Mon, 12 Nov 2012 22:27:39 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 2880F21F88CF for ; Mon, 12 Nov 2012 22:27:39 -0800 (PST) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta03.emeryville.ca.mail.comcast.net with comcast id NtjA1k0030lTkoCA3uTfv3; Tue, 13 Nov 2012 06:27:39 +0000 Received: from sjc-vpn6-539.cisco.com ([128.107.239.233]) by omta04.emeryville.ca.mail.comcast.net with comcast id NuRN1k00152qHCY8QuRQEN; Tue, 13 Nov 2012 06:25:37 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E0D8EAF@EUSAAMB109.ericsson.se> Date: Mon, 12 Nov 2012 22:25:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <39E70C32-C616-4A2B-8A1D-DCC0E582B111@tony.li> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E0D8EAF@EUSAAMB109.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1499) Cc: "rrg@irtf.org" Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 06:27:39 -0000 On Nov 12, 2012, at 4:37 PM, Jakob Heitz = wrote: > What explosion? >=20 > http://ripe63.ripe.net/archives/video/178 > http://ripe63.ripe.net/presentations/61-2011-10-31-bgp2011.pdf a) Explosion is an inflammatory choice of words. It's a growth rate = problem. b) This presentation that you cite is again misguided as it simply = assumes that everything can grow at the rate of Moore's law with = constant cost. Moore's law does NOT apply to the data plane portion of = core routers. These are NOT commodity parts. =20 c) The presentation also misses out on the fact that a more significant = issue is DRAM speeds. These don't keep up with table growth either, so = growth turns into a convergence hit. Regards, Tony p.s. We are reiterating the exact same discussion that we've had for the = last 8 years. Is there a point to this? From tony.li@tony.li Mon Nov 12 22:28:56 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6C721F88DC for ; Mon, 12 Nov 2012 22:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iRxJwOmO-ky for ; Mon, 12 Nov 2012 22:28:56 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8D221F88D5 for ; Mon, 12 Nov 2012 22:28:56 -0800 (PST) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta02.emeryville.ca.mail.comcast.net with comcast id NuTT1k0061smiN4A2uUwRa; Tue, 13 Nov 2012 06:28:56 +0000 Received: from sjc-vpn6-539.cisco.com ([128.107.239.233]) by omta20.emeryville.ca.mail.comcast.net with comcast id NuSg1k00h52qHCY8guSjoR; Tue, 13 Nov 2012 06:26:54 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Mon, 12 Nov 2012 22:26:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> To: Dae Young KIM X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 06:28:56 -0000 On Nov 12, 2012, at 4:52 PM, Dae Young KIM wrote: >=20 > Simple: one of the contributors to the explosion is the drive for PI = prefixes. This is driven by sites that choose to be multi-homed and = want failover semantics that BGP can provide. >=20 > With ILNP, a site can get this semantics with multiple PA prefixes. > Isn't the description the same with the current IP Internet? Can't the = current Internet do the same? Any change?=20 No. Today if you have a set of PA prefixes and your address changes = from one to another, your TCP connections all break. Tony From rw@firstpr.com.au Mon Nov 12 23:34:52 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B6321F88CB for ; Mon, 12 Nov 2012 23:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.226 X-Spam-Level: X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON-3bUtEMjaG for ; Mon, 12 Nov 2012 23:34:51 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by ietfa.amsl.com (Postfix) with ESMTP id 38FAE21F888E for ; Mon, 12 Nov 2012 23:34:46 -0800 (PST) Received: from [127.0.0.1] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 788A0175A93; Tue, 13 Nov 2012 18:34:44 +1100 (EST) Message-ID: <50A1F7CF.2080402@firstpr.com.au> Date: Tue, 13 Nov 2012 18:33:35 +1100 From: Robin Whittle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: RRG References: <50A19CA4.8000007@firstpr.com.au> <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net> <50A1CB11.4050809@firstpr.com.au> <78553EF9-D0D4-4914-89CC-E9CC1F435FDB@castlepoint.net> <50A1DF3F.6020801@firstpr.com.au> <05AD8FE9-B1D1-4694-9F69-61260B0FC1DA@castlepoint.net> In-Reply-To: <05AD8FE9-B1D1-4694-9F69-61260B0FC1DA@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [rrg] Happy Eyeballs RFC6555: app changes so dual-stack IPv4/6 is usable X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 07:34:52 -0000 Short version: Discussing the implementation of Happy Eyeballs or something similar to it in the operating system, rather than in the application. Hi Shane, You wrote: >> It seems that applications need to be altered, by the addition of a >> Happy Eyeballs algorithm, to provide reliable performance when the >> dual-stack host is connected to both IPv4 and IPv6. This is >> unfortunate, but not surprising - since these are two separate Internets. > No. Note that Mac OS X _operating_system_ implements a form of Happy > Eyeballs. Thus, there is no need for apps on top of OS X to implement > it. IMO, the only reason apps such as Firefox & Chrome have > implemented Happy Eyeballs is because Windows does not implement > Happy Eyeballs, so the apps vendors were forced to work around it. > > This illustrates the fundamental conundrum we're facing. Apps > vendors are making up for the deficiencies of the underlying > operating system network stacks. If we give the O/S vendors something > to latch on to, then it makes everyone's lives improved. Maybe it is difficult or perhaps impossible to implement Happy Eyeballs or the like in the OS in a manner which never causes problems, no matter the nature of the application. The example algorithm in section 6 of RFC 6555 involves sending a SYN to the IPv6 address (assuming the address policy for the host prefers IPv6, which I understand is typically the case for a dual-stack OS), waiting 300ms and then sending a SYN to the IPv4 address if there was no response in that time. From Australia, and especially on a 3G/4G mobile link, 300ms is a rather short time in which to expect a response from servers in most of the world. Assuming the IPv6 address does produce an ACK which arrives later than 300ms, then the host is sending out two SYNs instead of one, and likely receiving two SYNs too. This is something of an extra burden on a 3G/4G link. Though Happy Eyeballs is documented for TCP, the Wikipedia page mentions it being used to choose between TCP and SCTP. I don't think it could work with UDP, since there is no SYN/ACK arrangement. A Happy Eyeballs-like algorithm could be implemented for UDP with the involvement of the server, but this would have to be at the application level. Perhaps this means that dual-stack problems it is intended to solve can't be solved for UDP-based protocols without suitable application changes for the client and server. This article from 2011-11-12 may not reflect the current behavior of the "Happy Eyeballs" algorithm (it is actually a different algorithm) in OS-X: https://labs.ripe.net/Members/emileaben/hampered-eyeballs however it does mention how it works, or worked, and some problems which arose, presumably with applications which use the traditional getaddrinfo() call, rather than another methods which are apparently unique to OS-X. "It looks like OS X Lion makes debugging connectivity issues to dual-stacked websites a royal pain, with the associated cost for support staff. While the Mac OS X Lion + Safari combination looks to be a true "Happy Eyeballs" implementation, the combination of OS X Lion with anything that just uses getaddrinfo() does not make the eyeballs much happier it seems." "If the way Mac OS X implemented 'Happy Eyeballs'-like functionality becomes more widespread (please don't do this Microsoft!) it will cause perfectly fine dual-stack hosts with roughly equal performance over both protocols, to select the legacy IPv4 protocol in roughly half of the cases. This makes the IPv6 capacity in networks under-used and that is bad for a few reasons: This page reports on problems with OS-X 10.7 (Lion) in April this year. http://shibboleth.net/pipermail/dev/2012-April/000651.html >From 2012-08-10 more reports of trouble with OS-X and particular browsers - Safari and Firefox: http://www.jumpertz.net/1/post/2012/11/going-cross-eyed-with-happy-eyeballs.html A 2012-09-11 Cisco presentation doesn't mention any difficulties: http://www.data.proidea.org.pl/euronog/2edycja/materials/Krzysztof_Mazepa-IPv4_vs_IPv6-Happy_Eyeballs.pdf Geoff Huston and George Michaelson (2012-04-16) mention various items of interest to these questions and mention problems with the OS-X implementation. https://ripe64.ripe.net/presentations/78-2012-04-16-ripe64.pdf This is not a proper survey of the field. I am just suggesting that it may not be straightforward to implement the Happy Eyeballs algorithm in the OS, especially considering that various apps may access the OS in different ways, may be doing their own version of Happy Eyeballs etc. and that the OS approach might upset some assumptions made in higher level protocols. - Robin From huitema@huitema.net Mon Nov 12 23:49:49 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FEB21F88D1 for ; Mon, 12 Nov 2012 23:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7XWLP64st53 for ; Mon, 12 Nov 2012 23:49:48 -0800 (PST) Received: from xsmtp03.mail2web.com (xsmtp03.mail2web.com [168.144.250.223]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD4921F88B8 for ; Mon, 12 Nov 2012 23:49:48 -0800 (PST) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1TYBFh-0005oz-T6 for rrg@irtf.org; Tue, 13 Nov 2012 02:49:47 -0500 Received: (qmail 18457 invoked from network); 13 Nov 2012 07:49:44 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.18.205.153]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Nov 2012 07:49:43 -0000 From: "Christian Huitema" To: "'Tony Li'" , "'Dae Young KIM'" References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> In-Reply-To: <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> Date: Mon, 12 Nov 2012 23:49:41 -0800 Message-ID: <09cc01cdc173$71323cd0$5396b670$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKmaqimcuMIEaDS4+m+D6OTBfD6uwEJqFf5AlYTT+gB3vf1+gMMZiYcAUxrLhkCUOa8uJXWzBUQ Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 07:49:49 -0000 > No. Today if you have a set of PA prefixes and your address changes from one > to another, your TCP connections all break. That's true, has been for quite some time, and yet nobody seems to be doing much about it. Which makes you wonder how big of a problem that is in practice. If applications were really hurting, you would hear complaints from application developers. But you don't. The applications that need reliable long duration sessions incorporate some trivial checkpoint and restart mechanism, or some pretty elaborate consistency protocols for big databases. They probably would do that no matter what the reliability of TCP, as long as it is not "perfect." And PA renumbering is probably not very high in their list of "stuff that occasionally break TCP." -- Christian Huitema From tony.li@tony.li Tue Nov 13 00:23:26 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3B921F88FB for ; Tue, 13 Nov 2012 00:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XR9RNf6Eltm0 for ; Tue, 13 Nov 2012 00:23:26 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD9121F88F7 for ; Tue, 13 Nov 2012 00:23:26 -0800 (PST) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta01.emeryville.ca.mail.comcast.net with comcast id NwHy1k00K16AWCUA1wPSAa; Tue, 13 Nov 2012 08:23:26 +0000 Received: from sjc-vpn6-539.cisco.com ([128.107.239.233]) by omta06.emeryville.ca.mail.comcast.net with comcast id NwMB1k00452qHCY8SwMDYL; Tue, 13 Nov 2012 08:21:24 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <09cc01cdc173$71323cd0$5396b670$@huitema.net> Date: Tue, 13 Nov 2012 00:21:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <03E5ABD7-EA3C-4C69-B3F9-16C8B6C6E512@tony.li> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:23:26 -0000 On Nov 12, 2012, at 11:49 PM, Christian Huitema = wrote: >> No. Today if you have a set of PA prefixes and your address changes = from > one >> to another, your TCP connections all break. >=20 > That's true, has been for quite some time, and yet nobody seems to be = doing > much about it. Which makes you wonder how big of a problem that is in > practice. If applications were really hurting, you would hear = complaints > from application developers. But you don't. The applications that need > reliable long duration sessions incorporate some trivial checkpoint = and > restart mechanism, or some pretty elaborate consistency protocols for = big > databases. They probably would do that no matter what the reliability = of > TCP, as long as it is not "perfect." And PA renumbering is probably = not very > high in their list of "stuff that occasionally break TCP." They don't do PA renumbering. They do PI instead. Clearly checkpoint = and restart are not sufficient, otherwise they could do PA easily. Again, this has been discussed endlessly already. Tony From dykim6@gmail.com Tue Nov 13 00:26:03 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9467621F8895 for ; Tue, 13 Nov 2012 00:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGUO4jno+6ea for ; Tue, 13 Nov 2012 00:26:02 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id BC0CB21F8857 for ; Tue, 13 Nov 2012 00:26:02 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id t11so2304022qaa.13 for ; Tue, 13 Nov 2012 00:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=rzL3WpkiCOiBCX4jr6oMeED9TLEqPTsolkC0KG7r40o=; b=Thqr6ZAiHonEyGTqTBiErz0yiyWE99kzjsNbCyafkoGvdpZKttMDqHaSb0U7CBYYDt z/XT01FQTlHdReb+JkLwNqIU/gYjPgUU8qRBv/azKHqF3Yb4tjeFdj7tFcTLvo8XQt68 DZYgwasTdXmasePOsXqn40OvgpFl+yqfNcRVb0i9TfZrsWBHXWdIG9oGRCKjdnBqUsWR HgGqoEj4InxUUfkdNf7xltZzvSOn9Qczm8yynWIKsrBspSQ7mbTOi+Uy1aTaXzyDMVPx /5w5x4NbV/DFuQUmAMZhotHFXzKQtERJuZRCdPSxsexLqVrpPqV7Z/rAfVgej4o6Xt8Z HYWg== Received: by 10.229.196.195 with SMTP id eh3mr5468669qcb.82.1352795162220; Tue, 13 Nov 2012 00:26:02 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 13 Nov 2012 00:25:42 -0800 (PST) In-Reply-To: <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> From: Dae Young KIM Date: Tue, 13 Nov 2012 17:25:42 +0900 X-Google-Sender-Auth: f28Dsfo3AM8b2jWxzaTpxGFsECQ Message-ID: To: Tony Li Content-Type: multipart/alternative; boundary=0016e6d266081919f704ce5c2be5 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:26:03 -0000 --0016e6d266081919f704ce5c2be5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 13, 2012 at 3:26 PM, Tony Li wrote: > > No. Today if you have a set of PA prefixes and your address changes from > one to another, your TCP connections all break. > OK, if that's all you care. On one hand, having each hosts in a site deal with multiple PA prefixes won't be much fun. On the other, the same connection resilience could be achieved with some sort of session management function on top of TCP, without resorting to LIS. You've got good reason to believe in LIS. That's fine. I'm still doubting whether LIS is the right answer to seamless multihoming. It's only my problem, perhaps, not yours. -- DY --0016e6d266081919f704ce5c2be5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 3:26 PM, Tony Li <tony.li@tony.li> wro= te:

No. =A0Today if you have a set of PA prefixes and your address change= s from one to another, your TCP connections all break.

OK, if that's all you care.

On one hand, having each hosts = in a site deal with multiple PA prefixes won't be much fun.

On the other, the same connection resilience could be achieved with som= e sort of session management function on top of TCP, without resorting to L= IS.

You've got good reason to believe in LIS. That's fine.
I'm still doubting whether LIS is the right answer to seamless mult= ihoming. It's only my problem, perhaps, not yours.


--
DY
--0016e6d266081919f704ce5c2be5-- From tony.li@tony.li Tue Nov 13 00:39:33 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D10721F84F6 for ; Tue, 13 Nov 2012 00:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grIp8+1O+9Gq for ; Tue, 13 Nov 2012 00:39:33 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id EFF7121F84EB for ; Tue, 13 Nov 2012 00:39:32 -0800 (PST) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta01.emeryville.ca.mail.comcast.net with comcast id NwbQ1k0090S2fkCA1wfY5z; Tue, 13 Nov 2012 08:39:32 +0000 Received: from sjc-vpn6-539.cisco.com ([128.107.239.233]) by omta09.emeryville.ca.mail.comcast.net with comcast id NwdK1k00G52qHCY8VwdNX2; Tue, 13 Nov 2012 08:37:30 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Tue, 13 Nov 2012 00:37:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> To: Dae Young KIM X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:39:33 -0000 > On one hand, having each hosts in a site deal with multiple PA = prefixes won't be much fun. Fortunately, only the network administrator HAS to deal with the = multiple prefixes, setting up one per provider. After that, everything = within the network can be automated. > On the other, the same connection resilience could be achieved with = some sort of session management function on top of TCP, without = resorting to LIS. Absolutely true. But then it might require application changes, which = we'd like to avoid. It would also not be intrinsic in the architecture. > I'm still doubting whether LIS is the right answer to seamless = multihoming. It's only my problem, perhaps, not yours. Doubts are healthy, and we learn more by doing. Tony From dykim6@gmail.com Tue Nov 13 00:45:51 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1C021F8488 for ; Tue, 13 Nov 2012 00:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbT-2yf+zyEw for ; Tue, 13 Nov 2012 00:45:47 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFC721F8470 for ; Tue, 13 Nov 2012 00:45:47 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so3726905qcs.13 for ; Tue, 13 Nov 2012 00:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=mcQSi/ihHEYqfDd69GATZIuTljFpCAHrvpGIgh8GQ+Q=; b=js7XSqpkr90Pp5yV8/k+KHy9Fq4wWgN1tcfZ3Oa/M9HoYVhfrv+lQp8gQAPAoac+cB FXiisTSTxLXbNSWqfYbF8Srp8R99DmrF5a6AV7nFoZPoLxY8uJZi5ed7Gb8g8pXqKE6Y C/SYOJ9sdE2VfMcZDSzI37/blwsEze6frhsOM3R6B2ucIWid1deEJwP5XJ9T/reMAH2n yyYlwetx8kr0TfWVor/hLgaToFKrfBrEVaUwh760Jm1kKWjZsNekcLiGhNEjPS4Rwa6A yUORncVteFvrjL6ViyMA8UT0reZXCX3iQdwxvTbbuj5oQzo7We/+xwcte0w3ShXfo94k KpHw== Received: by 10.49.117.137 with SMTP id ke9mr27009703qeb.5.1352796347148; Tue, 13 Nov 2012 00:45:47 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 13 Nov 2012 00:45:26 -0800 (PST) In-Reply-To: References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> From: Dae Young KIM Date: Tue, 13 Nov 2012 17:45:26 +0900 X-Google-Sender-Auth: YdiJUNRGIcl9Vr7oCcv_ifgfOAw Message-ID: To: Tony Li Content-Type: multipart/alternative; boundary=047d7b66efdfb9aa9504ce5c71c9 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:45:52 -0000 --047d7b66efdfb9aa9504ce5c71c9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 13, 2012 at 5:37 PM, Tony Li wrote: > > > On one hand, having each hosts in a site deal with multiple PA prefixes > won't be much fun. > > > Fortunately, only the network administrator HAS to deal with the multiple > prefixes, setting up one per provider. After that, everything within the > network can be automated. > Does this mean renumbering? > > > > On the other, the same connection resilience could be achieved with some > sort of session management function on top of TCP, without resorting to LIS. > > > Absolutely true. But then it might require application changes, which > we'd like to avoid. It would also not be intrinsic in the architecture. > Which architecture? And no application change with ILNP? I thought there'd be application changes with ILNP, although none with the routers. Apps should take only the half of the IPv6 address as host ID, not the whole. -- DY --047d7b66efdfb9aa9504ce5c71c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 5:37 PM, Tony Li <tony.li@tony.li> wro= te:

> On one hand, having each hosts in a site deal with multiple PA prefixe= s won't be much fun.


Fortunately, only the network administrator HAS to deal with the mult= iple prefixes, setting up one per provider. =A0After that, everything withi= n the network can be automated.

Does this mean ren= umbering?


> On the other, the same connection resilience could be achieved with so= me sort of session management function on top of TCP, without resorting to = LIS.


Absolutely true. =A0But then it might require application changes, wh= ich we'd like to avoid. =A0It would also not be intrinsic in the archit= ecture.

Which architecture?

And no applicat= ion change with ILNP? I thought there'd be application changes with ILN= P, although none with the routers. Apps should take only the half of the IP= v6 address as host ID, not the whole.

--
DY
--047d7b66efdfb9aa9504ce5c71c9-- From dykim6@gmail.com Tue Nov 13 00:53:16 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3C021F860D for ; Tue, 13 Nov 2012 00:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S41J9q8Zepzj for ; Tue, 13 Nov 2012 00:53:15 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 170C621F85EB for ; Tue, 13 Nov 2012 00:53:13 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id g24so565418qab.13 for ; Tue, 13 Nov 2012 00:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=hII88pP9Nwhr/VCpoz55/rytdGwUvl115eoy92U4uKA=; b=h8SMHdCaTz259+uJ2y84wK6qWiBnlVQrLR+pV3Wu6qu6lbhNMcSI5BYfSvFpguqy5Y GZG+48/d0Fy6Y4FGJP8mXiepgx5jDsCO3iOOJkyGOqLs0/4a5nEjUQTa/ybOmQ43t8rd oFrLtW+zr+3tktkMXfrgy/pYH6AssQPWu7se8FmwJUT5GxBzOJleioeqwwU7HybaeKOb 8SA171JG2IaBdIno9mUkhzbSCt2qu02KEHRqymb8yfIMVdqeO1DTkR9tAI6lnIR4UbRq yAXY95sfM+GgKxqnv01RSLq5g6v40AzG37FrQ+OhJdx9hnatbnZYCePb4ask2rzfwYbK Y2tg== Received: by 10.229.198.217 with SMTP id ep25mr3258861qcb.59.1352796792127; Tue, 13 Nov 2012 00:53:12 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 13 Nov 2012 00:52:51 -0800 (PST) In-Reply-To: References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> From: Dae Young KIM Date: Tue, 13 Nov 2012 17:52:51 +0900 X-Google-Sender-Auth: r0Bk3GqMb9kHtOUnlsIcyXktyJ8 Message-ID: To: Tony Li Content-Type: multipart/alternative; boundary=005045015bad3f7ff204ce5c8cc2 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:53:16 -0000 --005045015bad3f7ff204ce5c8cc2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 13, 2012 at 5:45 PM, Dae Young KIM wrote: > > > On the other, the same connection resilience could be achieved with some >> sort of session management function on top of TCP, without resorting to LIS. >> >> >> Absolutely true. But then it might require application changes, which >> we'd like to avoid. >> > > And no application change with ILNP? I thought there'd be application > changes with ILNP, although none with the routers. Apps should take only > the half of the IPv6 address as host ID, not the whole. > I'm mistaken. Perhaps, no change with ILNP; rather TCP has to be changed. The pain would be the same if a shim session layer would be inserted on top of TCP with having the socket interface look the same to APPs...? -- DY --005045015bad3f7ff204ce5c8cc2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 5:45 PM, Dae Young KIM <dykim@cnu.kr> wro= te:

> On the other, the same connection resilience could be achieved with so= me sort of session management function on top of TCP, without resorting to = LIS.


Absolutely true. =A0But then it might require application changes, wh= ich we'd like to avoid.

And no applicati= on change with ILNP? I thought there'd be application changes with ILNP= , although none with the routers. Apps should take only the half of the IPv= 6 address as host ID, not the whole.

I'm mistaken. Perhaps, no change with ILNP;= rather TCP has to be changed.

The pain would be the same if a shim = session layer would be inserted on top of TCP with having the socket interf= ace look the same to APPs...?

--
DY
--005045015bad3f7ff204ce5c8cc2-- From pfrejborg@gmail.com Tue Nov 13 02:06:55 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72821F8676 for ; Tue, 13 Nov 2012 02:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsE58UfUL4jm for ; Tue, 13 Nov 2012 02:06:54 -0800 (PST) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0191D21F861B for ; Tue, 13 Nov 2012 02:06:53 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id wz12so260161pbc.13 for ; Tue, 13 Nov 2012 02:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gq04eJdqFw3WjFcq8vOq7a62UCcuCHreZEciZYaaHD8=; b=kPvn+PVb1KypE/7Sl5uvDV26Foa3YXxW2VNY5ZF3driBkEN/itVj975by2dvqVc/i2 qXEmI9ZdfrTX/whRGF8sXrjxhXkPjO8owXBm6bBxUQisJtrtf7u9I2kaB44knT8R+1EG YlSSrtS2EcKgx6JxoVu5ptcZyHpoJmy0553mkH02hFDFOkzZHosBq/G+dYe1F+/Vy6c8 CUyTXZf2yAgY87mn8pyU6fLpkEdJpzv+h4ObbHZStb49XmiOu8Br5lven5nVsnr+Crl9 9Zgq4CBqhmMM9wX9knNXz3Q18kqxw4DZYRA+J4spoNgSo0AXQvT5UxAJEKmzy/m9o42W WA4A== MIME-Version: 1.0 Received: by 10.66.80.65 with SMTP id p1mr56770080pax.20.1352801211743; Tue, 13 Nov 2012 02:06:51 -0800 (PST) Received: by 10.66.218.37 with HTTP; Tue, 13 Nov 2012 02:06:51 -0800 (PST) In-Reply-To: <09cc01cdc173$71323cd0$5396b670$@huitema.net> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> Date: Tue, 13 Nov 2012 12:06:51 +0200 Message-ID: From: Patrick Frejborg To: Christian Huitema Content-Type: text/plain; charset=ISO-8859-1 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 10:06:55 -0000 On Tue, Nov 13, 2012 at 9:49 AM, Christian Huitema wrote: >> No. Today if you have a set of PA prefixes and your address changes from > one >> to another, your TCP connections all break. > > That's true, has been for quite some time, and yet nobody seems to be doing > much about it. Which makes you wonder how big of a problem that is in > practice. If applications were really hurting, you would hear complaints > from application developers. But you don't. The applications that need > reliable long duration sessions incorporate some trivial checkpoint and > restart mechanism, or some pretty elaborate consistency protocols for big > databases. They probably would do that no matter what the reliability of > TCP, as long as it is not "perfect." And PA renumbering is probably not very > high in their list of "stuff that occasionally break TCP." > Outcome is that the networking people have to build larger L2 DC networks so that applications don't break when a VM is moved between locations - now the DC networks are becoming so large that we need another layer (NVO3) to extend the VLAN range of the already very large L2 DC networks. Life would be so much easier to move a session from one VM to another VM, with the help of a session identifier - instead the packets are encaped with new headers on the "wire" and not at the hosts where the encap/decap of the session layer should occur without changes for the applications. Of course, some application will suffer; if all applications are preserved as such then there is no true separation between identifiers and locators because some of the applications make use of the overload of Loc/ID (also transport protocol needs to evolve in order to make multi-homing more convenient). However, it is a nice starting point to apply the encap of a new header at the wire but it shouldn't be the final goal, the goal should be to have a stack containing a session layer. Switching topic: Danny and Shane had some thoughts about BGP, perhaps there is room for improvement on inter-domain routing. I agree there might some unfinished topics for us, found an interesting paper on how BGP might be improved. http://www.cs.princeton.edu/~jrex/papers/multipath06.pdf Patrick From swb@internet2.edu Tue Nov 13 05:28:33 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339D021F8558 for ; Tue, 13 Nov 2012 05:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUCBfZhOk-Vn for ; Tue, 13 Nov 2012 05:28:32 -0800 (PST) Received: from int-proxy02.merit.edu (int-proxy02.merit.edu [207.75.116.231]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE3921F853C for ; Tue, 13 Nov 2012 05:28:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy02.merit.edu (Postfix) with ESMTP id 6EEDC120615; Tue, 13 Nov 2012 08:28:29 -0500 (EST) X-Virus-Scanned: amavisd-new at int-proxy02.merit.edu Received: from int-proxy02.merit.edu ([127.0.0.1]) by localhost (int-proxy02.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCOB6Cg50b8x; Tue, 13 Nov 2012 08:28:29 -0500 (EST) Received: from swbi2mbp.local (unknown [64.55.78.101]) by int-proxy02.merit.edu (Postfix) with ESMTPSA id DF2FA120614; Tue, 13 Nov 2012 08:28:28 -0500 (EST) Message-ID: <50A24AFC.40408@internet2.edu> Date: Tue, 13 Nov 2012 13:28:28 +0000 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dae Young KIM References: <20121112160254.ECDBD18C0C3@mercury.lcs.mit.edu> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 13:28:33 -0000 I suggest we declare the RRG list officially open and have a meeting in Orlando. From wesley.george@twcable.com Tue Nov 13 06:09:54 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E37621F865D for ; Tue, 13 Nov 2012 06:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+JNMckQPVxt for ; Tue, 13 Nov 2012 06:09:50 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 545EB21F866E for ; Tue, 13 Nov 2012 06:09:47 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="450703001" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Nov 2012 09:08:45 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 13 Nov 2012 09:09:00 -0500 From: "George, Wes" To: Shane Amante , "rrg@irtf.org" Date: Tue, 13 Nov 2012 09:09:04 -0500 Thread-Topic: routing security and scale impacts (was RRG to hibernation) Thread-Index: Ac3BqG0PHF1lNolqQzimUAvSs94DxA== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033725314C@PRVPEXVS15.corp.twcable.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 Subject: [rrg] routing security and scale impacts (was RRG to hibernation) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 14:09:54 -0000 Changing subject line to reflect topic Shane has articulated a number of concerns that I think would be useful for= RRG to spend some time working on, and I tend to agree with Danny that the= current BGPSec solution seems to be more about "hacking at the edges" to g= et something that is marginally better in some ways than the [lack of] secu= rity that we have now, potentially ignoring the known scaling problems this= group has discussed at length all the while doing several things likely to= exacerbate them. It gives me concern about whether it will see significant= deployment due to the large amount of required investment vs the potential= benefit. I know I have asked more than once about the scaling implications= of BGPSec since it potentially makes a large impact in the footprint of th= e routing data that must be stored and managed, and haven't exactly been pl= eased with the answers even though some analysis has been done to show that= it's not a bad thing. If I were to distill things down, today we have a growth curve for both the= routing table (both RIB and FIB) and for cost-effective hardware with the = horsepower necessary to manage it (CPU, ASIC, memory, etc). SIDR is likely = not the one thing that will break the routing system by causing those curve= s to cross, but it certainly changes the curves' pitch such that it's more = likely that the cost of keeping up with the demands of the system starts be= coming unmanageable, even if it doesn't actually reach the limits of the te= chnology. The investment in a network for scale and growth is incremental, = and SIDR's full justification is that those incremental upgrades will bring= hardware that can support its needs organically. However, things like BGPS= ec or other disturbances that increase the growth curve of the routing tabl= e and related scaling vectors mean that as an operator, I have to shorten m= y upgrade cycle, spend capital earlier than originally projected, possibly = even to the point where I can't manage an entire depreciation cycle (5-7 ye= ars) before needing to spend additional money on upgrades. In a network tha= t is driven by commoditization of prices, that's not a good position to be = in. Additionally, as Shane alluded to in another message, this isn't simply abo= ut DFZ scale, but also internal scale, where there are commonly a *LOT* mor= e routes being carried by your average router inside an ISP's network. Ther= e are also other considerations like the rate of updates due to background = churn vs during an event, other things that the control plane must manage s= imultaneously, etc. Taking a step even further away from where RRG has been= previously focused, there is a similar sort of scaling problem within the = L3VPN space that is typically self-contained within the SP's network. While= I think there are some engineering solutions that may help with the short-= term scaling issues, there may also be some meat for research in the area o= f modeling and instrumentation of the routing system to give SP's better to= ols to use their available capacity efficiently, and possibly even changes = to help the routing control plane degrade more gracefully and deterministic= ally. The L3VPN discussion is detailed in draft-gs-vpn-scaling-01 (an -02 r= ev is due soon, waiting on co-author review and a few more updates), specif= ically in section 6 and 6.5 for the modeling/instrumentation, and in sectio= ns 4 and 5 for ways that the control plane tends to break down at scale lim= its. Thanks, Wes George > -----Original Message----- > From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of > Shane Amante > Sent: Saturday, November 10, 2012 8:39 PM > To: rrg@irtf.org > Subject: Re: [rrg] RRG to hibernation > > > On Nov 10, 2012, at 10:35 AM, Danny McPherson wrote: > > On Nov 10, 2012, at 12:24 PM, Tony Li wrote: > [--snip--] > >> I agree that some security needs to be deployed. I'm not convinced > that it needs to be BGPSEC. We've muddled along for many years and > never found the gumption to actually deploy anything. Must not be > important to people. I don't get it, but that's the observable > behavior. > >> > >> In any case, this doesn't seem like a research topic. This is pretty > clearly an engineering issue. > > > > I don't agree. The engineering solution that SIDR is actively working > (RPKI-enabled BGPSEC) is pumping out standards track RFCs like there's > no tomorrow. The USG has stated intentions of "expediting secure > routing work through the Internet standard process" and "fostering > adoption through government procurement vehicles". > > > > As an operator this scares the hell out of me, especially considering > what they've designed is largely a system to control "what's routed on > the Internet and by whom". They can't seem to do anything in BGP(SEC) > without introducing the equivalent of "periodic updates", and undoing > all the goodness of things like update packing completely. > > > > Some serious thinkers working on this problem would be goodness... > > Let me add that I share Danny's concerns ... > > However, let me try to take a step back and share with everyone a much > broader set of, potentially, architectural concerns that I'm not sure > this RG considered during the last round. > > BGP was originally designed for flooding of reachability information. > But, reachability information is the end-result /after/ the application > of _routing_policy_, describing "intent", by operators of individual > networks based on various contractual agreements they have with parties > whom they directly interconnect. Assuming you agree with this premise, > this presents a paradox from a security PoV. Specifically, if a > downstream network does not have visibility into its upstream network's > routing policy is it practical/feasible for the downstream network to > understand the _intended_ propagation of reachability information and, > ultimately, connectivity? Furthermore, is it feasible to carry such > information within the control plane itself? Or, should the control > plane be relegated to carrying [strictly] reachability information in > real-time, while offboard systems carry accompanying routing policy and > security information in order to assist in making "optimal" Inter-Domain > rou ting/forwarding decisions? > > A second concern is also related to the original design of BGP and what > it has organically involved into, today. Specifically, BGP is /also/ > now being tasked as a generic "message bus" and service discovery > mechanism. Not to pick on anyone, in particular, but the following are > recent examples that come to my mind wrt this trend: > http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-01 > http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 > ... and, there may be others. Although, contrast those proposals with > what should be most concerning to people in this RG, and in the IETF: > http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error- > handling-05 > In short, operators (such as myself) are _extremely_ concerned that a > single erroneous update results in a complete reset of BGP sessions. > Due to the overwhelming success of BGP, it's now (and, has been for a > while) a mission-critical protocol, thus such catastrophic session > resets -- caused by a single malformed UPDATE -- are widely > visible/impactful. This impact is compounded by the 'cost to recover'. > Namely, due to the large and growing amount of information in the RIB > (again, not just reachability, but also service-discovery and completely > orthogonal information), it takes longer to exchange RIB information > and, ultimately, restore services. Is this really the best we, as an > industry, can do? > > While the IETF IDR WG has been looking at mechanisms for how BGP may > defend against certain types of erroneous BGP UPDATE's for external BGP > sessions: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 > ... there does not appear to be any [straightforward] answer with > respect to internal BGP sessions, given the requirement that BGP > speakers internal to an AS must have a globally consistent RIB and FIB, > otherwise packet forwarding loops will result. And, in my personal > operational experience it's _rarely_ the case that malformed UPDATE's > are detected at the first ASBR (attached to an eBGP neighbor) in my AS, > thus it concerns me that mechanisms such as draft-ietf-idr-error- > handling-02 are an adequate solution to the problems we experience. > IOW, as an operator I desire "defense in depth" where a heterogeneous > mix of vendor equipment (HW + SW), participating as interior BGP > speakers, have mechanisms to detect *and* automatically recover from > malformed UDPATE's received over iBGP sessions. This is another area > that I would point research colleagues toward. > > So, this raises the classic conundrum of: increasing complexity, > increasing RIB (and FIB) size information coupled with a contrasting > need from operators who are concerned about the robustness of the > protocol and the requirement to NOT sustain any failures[1]. > Something's got to give. > > Ultimately, this makes me question whether it's no longer _just_ growth > of RIB (and, FIB) size that this RG should be (primarily?) focused on. > Rather, will the requirements for: > a) operational robustness, in the face of critical messaging errors in > an Inter-Domain Routing Protocol, which the IETF may be unable to > address on its own; > b) designing security as a first-class principle of an Inter-Domain > Routing Protocol -- either carried within or outside of control-plane > reachability information > c) increased scalability of RIB (and, other?) information ... lead us > down a path of considering we may be approaching the end-of-the-road for > BGPv4 and we need something new? > > Does anyone on this list share similar concerns wrt operational > robustness, time to recovery and (then) scalability of BGPv4? > > -shane > > [1] It is not cool to suggest that operators should just stop asking for > new features and we wouldn't have this problem. :) > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From tony.li@tony.li Tue Nov 13 07:44:18 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1EF21F86F8 for ; Tue, 13 Nov 2012 07:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWB59rxJJ+pi for ; Tue, 13 Nov 2012 07:44:17 -0800 (PST) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 7F80721F86F7 for ; Tue, 13 Nov 2012 07:44:13 -0800 (PST) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta07.emeryville.ca.mail.comcast.net with comcast id P2Ht1k0030QkzPwA73kCCG; Tue, 13 Nov 2012 15:44:12 +0000 Received: from sjc-vpn6-539.cisco.com ([128.107.239.233]) by omta02.emeryville.ca.mail.comcast.net with comcast id P3hx1k00M52qHCY8N3i0Df; Tue, 13 Nov 2012 15:42:10 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Tue, 13 Nov 2012 07:41:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> To: Dae Young KIM X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:44:18 -0000 On Nov 13, 2012, at 12:45 AM, Dae Young KIM wrote: >=20 > Fortunately, only the network administrator HAS to deal with the = multiple prefixes, setting up one per provider. After that, everything = within the network can be automated. >=20 > Does this mean renumbering?=20 Yes, for the end host, the assignment of locators can become automatic. Tony From pesherb@yahoo.com Tue Nov 13 07:45:57 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B6C21F85FE for ; Tue, 13 Nov 2012 07:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4w+PLBZEK4T for ; Tue, 13 Nov 2012 07:45:53 -0800 (PST) Received: from nm23.bullet.mail.bf1.yahoo.com (nm23.bullet.mail.bf1.yahoo.com [98.139.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6DB21F85E1 for ; Tue, 13 Nov 2012 07:45:50 -0800 (PST) Received: from [98.139.215.143] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2012 15:45:45 -0000 Received: from [98.139.212.200] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2012 15:45:45 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 13 Nov 2012 15:45:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 736344.22966.bm@omp1009.mail.bf1.yahoo.com Received: (qmail 51639 invoked by uid 60001); 13 Nov 2012 15:45:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352821545; bh=Lj4rkjhK7lN54XF96u8gzYkyIyrHmkugVJutZP/GPA0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NkPIaj3eVIi2PX9uQl/cIrK4zn+LQwtCLNMoZulwS40Mla3JCT1ck5JwHRMjQi8JTn/afxkVTXw5i14fzzrUTSrV/RjoUSjNzWk0CxgiA+qhPs7D9XKADgKzCB9n2YmYw5552fXL7WwpwmgtH8UcC0uoO8gq4KLlXiQanHRdu3s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=y76yLcXxrfpZkDKFzxFVgtrU+3ghxcDFgBL2gOYEw8lr5sxNq3rEWHW0+Ungzh6jQrsNrlgfeusGGSJQ0i0BqW/gZ5Px+20+Tt9SVcDFclT9Zb8u4f/N6vowJHTFYF6iWOhUrRzQvBPtjTLqGU5pHbZUV9N2DvqUZktsd5RW5pc=; X-YMail-OSG: 2fVezecVM1nW7Vcay_Oo.RAASYSajYcweuxIPXvvdoxRPjr FvrXO2j__CmJ4ifHRq_8Zb.UBv6dJh5C.KPS83hpba5mE1IcKATwyBYJOI5T xWTe0Y8JjAAw37d3iy63i5IH5dNomAhUG9VOFtg13gpVdleti8hmLK1Yx11z YJNe3z87HEI5P6ZRWW4XEP4jUgEbHmJRRZKR_lt8w5aY99K3B.qT5vJf18xk Aij1q9TCXuBzqxaIN.gv5PotWdsS3AjSyncplChUJpuyWxTS7Gn8wdhem7Yx 7vz0u0wtvzi0rZAxv72pypWz8rnloWeWGW.KbDmd2tsalAYokrBfsrpGbmZU 34iWQkdLHgmqXO4EPiIR8Qt95Ef2cppfbn1fmzQBONxyPAy5G.3uzdf1umsI y.tAJO5X6oEXlr9YfkAXmjE6FFGVzTd5ve8dfsWCN1ple.Iid.r_coMnzMpK 9UzjFJ_3g1_bVhFKiJMqRhkMvSFrxhuzaFTl9bG7GcvQcxL4aSVJV8yncGL2 0tXpHZ7KEdirYMoYT3zpTTvuewRbL40_6xFBs_NKTB11NhC7xRRjIDME- Received: from [169.132.18.1] by web160906.mail.bf1.yahoo.com via HTTP; Tue, 13 Nov 2012 07:45:45 PST X-Rocket-MIMEInfo: 001.001, Cgo.IFRoZSByZXNlYXJjaCB3ZSd2ZSBkb25lIHdhbnRzIHRvIGxlYWQgdXMgaW4gYSBkaXJlY3Rpb24gd2hlcmUgdGhlIGhvc3TCoGFkZHJlc3MgaXNuJ3Qgc3RhYmxlLgoKCnlvdSBtYXkgd2FudCB0byBjaGVjayBoZXJlwqBodHRwOi8vcmluYS50c3NnLm9yZwrCoApUaGFuayB5b3UsCgoKUGV0ZXIKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogV2lsbGlhbSBIZXJyaW4gPGJpbGxAaGVycmluLnVzPgpUbzogTm9lbCBDaGlhcHBhIDxqbmNAbWVyY3VyeS5sY3MubWl0LmVkdT4gCkMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.123.460 References: Message-ID: <1352821545.10345.YahooMailNeo@web160906.mail.bf1.yahoo.com> Date: Tue, 13 Nov 2012 07:45:45 -0800 (PST) From: P S To: William Herrin , Noel Chiappa In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="967773369-1500433957-1352821545=:10345" Cc: "rrg@irtf.org" Subject: Re: [rrg] Rerouting by readdressing X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: P S List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:45:57 -0000 --967773369-1500433957-1352821545=:10345 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A> The research we've done wants to lead us in a direction where the h= ost=A0address isn't stable.=0A=0A=0Ayou may want to check here=A0http://rin= a.tssg.org=0A=A0=0AThank you,=0A=0A=0APeter=0A=0A=0A_______________________= _________=0A From: William Herrin =0ATo: Noel Chiappa =0ACc: rrg@irtf.org =0ASent: Monday, November 12, 2012= 6:30 PM=0ASubject: [rrg] Rerouting by readdressing=0A =0AOn Sun, Nov 11, 2= 012 at 8:55 PM, Noel Chiappa wrote:=0A>=A0 =A0 >= From: William Herrin =0A>=0A>=A0 =A0 > I have a notion fo= r a "routing" protocol=0A>=0A> I'm glad you put the 'routing' in quotations= , because to me, 'routing' is i)=0A> the _selection of paths_, and ii) the = distribution of the information needed=0A> to select paths.=0A=0AHi Noel,= =0A=0AWell, I figure: we've been trying for 20 years to come up with a BGP= =0Areplacement that scales. In that time we've discovered that:=0A=0A1. Alg= orithmically determining the netmask instead of passing it as a=0Aseparate = datum is a bad idea.=0A=0A2. Building layer 4 protocols with a static depen= dence on the layer 3=0Aaddress requires any network that isn't part of a pe= rfect heirarchy to=0Ablast destination knowledge to every other network tha= t isn't a strict=0Ahierarchy.=0A=0A3. Because the FIB has distinctly differ= ent outputs than the RIB, its=0Apossible to aggregate it where it wasn't po= ssible to aggregate the=0ARIB.=0A=0A4. Disaggregation =3D bad.=0A=0AIf all = of that is correct, and it does seem to be, then maybe there=0Ajust aren't = any good answers to be found within the "box" bounded by=0ATCP's need to ha= ve a stable IP address. So, lets set that box aside=0Afor a while and think= about what routing might look like without it.=0AWhat can we do if we don'= t care whether the endpoint has a stable=0Alayer-3 address so long as it ha= s some layer-3 address at any given=0Atime?=0A=0A=0A> I'm not sure what def= inition other people are using, but it might be useful=0A> to come up with = a standard one to prevent confusion.=0A=0AAt its most abstract, the routing= process figures out how to get=0Apackets from A to B via C. Everything at = a finer level of detail is=0Asubject to detail-level rules. Some of them ca= n be bent. Others can be=0Abroken.=0A=0A=0A>=A0 =A0 > which manages link c= hanges through dynamic re-addressing and multiply=0A>=A0 =A0 > addressing = hosts. By and large the addresses change so that the=0A>=A0 =A0 > triviall= y aggregable routes don't have to. Not just at the host level=0A>=A0 =A0 >= but all the way downstream from the link change.=0A>=0A> If I understand y= ou properly, this is a way of dealing with topology changes=0A> by re-numbe= ring things? (To use the definition of 'routing' above, you=0A> wouldn't ne= ed to propogate new information, because the old data would still=0A> be va= lid - it's just that the things the old information would apply to have=0A>= changed?)=0A=0AThat's the gist of it, yeah. Any given node has three types= of links:=0Acoreward, hostward and sideward.=0A=0AA coreward link is one f= rom which this node accepts a block of=0Aaddresses tied to a "default route= ." Not necessarily 0/0. 2000::/3 is=0Aa default route.=0A=0AA hostward link= is one on which this node offers blocks of addresses=0Atied to a default r= oute and the neighboring node has accepted=0Aassignment of those addresses.= =0A=0AA sideward link is one on which an offer of addresses has been made= =0Abut rejected by the neighbor as it already has a satisfactory coreward= =0Apath, yet this node has also rejected the neighbors offer of=0Aaddresses= .=0A=0AEach address block you hold (and you don't hold many) is tied to a= =0Asingle coreward path which immediately aggregates into a larger block=0A= of addresses held by your coreward neighbor. If any element of the=0Acorewa= rd path fails, you send a message hostward instructing every=0Arouter and h= ost in that direction that the address block is no longer=0Avalid.=0A=0AFro= m your hostward neighbor, you'll receive a notification that the=0Aassigned= address block has reached its utilization high water mark. If=0Ayou have e= nough addresses, you'll assign it a new bigger block and=0Atell it to sched= ule release of the existing block in 300 seconds. And=0Ain 300 seconds you = send another message hostward declaring the old=0Ablock invalid.=0A=0AIf yo= u need more addresses to fulfill the request, you send a message=0Acoreward= indicating that you've reached your high water mark and need=0Aa bigger ad= dress block.=0A=0ASame process when your hostward neighbor advises that his= address=0Autilization has reached his low water mark.=0A=0ASideward you se= nd disaggregated routes which create shortcuts through=0Athe network so it = need not operate as a strict heirarchy. But these=0Aroutes are needed only = for efficiency, not connectedness. They can be=0Adiscarded at any distance = without harm.=0A=0AIt's probably even practical to implement a short-term t= unneled=0Areroute via a formerly sideward now coreward link so that you can= =0Arelease the old addresses gracefully after a link failure.=0A=0A=0A=0A> = I need to go away and think about this for a while before I can have some= =0A> really solid reaction, but off the top of my head I wonder if the work= =0A> involved in keeping up with the changing addresses isn't as much (or p= ossibly=0A> more) work than the usual approach. TANSTAAFL, after all...=0A= =0AOverall, it's more work for a certainty. In terms of the maximum work=0A= required for any particular node, my SWAG puts it far smaller than it=0Ais = now. And it seems to exhibit negligible growth with the number of=0Alinks a= nd nodes in the network -- more than a couple hops away you're=0Adealing wi= th a single aggregate regardless.=0A=0A>=A0 =A0 > Even bumps automatic res= izing requirements upstream so that over time=0A>=A0 =A0 > any given route= r offers exactly one route outward which automatically=0A>=A0 =A0 > aggreg= ates with the route its upstream already holds.=0A>=0A> Err, routing (in th= e sense given at the top) is trivial when there's only one=0A> path ("its u= pstream"). It's finding/selecting paths in arbitrary graphs with=0A> lots o= f alternate paths (i.e. ones with lots of 'cycles', to use the=0A> graph-th= eory term) which is the hard case.=0A=0AWe have excellent solutions for the= hard case provided the graph-like=0Acomponent to the network contains a su= fficiently small number of=0Aprefixes. If we can find a solution for a suff= iciently large portion=0Aof the network which looks as much like a heirarch= y as a graph, and=0Athat solution plays nicely with the purely graphy parts= , then=0Apragmatically speaking the scalability problem is solved.=0A=0A=0A= >=A0 =A0 > It does require a new suite of transport protocols=0A>=A0 =A0 = > ...=0A>=A0 =A0 > the odds of ever reaching deployment on an approach whi= ch requires us=0A>=A0 =A0 > to abandon TCP and UDP are not good?=0A>=0A> T= hat's infeasible; you can't require changing all hosts. You need to see if= =0A> you can come up with some approach that avoids that.=0A>=0A> (E.g. if = we have location-identity separatation deployed, you could hide the=0A> new= locators from the hosts.)=0A=0APerhaps. But maybe it's worth setting aside= that question long enough=0Ato determine whether an internally consistent = technical solution can=0Abe built at all.=0A=0AA transport protocol which d= oesn't require a stable address should=0Awork equally well on a network whi= ch does provide one and on a network=0Awhich does not. Maybe that's the way= in.=0A=0A=0A>> Are you game to flesh it out and see how far we can run wit= h it=0A>=0A> Right at the moment, I personally don't have any spare time/en= ergy.=0A=0AWell, lack of spare time/energy is a problem. But if there's onl= y time=0Ato consider ideas within the box bounded by a TCP-required stable = host=0Aaddress then it hardly seems fair to criticize the research process= =0Afor not finding anything new or insightful.=0A=0A=0A> But you=0A> should= think about it (and try and write something); even if it's not usable=0A> = directly, there might be some aspects that could be useful to other designs= .=0A=0AAs it happens, I've spent a few dozens of hours pondering it. But it= 's=0Aonly so much fun to play with one's self and my participation here is= =0Anot paid (hire me please!)=0A=0AThe research we've done wants to lead us= in a direction where the host=0Aaddress isn't stable. I respectfully sugge= st we follow and see what=0Athere is to be seen.=0A=0ARegards,=0ABill Herri= n=0A=0A=0A-- =0AWilliam D. Herrin ................ herrin@dirtside.com=A0 b= ill@herrin.us=0A3005 Crane Dr. ...................... Web: =0AFalls Church, VA 22042-3004=0A__________________________________= _____________=0Arrg mailing list=0Arrg@irtf.org=0Ahttp://www.irtf.org/mailm= an/listinfo/rrg --967773369-1500433957-1352821545=:10345 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

<= /span>
> The research we'v= e done wants to lead us in a direction where the host address isn't stable.

you may w= ant to check here http://rina.tssg.org
 
Thank y= ou,

Peter
From: William Herrin <bill@herrin.us>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
= Cc: rrg@irtf.org
Sent: Monday, November 12, 2012 6= :30 PM
Subject: [rrg] = Rerouting by readdressing

=0AOn Sun, Nov 11, 2012 at= 8:55 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote= :
>    > From: William Herrin <bill@herrin.us>
&g= t;
>    > I have a notion for a "routing" protocol
&= gt;
> I'm glad you put the 'routing' in quotations, because to me, 'r= outing' is i)
> the _selection of paths_, and ii) the distribution of= the information needed
> to select paths.

Hi Noel,

Wel= l, I figure: we've been trying for 20 years to come up with a BGP
replac= ement that scales. In that time we've discovered that:

1. Algorithmi= cally determining the netmask instead of passing it as a
separate datum = is a bad idea.

2. Building layer 4 protocols with a static dependenc= e on the layer 3
address requires any network that isn't part of a perfect heirarchy to
blast destination knowledge to eve= ry other network that isn't a strict
hierarchy.

3. Because the FI= B has distinctly different outputs than the RIB, its
possible to aggrega= te it where it wasn't possible to aggregate the
RIB.

4. Disaggreg= ation =3D bad.

If all of that is correct, and it does seem to be, th= en maybe there
just aren't any good answers to be found within the "box"= bounded by
TCP's need to have a stable IP address. So, lets set that bo= x aside
for a while and think about what routing might look like without= it.
What can we do if we don't care whether the endpoint has a stablelayer-3 address so long as it has some layer-3 address at any given
ti= me?


> I'm not sure what definition other people are using, bu= t it might be useful
> to come up with a standard one to prevent conf= usion.

At its most abstract, the routing process figures out how to get
packets from A to B via C. Everything at a finer level of de= tail is
subject to detail-level rules. Some of them can be bent. Others = can be
broken.


>    > which manages link cha= nges through dynamic re-addressing and multiply
>    > = addressing hosts. By and large the addresses change so that the
>&nbs= p;   > trivially aggregable routes don't have to. Not just at the = host level
>    > but all the way downstream from the l= ink change.
>
> If I understand you properly, this is a way of = dealing with topology changes
> by re-numbering things? (To use the d= efinition of 'routing' above, you
> wouldn't need to propogate new in= formation, because the old data would still
> be valid - it's just th= at the things the old information would apply to have
> changed?)
=
That's the gist of it, yeah. Any given node has three types of links:
coreward, hostward and sideward.

A coreward link is one f= rom which this node accepts a block of
addresses tied to a "default rout= e." Not necessarily 0/0. 2000::/3 is
a default route.

A hostward = link is one on which this node offers blocks of addresses
tied to a defa= ult route and the neighboring node has accepted
assignment of those addr= esses.

A sideward link is one on which an offer of addresses has bee= n made
but rejected by the neighbor as it already has a satisfactory cor= eward
path, yet this node has also rejected the neighbors offer of
ad= dresses.

Each address block you hold (and you don't hold many) is ti= ed to a
single coreward path which immediately aggregates into a larger = block
of addresses held by your coreward neighbor. If any element of the=
coreward path fails, you send a message hostward instructing every
r= outer and host in that direction that the address block is no longer
valid.

From your hostward neighbor, you'll receive a noti= fication that the
assigned address block has reached its utilization hig= h water mark. If
you have enough addresses, you'll assign it a new bigge= r block and
tell it to schedule release of the existing block in 300 sec= onds. And
in 300 seconds you send another message hostward declaring the= old
block invalid.

If you need more addresses to fulfill the req= uest, you send a message
coreward indicating that you've reached your hi= gh water mark and need
a bigger address block.

Same process when = your hostward neighbor advises that his address
utilization has reached = his low water mark.

Sideward you send disaggregated routes which cre= ate shortcuts through
the network so it need not operate as a strict hei= rarchy. But these
routes are needed only for efficiency, not connectedne= ss. They can be
discarded at any distance without harm.

It's probably even practical to implement a short-term tunnel= ed
reroute via a formerly sideward now coreward link so that you can
= release the old addresses gracefully after a link failure.



&= gt; I need to go away and think about this for a while before I can have so= me
> really solid reaction, but off the top of my head I wonder if th= e work
> involved in keeping up with the changing addresses isn't as = much (or possibly
> more) work than the usual approach. TANSTAAFL, af= ter all...

Overall, it's more work for a certainty. In terms of the = maximum work
required for any particular node, my SWAG puts it far small= er than it
is now. And it seems to exhibit negligible growth with the nu= mber of
links and nodes in the network -- more than a couple hops away y= ou're
dealing with a single aggregate regardless.

>  &nbs= p; > Even bumps automatic resizing requirements upstream so that over time
>    > any given router offers exactly one r= oute outward which automatically
>    > aggregates with= the route its upstream already holds.
>
> Err, routing (in the= sense given at the top) is trivial when there's only one
> path ("it= s upstream"). It's finding/selecting paths in arbitrary graphs with
>= lots of alternate paths (i.e. ones with lots of 'cycles', to use the
&g= t; graph-theory term) which is the hard case.

We have excellent solu= tions for the hard case provided the graph-like
component to the network= contains a sufficiently small number of
prefixes. If we can find a solu= tion for a sufficiently large portion
of the network which looks as much= like a heirarchy as a graph, and
that solution plays nicely with the pu= rely graphy parts, then
pragmatically speaking the scalability problem i= s solved.


>    > It does require a new suite of transport protocols
>    > ...
>  =   > the odds of ever reaching deployment on an approach which requ= ires us
>    > to abandon TCP and UDP are not good?
= >
> That's infeasible; you can't require changing all hosts. You n= eed to see if
> you can come up with some approach that avoids that.<= br>>
> (E.g. if we have location-identity separatation deployed, y= ou could hide the
> new locators from the hosts.)

Perhaps. But= maybe it's worth setting aside that question long enough
to determine w= hether an internally consistent technical solution can
be built at all.<= br>
A transport protocol which doesn't require a stable address shouldwork equally well on a network which does provide one and on a networkwhich does not. Maybe that's the way in.


>> Are you game = to flesh it out and see how far we can run with it
>
> Right at the moment, I personally don't have any spare time/energy.
Well, lack of spare time/energy is a problem. But if there's only time
= to consider ideas within the box bounded by a TCP-required stable host
a= ddress then it hardly seems fair to criticize the research process
for n= ot finding anything new or insightful.


> But you
> shou= ld think about it (and try and write something); even if it's not usable> directly, there might be some aspects that could be useful to other d= esigns.

As it happens, I've spent a few dozens of hours pondering it= . But it's
only so much fun to play with one's self and my participation= here is
not paid (hire me please!)

The research we've done wants= to lead us in a direction where the host
address isn't stable. I respec= tfully suggest we follow and see what
there is to be seen.

Regard= s,
Bill Herrin


--
William D. Herrin ................ herrin@dirtside.com  bill@herrin.us
3005 Cran= e Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-30= 04
_______________________________________________
rrg mailing listrrg@irtf.= org
http://www.irtf.org/mailman/listinfo/rrg


--967773369-1500433957-1352821545=:10345-- From tony.li@tony.li Tue Nov 13 07:46:46 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946E021F85EE for ; Tue, 13 Nov 2012 07:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emSTiys6P2U7 for ; Tue, 13 Nov 2012 07:46:46 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 40BFB21F85E1 for ; Tue, 13 Nov 2012 07:46:44 -0800 (PST) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta03.emeryville.ca.mail.comcast.net with comcast id P0bW1k0080EPchoA33mj4h; Tue, 13 Nov 2012 15:46:43 +0000 Received: from sjc-vpn6-539.cisco.com ([128.107.239.233]) by omta01.emeryville.ca.mail.comcast.net with comcast id P3kT1k00T52qHCY8M3kWmW; Tue, 13 Nov 2012 15:44:41 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <50A24AFC.40408@internet2.edu> Date: Tue, 13 Nov 2012 07:44:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121112160254.ECDBD18C0C3@mercury.lcs.mit.edu> <50A24AFC.40408@internet2.edu> To: Scott Brim X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:46:46 -0000 On Nov 13, 2012, at 5:28 AM, Scott Brim wrote: > I suggest we declare the RRG list officially open Not necessary, as it was not closed. However, for a group in = hibernation, y'all are makin an awful racket. ;-) > and have a meeting in > Orlando. Feel free. Due to my day job, I will not be able to attend. Are you = willing to step up as acting chair? Tony From eric.fleischman@boeing.com Tue Nov 13 08:31:07 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F1121F86C3 for ; Tue, 13 Nov 2012 08:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKbB8Sfd7hBm for ; Tue, 13 Nov 2012 08:31:07 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id DC42C21F855A for ; Tue, 13 Nov 2012 08:31:03 -0800 (PST) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id qADGV0Em012232 for ; Tue, 13 Nov 2012 08:31:01 -0800 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id qADGUxbv012200 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 13 Nov 2012 08:30:59 -0800 Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.248]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 13 Nov 2012 08:30:59 -0800 From: "Fleischman, Eric" To: Tony Li , Dae Young KIM Date: Tue, 13 Nov 2012 08:30:58 -0800 Thread-Topic: [rrg] RRG to hibernation Thread-Index: Ac3BaC0IS659HGZCTzWADvzKHNpEOQAU8EXg Message-ID: <98C98A7AE5C75941BCC7172509D00CA6386BE6E6F9@XCH-NW-12V.nw.nos.boeing.com> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> In-Reply-To: <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> 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-TM-AS-MML: No Cc: "rrg@irtf.org" Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 16:31:07 -0000 >>=20 >> Simple: one of the contributors to the explosion is the drive for PI pre= fixes. This is driven by sites that choose to be multi-homed and want fail= over semantics that BGP can provide. >>=20 >> With ILNP, a site can get this semantics with multiple PA prefixes. >> Isn't the description the same with the current IP Internet? Can't the c= urrent Internet do the same? Any change?=20 >No. Today if you have a set of PA prefixes and your address changes from = one to another, your TCP connections all break. >Tony A nit: These connections will not break if HIP is being used. From wherrin@gmail.com Tue Nov 13 13:41:44 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7E421F86EE for ; Tue, 13 Nov 2012 13:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l205wgZbQNLg for ; Tue, 13 Nov 2012 13:41:43 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1D08F21F8621 for ; Tue, 13 Nov 2012 13:41:43 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id 16so2456808obc.13 for ; Tue, 13 Nov 2012 13:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=rgV5+/xvSi+f5O7EIHvETECXEja3txwtB/6rAgH9Qbk=; b=qRKWbhzLFSax2Du5CDSaaE2L5kmqk4lMoJMmdQSXN6whq3mtZRHu+a6XelB4tSA0xK YS03ZncOqW8sJdP27+HQ63eNJ9Fhyj30mSmAkgWbejY7ZV4ekdwaOyHVMKoEJeWGNzeS 2aLw90I/qoRKiS7lXXTFbko6556LibQbGT1QkVfQJU45/XN3YsUxKMwTtMBz6maqhj+2 YE9TSuLYEaMreboRmUN3HEB5Wb35CiEGXJgUsDcxkLYhxOLSwNGw4N58kCpL96ZMk4CN v7dqvOaAARiCDdsnF4xM1hqe5h87oc7VXkdisfDjA4zS1A52KC9RFHVjw+IwQqelOLZy DWEQ== Received: by 10.182.154.70 with SMTP id vm6mr19737657obb.50.1352842902468; Tue, 13 Nov 2012 13:41:42 -0800 (PST) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.182.81.164 with HTTP; Tue, 13 Nov 2012 13:41:22 -0800 (PST) In-Reply-To: <1352821545.10345.YahooMailNeo@web160906.mail.bf1.yahoo.com> References: <1352821545.10345.YahooMailNeo@web160906.mail.bf1.yahoo.com> From: William Herrin Date: Tue, 13 Nov 2012 16:41:22 -0500 X-Google-Sender-Auth: XBqGy5fSf6yTbi-eIxCZU1VLjGE Message-ID: To: P S Content-Type: text/plain; charset=ISO-8859-1 Cc: "rrg@irtf.org" , Noel Chiappa Subject: Re: [rrg] Rerouting by readdressing X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 21:41:44 -0000 On Tue, Nov 13, 2012 at 10:45 AM, P S wrote: > >> The research we've done wants to lead us in a direction where the host >> address isn't stable. > > you may want to check here http://rina.tssg.org Hi Peter, I'll see the network-as-IPC approach and counter with the Goat Entrails Routing Protocol, or GERP. The operating principle behind GERP is that for each packet, you pay a mystic to butcher a goat, read the entrails and then tell you which link to send the packet down. I worry that GERP might not scale well, constrained as it is by the number of available goats. Okay, so I'm being harsh, bordering on cruel. Here's the deal: the last time I looked at John Day's work, it was so much gobbledygook. Abstruse material ineptly presented? Or actual gibberish? I still don't know but a 10 minute perusal of that web site didn't get me any closer to a credible explanation of how the router in the middle of the complex network, far from either of the endpoints, is supposed to select which of its links is in the direction of the eventual receiver. Slide 14 of http://rina.tssg.org/docs/CAMAD-slides.pdf implies the construction of a stateful pathways between every pair of communicating applications. Circuit switching that supports packet flows instead of bit rates? That's ridiculous on its face. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dykim6@gmail.com Tue Nov 13 14:37:43 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D831521F8621 for ; Tue, 13 Nov 2012 14:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwA38f+7sowe for ; Tue, 13 Nov 2012 14:37:43 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id DF48B21F84B9 for ; Tue, 13 Nov 2012 14:37:42 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id g24so1153862qab.13 for ; Tue, 13 Nov 2012 14:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Rsr5J0E75R6pXNKX8PTRogu3Ubz/f2bcOzA5FSom+ac=; b=anVXe6A5Y3/mDwM7cq3Vz5utgr8c0Rg/1zqJnpDnjvraiZ92v5AP0Y9FR+r/HRrgBq oMu0TMSbFS448stfM+r2pF7ZDW3j48vuBU3/sXTN2Hgr7fOcDZ/yebCmsLMImlXtu8JV 5EDU7pelM04gi8H4y73BknSUyEWcvJDcdDOl/UvblK5vyCMCcrg5fmNHVEC7LobGteSp c12El89g0XjQEYdpVCdIDMN2A7F2o50azoiBwjwKeJie8tqkmxfquuddr9YLyu96PZi3 MuwKt0U2agKEUfu69CgSHjbeKAb6yOnr47lEdIbypSvrBE7c9WdBSo3JaA7Sc1ql6et/ 4PeA== Received: by 10.229.196.195 with SMTP id eh3mr5738120qcb.82.1352846262292; Tue, 13 Nov 2012 14:37:42 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 13 Nov 2012 14:37:22 -0800 (PST) In-Reply-To: References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> From: Dae Young KIM Date: Wed, 14 Nov 2012 07:37:22 +0900 X-Google-Sender-Auth: EJg8hPjSJnpssu2Er_F_FOZDbEI Message-ID: To: Tony Li Content-Type: multipart/alternative; boundary=0016e6d26608e6518104ce68105a Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 22:37:44 -0000 --0016e6d26608e6518104ce68105a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 14, 2012 at 12:41 AM, Tony Li wrote: > > > Does this mean renumbering? > > > Yes, for the end host, the assignment of locators can become automatic. > I thought renumbering is the last thing people wanted to do.... -- DY --0016e6d26608e6518104ce68105a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2012 at 12:41 AM, Tony Li <tony.li@tony.li> wr= ote:

> Does this mean renumbering?


Yes, for the end host, the assignment of locators can become automatic.

I thought renumbering is the last thing= people wanted to do....

--
DY
--0016e6d26608e6518104ce68105a-- From dykim6@gmail.com Tue Nov 13 15:00:06 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AF021F84F1 for ; Tue, 13 Nov 2012 15:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i1VM9gimoZj for ; Tue, 13 Nov 2012 15:00:06 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id E507F21F845D for ; Tue, 13 Nov 2012 15:00:05 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id g24so1166238qab.13 for ; Tue, 13 Nov 2012 15:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=nfNahEuAa1Ll1+ljZhcQkG14EQDY6KO6cGuYwFOew8E=; b=VrY2lrIw+bEqC6TY9AuLMx/yU58/jJDjBTmayBLMuxr5lJbkmRHuG4+qkcL7ZJZCB7 oRETFPN1inqgwOSMrt88sCU2f0aJZgXwk2cxWpkwjH9LMXnCsFpYY7ed0Nhoq0C8Ys6a q2VvuiRRRWWLw03L+Qv7tjjzZJ9+/V0vvalTYsjc0rpjJKX6uEo0MmkmlibQC2s4VgD0 2oyS62cEl2qOcqiE8cQDAEo1GNUw/ydarvEP6XQ8OvQQIqVt3yiReAhjYIlOLBDkFi6M hCNvXdD/CO2fb19u0UaIvOI/n12gGASxei/Qg3pvinILcwrfPc08im+YgZZKrAhy7gLW pwvg== Received: by 10.224.9.138 with SMTP id l10mr1169503qal.58.1352847605145; Tue, 13 Nov 2012 15:00:05 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 13 Nov 2012 14:59:45 -0800 (PST) In-Reply-To: References: From: Dae Young KIM Date: Wed, 14 Nov 2012 07:59:45 +0900 X-Google-Sender-Auth: okfaoL9ZGA9qBNr_LkGrVp6YOl0 Message-ID: To: William Herrin Content-Type: multipart/alternative; boundary=bcaec517ab7af0a0e804ce6860e3 Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Rerouting by readdressing X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:00:06 -0000 --bcaec517ab7af0a0e804ce6860e3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 13, 2012 at 8:30 AM, William Herrin wrote: > > What can we do if we don't care whether the endpoint has a stable > layer-3 address so long as it has some layer-3 address at any given > time? > Good point. A transport protocol which doesn't require a stable address should > work equally well on a network which does provide one and on a network > which does not. Maybe that's the way in. > Worth pursuing. The research we've done wants to lead us in a direction where the host > address isn't stable. I respectfully suggest we follow and see what > there is to be seen. > Will stay tuned. -- DY --bcaec517ab7af0a0e804ce6860e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 13, 2012 at 8:30 AM, William Herrin <<= a href=3D"mailto:bill@herrin.us" target=3D"_blank">bill@herrin.us> wrote:

What can we do if we don't care whether the endpoint has a stable
layer-3 address so long as it has some layer-3 address at any given
time?

Good point.

A transport protocol which doesn't require a stable address should
work equally well on a network which does provide one and on a network
which does not. Maybe that's the way in.

Worth= pursuing.

The research we've done wants to lead us in a direction where the host<= br> address isn't stable. I respectfully suggest we follow and see what
there is to be seen.

Will stay tuned.
--
DY
--bcaec517ab7af0a0e804ce6860e3-- From tony.li@tony.li Tue Nov 13 15:00:21 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7045221F8507 for ; Tue, 13 Nov 2012 15:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbRg6kSJBmR7 for ; Tue, 13 Nov 2012 15:00:21 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id EC08A21F84F1 for ; Tue, 13 Nov 2012 15:00:18 -0800 (PST) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta02.emeryville.ca.mail.comcast.net with comcast id PAw31k0031smiN4A2B0Jda; Tue, 13 Nov 2012 23:00:18 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta20.emeryville.ca.mail.comcast.net with comcast id PAy31k00C52qHCY8gAy5PZ; Tue, 13 Nov 2012 22:58:16 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Tue, 13 Nov 2012 14:58:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> To: Dae Young KIM X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:00:21 -0000 On Nov 13, 2012, at 2:37 PM, Dae Young KIM wrote: > On Wed, Nov 14, 2012 at 12:41 AM, Tony Li wrote: >=20 > > Does this mean renumbering? >=20 >=20 > Yes, for the end host, the assignment of locators can become = automatic. >=20 > I thought renumbering is the last thing people wanted to do....=20 Manual renumbering is certainly the last thing that folks want to do. = This is why we're trying to automate it. Please read the RFCs. They will help. Tony From dykim6@gmail.com Tue Nov 13 15:17:25 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8B321F8795 for ; Tue, 13 Nov 2012 15:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4kuS-EMhMpA for ; Tue, 13 Nov 2012 15:17:25 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 01C3921F878F for ; Tue, 13 Nov 2012 15:17:24 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id t11so2898141qaa.13 for ; Tue, 13 Nov 2012 15:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=/qymtppK9eHk29pAuWClvCzzorua/eOhIwMy91TuEjw=; b=QbVRxulcQFiST8C6GfnFAb93O0/6WZxMyIX0vR3VZcn580SQbwyvv+JBiaT5v16TNv IDWGt3igiov46FuZhzTc/nYGNmbEUKozh5iGklgFp7RFjTCGTcG7yiP1h2Cv4boE/+UD 3MFLC1/G6UlRPAzwZAi4HDKSBkm+Hf5dtAUd7/b0ml94zymQtwvDJ8vLDKfDqyQoHmSQ MpnNdpgAKQUfHqMQXtKizrFP/0WHT/gvzG+xaqQXzhEtV0saj5MbMdYzzGVm6+gEBRdJ lFU7XpBohCFumiTpBolGZ2iUaSysKEtokZXP8PrVvbVcZbu2awAwwuONALgMTvXud0at ER8g== Received: by 10.49.117.137 with SMTP id ke9mr28465458qeb.5.1352848644426; Tue, 13 Nov 2012 15:17:24 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 13 Nov 2012 15:17:04 -0800 (PST) In-Reply-To: <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> From: Dae Young KIM Date: Wed, 14 Nov 2012 08:17:04 +0900 X-Google-Sender-Auth: tXNfXQVKB-s2wL70U3VqCqeO-gE Message-ID: To: Tony Li Content-Type: multipart/alternative; boundary=047d7b66efdfe2cb2804ce689e44 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:17:25 -0000 --047d7b66efdfe2cb2804ce689e44 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 14, 2012 at 7:58 AM, Tony Li wrote: > > Manual renumbering is certainly the last thing that folks want to do. > This is why we're trying to automate it. > I think renumbering could also be automated with the IP hosts, albeit you might need a shim session layer not to break APP communications. This is a non-LIS approach which you don't buy, though. I might be interested in a non-LIS solution with no need for renumbering, neither for a shim session layer. Since it's a non-LIS solution even without a shim session layer, the host doesn't have to change at all. -- DY --047d7b66efdfe2cb2804ce689e44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2012 at 7:58 AM, Tony Li <tony.li@tony.li> wro= te:

Manual renumbering is certainly the last thing that folks want = to do. =A0This is why we're trying to automate it.

I think renumbering could also be automated with the IP = hosts, albeit you might need a shim session layer not to break APP communic= ations. This is a non-LIS approach which you don't buy, though.

I might be interested in a non-LIS solution with no need for renumberin= g, neither for a shim session layer. Since it's a non-LIS solution even= without a shim session layer, the host doesn't have to change at all. =

--
DY
--047d7b66efdfe2cb2804ce689e44-- From jmh@joelhalpern.com Tue Nov 13 15:24:52 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4539821F87B0 for ; Tue, 13 Nov 2012 15:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZJcEVF9VUHK for ; Tue, 13 Nov 2012 15:24:51 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6C46021F8527 for ; Tue, 13 Nov 2012 15:24:51 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C157B557F4D for ; Tue, 13 Nov 2012 15:24:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 30361C1AEA; Tue, 13 Nov 2012 15:24:49 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-52-236.clppva.btas.verizon.net [71.161.52.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 94BB3C1AE9; Tue, 13 Nov 2012 15:24:48 -0800 (PST) Message-ID: <50A2D6BC.602@joelhalpern.com> Date: Tue, 13 Nov 2012 18:24:44 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dae Young KIM References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:24:52 -0000 Shim6 does exactly what you describe. It may even a reasonable approach, although i has not gotten traction. It is, effectively, a locator / identifier separation in a v ery limited form. Yours, Joel On 11/13/2012 6:17 PM, Dae Young KIM wrote: > On Wed, Nov 14, 2012 at 7:58 AM, Tony Li > wrote: > > > Manual renumbering is certainly the last thing that folks want to > do. This is why we're trying to automate it. > > > I think renumbering could also be automated with the IP hosts, albeit > you might need a shim session layer not to break APP communications. > This is a non-LIS approach which you don't buy, though. > > I might be interested in a non-LIS solution with no need for > renumbering, neither for a shim session layer. Since it's a non-LIS > solution even without a shim session layer, the host doesn't have to > change at all. > > -- > DY > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > From tony.li@tony.li Tue Nov 13 15:25:45 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1689121F8791 for ; Tue, 13 Nov 2012 15:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CC+5NzrCyDA for ; Tue, 13 Nov 2012 15:25:44 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id AF43B21F85B8 for ; Tue, 13 Nov 2012 15:25:40 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta01.emeryville.ca.mail.comcast.net with comcast id P4Xa1k00C1Y3wxoA1BRfYu; Tue, 13 Nov 2012 23:25:39 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta15.emeryville.ca.mail.comcast.net with comcast id PBPT1k00K52qHCY8bBPVZ4; Tue, 13 Nov 2012 23:23:38 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Tue, 13 Nov 2012 15:23:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4DE06D35-70EC-4A69-A520-971FA64673D4@tony.li> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> To: Dae Young KIM X-Mailer: Apple Mail (2.1499) Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:25:45 -0000 > I think renumbering could also be automated with the IP hosts, albeit = you might need a shim session layer not to break APP communications. = This is a non-LIS approach which you don't buy, though. Long ago we went down the path of trying a shim. It was not pretty. > I might be interested in a non-LIS solution with no need for = renumbering, neither for a shim session layer. Since it's a non-LIS = solution even without a shim session layer, the host doesn't have to = change at all.=20 I too would be interested in free money. But I'm not holding my = breath. Tony From dykim6@gmail.com Tue Nov 13 15:46:38 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD81721F8522 for ; Tue, 13 Nov 2012 15:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtup+sh1cAQ5 for ; Tue, 13 Nov 2012 15:46:38 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id B035C21F84F6 for ; Tue, 13 Nov 2012 15:46:37 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so4408671qcs.13 for ; Tue, 13 Nov 2012 15:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=2gjz2T0AoAbAR4l043eVuIycWMno7yAqbvsHt9wjuro=; b=X2SqWzbePfb5XWGXtPXI4v4J4r2ALjDmpU2NIardp5NXG85XaNRMubu6YBjtCI93eU JHVflEzihA/YrWhFJ1rHC1lTQcFl0OGBdUFkEJDkxpYDtNStnm1geTDWlLB6uWMxV7Px zFRIO2OBUDjDeK3uvEaM8RM2PDmzkAAss06+SeJzoICs14vLDe1n8CI7i0YucyC/c6uQ oP2XRGnzoYcOh1DMJ85EBdI1QKcETvQCOb7/MBUzVJ4e2gqqfLN/7ZOxozod1lnNaJTq iCGAqJEC9tNHDGiwJODpxX2U92UYywLFVCiKQ9L2EcNhxHyT+9pWOM8PCIkVQnRcykXE 5glw== Received: by 10.224.179.138 with SMTP id bq10mr1143807qab.73.1352850396110; Tue, 13 Nov 2012 15:46:36 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 13 Nov 2012 15:46:15 -0800 (PST) In-Reply-To: <50A2D6BC.602@joelhalpern.com> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <50A2D6BC.602@joelhalpern.com> From: Dae Young KIM Date: Wed, 14 Nov 2012 08:46:15 +0900 X-Google-Sender-Auth: 1rcMk5XLwQhm2FM8lb9QbjXngzI Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=20cf30363f794b600304ce6907e5 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:46:38 -0000 --20cf30363f794b600304ce6907e5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 14, 2012 at 8:24 AM, Joel M. Halpern wrote: > Shim6 does exactly what you describe. > It may even a reasonable approach, although i has not gotten traction. > It is, effectively, a locator / identifier separation in a v ery limited > form. > Isn't it again a LIS? Why not people trying to insert a real session layer? Then, Transport/Network don't have to deal with two number spaces, ID and Loc. -- DY --20cf30363f794b600304ce6907e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2012 at 8:24 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Shim6 does exactly what you describe.
It may even =A0a reasonable approach, although i has not gotten traction. It is, effectively, a locator / identifier separation in a v ery limited fo= rm.

Isn't it again a LIS?
Why not people trying to insert a real session layer? Then, Transport/Netw= ork don't have to deal with two number spaces, ID and Loc.

--
DY
--20cf30363f794b600304ce6907e5-- From dykim6@gmail.com Tue Nov 13 15:53:59 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F24921F87A4 for ; Tue, 13 Nov 2012 15:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwiWui0QIl72 for ; Tue, 13 Nov 2012 15:53:57 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 65E6321F86A3 for ; Tue, 13 Nov 2012 15:53:54 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so4412287qcs.13 for ; Tue, 13 Nov 2012 15:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=fCYepU+7uIiFM+0TAZptekveUPCuhU45MvDRxIyjZbs=; b=n5xcciC38PBXLC9TZRHPbA/LkJS/ywa39AXGt2UHC/vU/dxDNVxzI4yoldiyM8oW+h 7F6Z6pMaBubswGIUvRcPWko8udwNIvzBGMTWMOZ2Rnjn/Fz0VjYa4rwsR8EX/WWmZDt1 /V8aReOdo9g+5P2TFovc6CPsQ2r/wfXR88jSIJW7GeyPKQSfAQapEAYBl304PMFXjBA1 32p9shgdXzDF2i5p5ygU2zADbJu3cf9ziu52qC6N2MCjBZMVbJladLHhudMJss9koJGF iU0ZffJ4UK0fNmALX93YGtfHoEW4C/TWawRgRPMpFTQOC6j43tNb8PV/+h1Y8GomTPbk L8eg== Received: by 10.49.13.202 with SMTP id j10mr28307115qec.27.1352850833076; Tue, 13 Nov 2012 15:53:53 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 13 Nov 2012 15:53:32 -0800 (PST) In-Reply-To: <4DE06D35-70EC-4A69-A520-971FA64673D4@tony.li> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <4DE06D35-70EC-4A69-A520-971FA64673D4@tony.li> From: Dae Young KIM Date: Wed, 14 Nov 2012 08:53:32 +0900 X-Google-Sender-Auth: b7aJrQlN3LK2bQmy4kRQAHASbE0 Message-ID: To: Tony Li Content-Type: multipart/alternative; boundary=047d7b6da7e856f07104ce6921b5 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:53:59 -0000 --047d7b6da7e856f07104ce6921b5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 14, 2012 at 8:23 AM, Tony Li wrote: > > I too would be interested in free money. But I'm not holding my breath. > This group seems to be too much into LIS. There practically seems to be no room for non-LIS advocates. As soon as you hint for a non-LIS, you're almost harshly ridiculed. Why should the routing group be so much biased toward LIS which has only secondary/indirect implications on routing? -- DY --047d7b6da7e856f07104ce6921b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2012 at 8:23 AM, Tony Li <tony.li@tony.li> wro= te:

I too would be interested in free money. =A0 But I'm not holding = my breath.

This group seems to be too much into LI= S. There practically seems to be no room for non-LIS advocates. As soon as = you hint for a non-LIS, you're almost harshly ridiculed.

Why should the routing group be so much biased toward LIS which has onl= y secondary/indirect implications on routing?

--
DY<= br> --047d7b6da7e856f07104ce6921b5-- From wesley.george@twcable.com Tue Nov 13 16:17:00 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2872521F859E for ; Tue, 13 Nov 2012 16:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-JNiVg9IE8Q for ; Tue, 13 Nov 2012 16:16:58 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 55DE621F84C7 for ; Tue, 13 Nov 2012 16:16:57 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="451176563" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Nov 2012 19:16:39 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 13 Nov 2012 19:16:55 -0500 From: "George, Wes" To: Dae Young KIM , Tony Li Date: Tue, 13 Nov 2012 19:16:58 -0500 Thread-Topic: [rrg] RRG to hibernation Thread-Index: Ac3B+jDnnZyggiNTSdWKZujoqm2+zgAAjFVA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033730A825@PRVPEXVS15.corp.twcable.com> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <4DE06D35-70EC-4A69-A520-971FA64673D4@tony.li> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD5923033730A825PRVPEXVS15cor_" MIME-Version: 1.0 Cc: "rrg@irtf.org" Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 00:17:00 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD5923033730A825PRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of Dae Y= oung KIM This group seems to be too much into LIS. There practically seems to be no = room for non-LIS advocates. As soon as you hint for a non-LIS, you're almos= t harshly ridiculed. Why should the routing group be so much biased toward LIS which has only se= condary/indirect implications on routing? [WEG] I don't see ridicule of the idea of non-LIS. I see people trying to r= esurrect old arguments on the prior work of this group with points that hav= e already been endlessly discussed with no consensus reached, and I see peo= ple responding patiently, but growing less patient as others don't get the = hint that the rest of us are more than ready to move on to something new. I= nstead of trying to rehash the last several years, again, perhaps you can l= ook more carefully at the problems proposed for new work in this group so t= hat we can try to make some forward progress? Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2671C6CDFBB59E47B64C10B3E0BD5923033730A825PRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of Dae Young KIM


This group seems to be too much into LIS. There practically seems to be no = room for non-LIS advocates. As soon as you hint for a non-LIS, you're almos= t harshly ridiculed.

Why should the routing group be so much biased toward LIS which has only se= condary/indirect implications on routing?

[WEG] I don’t see ridicule of the idea of non-LIS. I see = people trying to resurrect old arguments on the prior work of this group with points that have already been endlessly discussed with no conse= nsus reached, and I see people responding patiently, but growing less patie= nt as others don’t get the hint that the rest of us are more than rea= dy to move on to something new. Instead of trying to rehash the last several years, again, perhaps you can look mo= re carefully at the problems proposed for new work in this group so that we= can try to make some forward progress?

Wes George=


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_2671C6CDFBB59E47B64C10B3E0BD5923033730A825PRVPEXVS15cor_-- From wherrin@gmail.com Tue Nov 13 16:29:40 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6935721F881E for ; Tue, 13 Nov 2012 16:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITNtXdTanucI for ; Tue, 13 Nov 2012 16:29:39 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id E3D0021F869E for ; Tue, 13 Nov 2012 16:29:38 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n9so10064140oag.13 for ; Tue, 13 Nov 2012 16:29:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=8QIqNjtKAMFn9RD2ntNQ0bspq8zNE58GwzW5C0Qopho=; b=YSWiD5QsAubCX3tlJCp1A9MlUpVfDmBurTVNx2YuHvHonr1ujgNfyM6VndkAHCX7Rf 5luP6F/u2TUZoDSzuuBSyGcjpbHXeEaYVe42ULwwt/3Rf1Ju1V9N0zweDcW9Y7uwcYGT YpPOKhIuGih229bouRcUtiFA5b44Rc8Y1+U9ML9OdjOAfLcogrf3Z283BvgrwrGF3Juy VFYFkTC5fc69+l8M4i2W+7glUVK6/MetnEgTK3l0ER/mbP06YNYHHUyLXdn35rM3W/ff 4f0MeF8VUAVKjWo1gkV+2Vy4UBT64IndXlkOPs03N3GlRWdv6/05aF4ZrW7utwSa3uk+ dJcQ== Received: by 10.60.9.167 with SMTP id a7mr19440245oeb.61.1352852976485; Tue, 13 Nov 2012 16:29:36 -0800 (PST) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.182.81.164 with HTTP; Tue, 13 Nov 2012 16:29:15 -0800 (PST) In-Reply-To: <09cc01cdc173$71323cd0$5396b670$@huitema.net> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <09cc01cdc173$71323cd0$5396b670$@huitema.net> From: William Herrin Date: Tue, 13 Nov 2012 19:29:15 -0500 X-Google-Sender-Auth: 1z1ypThakEPusfuIEBMuiWgZcfU Message-ID: To: Christian Huitema Content-Type: text/plain; charset=ISO-8859-1 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 00:29:40 -0000 On Tue, Nov 13, 2012 at 2:49 AM, Christian Huitema wrote: >> No. Today if you have a set of PA prefixes and your address changes from > one >> to another, your TCP connections all break. > > That's true, has been for quite some time, and yet nobody seems to be doing > much about it. Actually, there's a whole IETF WG (MPTCP) dedicated to creating a TCP Multipath option which would function appropriately with hosts holding multiple PA addresses. There's a whole other group dedicated to improving SCTP to a point where it's credible as a TCP replacement. There's even a third WG (MIF) trying to work through the source address selection implications of a host that sits on multiple networks. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dykim6@gmail.com Tue Nov 13 16:39:03 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CD821F87C0 for ; Tue, 13 Nov 2012 16:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg0eV1FZNzqV for ; Tue, 13 Nov 2012 16:39:02 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id A841021F84F2 for ; Tue, 13 Nov 2012 16:39:02 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so4437503qcs.13 for ; Tue, 13 Nov 2012 16:39:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=fxcxF4uI/WAJRyTtndgvTK6r+2pSUE8edSWUN99Kta8=; b=YoL30FXUVyrvlyBL3Xwc54wb/nvyF3x58UESsP44xtQFEpyOeseYZ4Xz44WfEKT/Q4 /JGn4zoO35sIL793FXPuwGa+lPfYfH8Pw28gM8TfrRRGitCoO6IdEMjHYU7dRhzbcEWW svghHrxDEGV7Z9FF8EriQgy/rZFi6IE8uFrAF22xznpUgnPpcAJlHFTCyQTv0sG3jI5j xF0wamz4lpmvixaA8UkpvPfquFBkv2WK7uoyN6G5VWPrctzpNJY/m5/B7saeUdT+zH2d 67xfXbDjXBuCfndqj6ekDnh0ZbZnZnJu9xOG5a0est4bvFTERxV4RJmy67iKosl6TXSD lzcA== Received: by 10.49.3.234 with SMTP id f10mr28454200qef.45.1352853540517; Tue, 13 Nov 2012 16:39:00 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 13 Nov 2012 16:38:40 -0800 (PST) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923033730A825@PRVPEXVS15.corp.twcable.com> References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <4DE06D35-70EC-4A69-A520-971FA64673D4@tony.li> <2671C6CDFBB59E47B64C10B3E0BD5923033730A825@PRVPEXVS15.corp.twcable.com> From: Dae Young KIM Date: Wed, 14 Nov 2012 09:38:40 +0900 X-Google-Sender-Auth: MRYi-GL6zpJBXEbUopzgLcHaBhg Message-ID: To: "George, Wes" Content-Type: multipart/alternative; boundary=047d7bb03e68b735f504ce69c225 Cc: "rrg@irtf.org" Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 00:39:03 -0000 --047d7bb03e68b735f504ce69c225 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2012 at 9:16 AM, George, Wes wro= te: > > *[WEG] I don=92t see ridicule of the idea of non-LIS. I see people tryin= g > to resurrect old arguments on the prior work of this group with points th= at > have already been endlessly discussed with no consensus reached, and I se= e > people responding patiently, but growing less patient as others don=92t g= et > the hint that the rest of us are more than ready to move on to something > new. Instead of trying to rehash the last several years, again, perhaps y= ou > can look more carefully at the problems proposed for new work in this gro= up > so that we can try to make some forward progress?* > OK, fine, let's move on. --=20 DY --047d7bb03e68b735f504ce69c225 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2012 at 9:16 AM, George, Wes <wesley.george@twcab= le.com> wrote:

[WEG] I don=92t see ridicule of the idea of non-LIS. I se= e people trying to resurrect old arguments on the prior work of this group with points that have already been endlessly discussed with no conse= nsus reached, and I see people responding patiently, but growing less patie= nt as others don=92t get the hint that the rest of us are more than ready t= o move on to something new. Instead of trying to rehash the last several years, again, perhaps you can look mo= re carefully at the problems proposed for new work in this group so that we= can try to make some forward progress?


OK, fine, let's move on.
--
DY
--047d7bb03e68b735f504ce69c225-- From dykim6@gmail.com Tue Nov 13 17:18:11 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D3821F8673 for ; Tue, 13 Nov 2012 17:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daIFXYrLj8SN for ; Tue, 13 Nov 2012 17:18:10 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id B7F1821F8645 for ; Tue, 13 Nov 2012 17:18:09 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id g24so1234220qab.13 for ; Tue, 13 Nov 2012 17:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=UvnoLfxuzPW8R6aOfd6GNO0GeozWuPumMB6Qj/wRK9o=; b=sX2j+67pJZxRMhCAy+T884pfZJtKjDXIccVdib8NNq0xHWm3NNJh0fKH7gHvaGAkLV fToyt3qOywxt7CpVb0vGwygyE56Q1Fnd+Lp6zTdUGZlpZ21LR0tXurTjX4uVN2sDY+uG q748NcojKOYXE2QcDNEAsy/5cQnqbDn+Q/cPPjk5D6V7F7B+nPr+f2wwPjfP618sCjOA 7lXJInSnuU6xATjURDBE7TEnOBP3ya7C6Zazc9NwGaIN9dSKWBs7e84R/APi3dpjuQus U1EPNFh5y9bHu/fzFLCng3cDcGn1FezWQMliBF1s6qXK62cHVMMoRGNGlw/gIQvK5wZJ aWag== Received: by 10.229.198.204 with SMTP id ep12mr3411049qcb.52.1352855887228; Tue, 13 Nov 2012 17:18:07 -0800 (PST) MIME-Version: 1.0 Sender: dykim6@gmail.com Received: by 10.49.12.9 with HTTP; Tue, 13 Nov 2012 17:17:47 -0800 (PST) In-Reply-To: References: <20121112234012.05F8E18C0CA@mercury.lcs.mit.edu> <50A18F75.8060001@joelhalpern.com> <27E72BC2-C84D-469F-9667-7A749567B477@tony.li> <957297EA-FFF8-408A-A181-E57028C9B8E1@tony.li> <50A2D6BC.602@joelhalpern.com> From: Dae Young KIM Date: Wed, 14 Nov 2012 10:17:47 +0900 X-Google-Sender-Auth: 5jT9bsdJyyvj815-Ut-uRdjeoO4 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=005045014742972df604ce6a4e80 Cc: rrg@irtf.org Subject: Re: [rrg] RRG to hibernation X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 01:18:11 -0000 --005045014742972df604ce6a4e80 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 14, 2012 at 8:46 AM, Dae Young KIM wrote: > On Wed, Nov 14, 2012 at 8:24 AM, Joel M. Halpern wrote: > >> Shim6 does exactly what you describe. >> It may even a reasonable approach, although i has not gotten traction. >> It is, effectively, a locator / identifier separation in a v ery limited >> form. >> > > Isn't it again a LIS? > (Not to stretch the discussion, but for clarification). OK, Shim6 is not an LIS. But, the shim is between L3 and L4 while a session shim would be between L4 and APP. -- DY --005045014742972df604ce6a4e80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2012 at 8:46 AM, Dae Young KIM <dykim@cnu.kr> wro= te:
On Wed, Nov 14, 2012 at 8:24 AM, Joel M. Halpern <jmh@= joelhalpern.com> wrote:
<= div class=3D"im">
Shim6 does exactly what you describe.
It may even =A0a reasonable approach, although i has not gotten traction. It is, effectively, a locator / identifier separation in a v ery limited fo= rm.

Isn't it again a LIS?<= br>

(Not to stretch the discussion, but fo= r clarification).

OK, Shim6 is not an LIS. But, the shim is between L3 and L4 while a ses= sion shim would be between L4 and APP.

-- =
DY
--005045014742972df604ce6a4e80-- From russw@riw.us Wed Nov 21 04:36:21 2012 Return-Path: X-Original-To: rrg@ietfa.amsl.com Delivered-To: rrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469A521F8555 for ; Wed, 21 Nov 2012 04:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.304 X-Spam-Level: X-Spam-Status: No, score=0.304 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OATonLWEI-iu for ; Wed, 21 Nov 2012 04:36:20 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0645B21F8519 for ; Wed, 21 Nov 2012 04:36:20 -0800 (PST) Received: from cpe-071-074-016-043.ec.res.rr.com ([71.74.16.43] helo=[192.168.100.52]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from ) id 1Tb9XP-0001j4-8A; Wed, 21 Nov 2012 04:36:19 -0800 References: <2671C6CDFBB59E47B64C10B3E0BD5923033725314C@PRVPEXVS15.corp.twcable.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923033725314C@PRVPEXVS15.corp.twcable.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <289A4475-7521-4147-9E7F-7201EC667910@riw.us> X-Mailer: iPad Mail (10A523) From: Russ White Date: Wed, 21 Nov 2012 07:36:20 -0500 To: "George, Wes" X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "rrg@irtf.org" Subject: Re: [rrg] routing security and scale impacts (was RRG to hibernation) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 12:36:21 -0000 +1 I might even have some ideas on where to get some ideas, if we can convince t= he researchers in question to come forward. We could start with a requiremen= ts doc, which I'd be willing to co with someone once I replace the hard driv= e in my computer. Russ Sent from my iPad On Nov 13, 2012, at 9:09 AM, "George, Wes" wrote= : > Changing subject line to reflect topic >=20 > Shane has articulated a number of concerns that I think would be useful fo= r RRG to spend some time working on, and I tend to agree with Danny that the= current BGPSec solution seems to be more about "hacking at the edges" to ge= t something that is marginally better in some ways than the [lack of] securi= ty that we have now, potentially ignoring the known scaling problems this gr= oup has discussed at length all the while doing several things likely to exa= cerbate them. It gives me concern about whether it will see significant depl= oyment due to the large amount of required investment vs the potential benef= it. I know I have asked more than once about the scaling implications of BGP= Sec since it potentially makes a large impact in the footprint of the routin= g data that must be stored and managed, and haven't exactly been pleased wit= h the answers even though some analysis has been done to show that it's not a= bad thing. >=20 > If I were to distill things down, today we have a growth curve for both th= e routing table (both RIB and FIB) and for cost-effective hardware with the h= orsepower necessary to manage it (CPU, ASIC, memory, etc). SIDR is likely no= t the one thing that will break the routing system by causing those curves t= o cross, but it certainly changes the curves' pitch such that it's more like= ly that the cost of keeping up with the demands of the system starts becomin= g unmanageable, even if it doesn't actually reach the limits of the technolo= gy. The investment in a network for scale and growth is incremental, and SID= R's full justification is that those incremental upgrades will bring hardwar= e that can support its needs organically. However, things like BGPSec or oth= er disturbances that increase the growth curve of the routing table and rela= ted scaling vectors mean that as an operator, I have to shorten my upgrade c= ycle, spend capital earlier than originally projected, possibly even to the p= oi > nt where I can't manage an entire depreciation cycle (5-7 years) before ne= eding to spend additional money on upgrades. In a network that is driven by c= ommoditization of prices, that's not a good position to be in. >=20 > Additionally, as Shane alluded to in another message, this isn't simply ab= out DFZ scale, but also internal scale, where there are commonly a *LOT* mor= e routes being carried by your average router inside an ISP's network. There= are also other considerations like the rate of updates due to background ch= urn vs during an event, other things that the control plane must manage simu= ltaneously, etc. Taking a step even further away from where RRG has been pre= viously focused, there is a similar sort of scaling problem within the L3VPN= space that is typically self-contained within the SP's network. While I thi= nk there are some engineering solutions that may help with the short-term sc= aling issues, there may also be some meat for research in the area of modeli= ng and instrumentation of the routing system to give SP's better tools to us= e their available capacity efficiently, and possibly even changes to help th= e routing control plane degrade more gracefully and deterministically. The L= 3VPN > discussion is detailed in draft-gs-vpn-scaling-01 (an -02 rev is due soon= , waiting on co-author review and a few more updates), specifically in secti= on 6 and 6.5 for the modeling/instrumentation, and in sections 4 and 5 for w= ays that the control plane tends to break down at scale limits. >=20 > Thanks, >=20 > Wes George >=20 >=20 >=20 >> -----Original Message----- >> From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of >> Shane Amante >> Sent: Saturday, November 10, 2012 8:39 PM >> To: rrg@irtf.org >> Subject: Re: [rrg] RRG to hibernation >>=20 >>=20 >> On Nov 10, 2012, at 10:35 AM, Danny McPherson wrote: >>> On Nov 10, 2012, at 12:24 PM, Tony Li wrote: >> [--snip--] >>>> I agree that some security needs to be deployed. I'm not convinced >> that it needs to be BGPSEC. We've muddled along for many years and >> never found the gumption to actually deploy anything. Must not be >> important to people. I don't get it, but that's the observable >> behavior. >>>>=20 >>>> In any case, this doesn't seem like a research topic. This is pretty >> clearly an engineering issue. >>>=20 >>> I don't agree. The engineering solution that SIDR is actively working >> (RPKI-enabled BGPSEC) is pumping out standards track RFCs like there's >> no tomorrow. The USG has stated intentions of "expediting secure >> routing work through the Internet standard process" and "fostering >> adoption through government procurement vehicles". >>>=20 >>> As an operator this scares the hell out of me, especially considering >> what they've designed is largely a system to control "what's routed on >> the Internet and by whom". They can't seem to do anything in BGP(SEC) >> without introducing the equivalent of "periodic updates", and undoing >> all the goodness of things like update packing completely. >>>=20 >>> Some serious thinkers working on this problem would be goodness... >>=20 >> Let me add that I share Danny's concerns ... >>=20 >> However, let me try to take a step back and share with everyone a much >> broader set of, potentially, architectural concerns that I'm not sure >> this RG considered during the last round. >>=20 >> BGP was originally designed for flooding of reachability information. >> But, reachability information is the end-result /after/ the application >> of _routing_policy_, describing "intent", by operators of individual >> networks based on various contractual agreements they have with parties >> whom they directly interconnect. Assuming you agree with this premise, >> this presents a paradox from a security PoV. Specifically, if a >> downstream network does not have visibility into its upstream network's >> routing policy is it practical/feasible for the downstream network to >> understand the _intended_ propagation of reachability information and, >> ultimately, connectivity? Furthermore, is it feasible to carry such >> information within the control plane itself? Or, should the control >> plane be relegated to carrying [strictly] reachability information in >> real-time, while offboard systems carry accompanying routing policy and >> security information in order to assist in making "optimal" Inter-Domain >> rou ting/forwarding decisions? >>=20 >> A second concern is also related to the original design of BGP and what >> it has organically involved into, today. Specifically, BGP is /also/ >> now being tasked as a generic "message bus" and service discovery >> mechanism. Not to pick on anyone, in particular, but the following are >> recent examples that come to my mind wrt this trend: >> http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-01 >> http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 >> ... and, there may be others. Although, contrast those proposals with >> what should be most concerning to people in this RG, and in the IETF: >> http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error- >> handling-05 >> In short, operators (such as myself) are _extremely_ concerned that a >> single erroneous update results in a complete reset of BGP sessions. >> Due to the overwhelming success of BGP, it's now (and, has been for a >> while) a mission-critical protocol, thus such catastrophic session >> resets -- caused by a single malformed UPDATE -- are widely >> visible/impactful. This impact is compounded by the 'cost to recover'. >> Namely, due to the large and growing amount of information in the RIB >> (again, not just reachability, but also service-discovery and completely >> orthogonal information), it takes longer to exchange RIB information >> and, ultimately, restore services. Is this really the best we, as an >> industry, can do? >>=20 >> While the IETF IDR WG has been looking at mechanisms for how BGP may >> defend against certain types of erroneous BGP UPDATE's for external BGP >> sessions: >> http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 >> ... there does not appear to be any [straightforward] answer with >> respect to internal BGP sessions, given the requirement that BGP >> speakers internal to an AS must have a globally consistent RIB and FIB, >> otherwise packet forwarding loops will result. And, in my personal >> operational experience it's _rarely_ the case that malformed UPDATE's >> are detected at the first ASBR (attached to an eBGP neighbor) in my AS, >> thus it concerns me that mechanisms such as draft-ietf-idr-error- >> handling-02 are an adequate solution to the problems we experience. >> IOW, as an operator I desire "defense in depth" where a heterogeneous >> mix of vendor equipment (HW + SW), participating as interior BGP >> speakers, have mechanisms to detect *and* automatically recover from >> malformed UDPATE's received over iBGP sessions. This is another area >> that I would point research colleagues toward. >>=20 >> So, this raises the classic conundrum of: increasing complexity, >> increasing RIB (and FIB) size information coupled with a contrasting >> need from operators who are concerned about the robustness of the >> protocol and the requirement to NOT sustain any failures[1]. >> Something's got to give. >>=20 >> Ultimately, this makes me question whether it's no longer _just_ growth >> of RIB (and, FIB) size that this RG should be (primarily?) focused on. >> Rather, will the requirements for: >> a) operational robustness, in the face of critical messaging errors in >> an Inter-Domain Routing Protocol, which the IETF may be unable to >> address on its own; >> b) designing security as a first-class principle of an Inter-Domain >> Routing Protocol -- either carried within or outside of control-plane >> reachability information >> c) increased scalability of RIB (and, other?) information ... lead us >> down a path of considering we may be approaching the end-of-the-road for >> BGPv4 and we need something new? >>=20 >> Does anyone on this list share similar concerns wrt operational >> robustness, time to recovery and (then) scalability of BGPv4? >>=20 >> -shane >>=20 >> [1] It is not cool to suggest that operators should just stop asking for >> new features and we wouldn't have this problem. :) >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> http://www.irtf.org/mailman/listinfo/rrg >=20 > This E-mail and any of its attachments may contain Time Warner Cable propr= ietary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the us= e of the individual or entity to which it is addressed. If you are not the i= ntended recipient of this E-mail, you are hereby notified that any dissemina= tion, distribution, copying, or action taken in relation to the contents of a= nd attachments to this E-mail is strictly prohibited and may be unlawful. If= you have received this E-mail in error, please notify the sender immediatel= y and permanently delete the original and any copy of this E-mail and any pr= intout. > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg