IETF Logo Mail Archive

Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath

Paul Jakma <paul@jakma.org> Wed, 28 March 2012 16:01 UTC

Return-Path: <paul@jakma.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3B121F895D for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 09:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1aTbQ3ofjLf for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 09:01:22 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB99821F8934 for <sidr@ietf.org>; Wed, 28 Mar 2012 09:01:21 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so771174wgb.13 for <sidr@ietf.org>; Wed, 28 Mar 2012 09:01:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=+0uEIwsMFKU/8VVCBL7rWE6RgIDCxky52XrXsP6gagY=; b=ZKpFOa//LpzSsKNGW1TIyPYZapVrPwmAKXyXLxp9aDU+KA4MT991P5JTgD2G+eqWlt 35d26eaCZdiZimZ3ZFxoscfbW4P6JFnMigzDYa9K85uKnDezj76lVBWwjp7ZNKBRKtfI x0/MBI+S98sIdc10jVTs+FV9laBXIcLhIBR41Xz0d3PUIAuLKhQiPvgOYOLbbEGWoTlb 95QhdZY2A7cqMnOLaDEAi4/3Fad2BRwGQXg8IcGU+R6egn8FP2WdW+tFSfPi8OX7AyUn BkjKoQaRa9tYhbxYvQcaP1+VuCENk3DxUM/vnoR0QlbLyLKAMv9nHJVQVebae2gv1OER eu1Q==
Received: by 10.216.137.74 with SMTP id x52mr17906962wei.77.1332950480973; Wed, 28 Mar 2012 09:01:20 -0700 (PDT)
Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk. [130.209.244.4]) by mx.google.com with ESMTPS id n8sm14872598wix.10.2012.03.28.09.01.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 09:01:20 -0700 (PDT)
Date: Wed, 28 Mar 2012 17:01:18 +0100
From: Paul Jakma <paul@jakma.org>
X-X-Sender: paul@jamaica.dcs.gla.ac.uk
To: Jakob Heitz <jakob.heitz@ericsson.com>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se>
Message-ID: <alpine.LFD.2.02.1203281618090.2692@jamaica.dcs.gla.ac.uk>
References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1203281401410.2692@jamaica.dcs.gla.ac.uk> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <FBFDBAE5-9BF8-4708-9240-B775CAF46D56@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Gm-Message-State: ALoCoQkFSJNa+0IGvZagShRNFN51GUbhK9yz4CNBr5PncDrlSF9z2nZToD14EgOpLp5fTaeZpm5Y
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2012 16:01:23 -0000

On Wed, 28 Mar 2012, Jakob Heitz wrote:

> The issue is SIDR can not aggregate multiple paths.

> Should SIDR work on path aggregation?

If we ever want to make routing state scale sub-linearly (i.e. make IDR 
"compact") in the size of the internet, then we're almost certainly going 
to need some form of conglomeration of routing information in some shape 
or form. Still having support for aggregation in BGP could then be useful.

It'd be a shame if we ended up having to choose between scalable and 
secure routing.

(OTOH scalable routing is potentially so far off in the future, and might 
be so different, that it's hard to say what level of extra engineering or 
overhead, if any would be justified for SIDR).

regards,
-- 
Paul Jakma  paul@jakma.org  twitter: @pjakma  PGP: 64A2FF6A
Fortune:
COBOL:
 	Completely Over and Beyond reason Or Logic.

v2.23.0 | Report a Bug | By Email