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

Christopher Morrow <morrowc.lists@gmail.com> Wed, 28 March 2012 16:15 UTC

Return-Path: <christopher.morrow@gmail.com>
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 9601A21E808F; Wed, 28 Mar 2012 09:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.556
X-Spam-Level:
X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 hLQa7CyKoG2f; Wed, 28 Mar 2012 09:15:16 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9892F21E8135; Wed, 28 Mar 2012 09:15:16 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1789638obb.31 for <multiple recipients>; Wed, 28 Mar 2012 09:15:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BOnqtymFmnekG3Q1PIOEh3AuqVm+jnz08U/tIOi/SDY=; b=BTJGwQ1jxmhIic+rMUaeQ3yzoZJochqSDwFFpzmtsyjA/rgRwa4sGkhlDDtSgLA6PX XrafDYFIlDnGxuIBMrdGmGQiQURKABytJ6mHMmfT9y4JByQqxbo/2LhtdxEU5IGIxFY5 E7IVHvYl+XG66xmf6Kunx4xcusnonH9nvovB0caz7ux2I/QvH/7vqaSKRPlv93PILurw qWJIGjsFZBU0xlvOlmHKcqmU7RUW0sr0T/BnBNDC4cbSrl4IHYCzI9ex4SLVZmE+fLkj LcAHTj3tfl0LPCUMqru44RjPojeWoHxxOuD0Vec1Plv4QiJ5951zlhk4ShwwYdKXfv4K ZoKw==
MIME-Version: 1.0
Received: by 10.182.147.106 with SMTP id tj10mr38891209obb.71.1332951316187; Wed, 28 Mar 2012 09:15:16 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 09:15:16 -0700 (PDT)
In-Reply-To: <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> <alpine.LFD.2.02.1203281618090.2692@jamaica.dcs.gla.ac.uk>
Date: Wed, 28 Mar 2012 12:15:16 -0400
X-Google-Sender-Auth: NpVjtzScSQGFCmEAe1ifE7dHgEI
Message-ID: <CAL9jLaYqMwXVNKsHuBf_r8h==CGoee+D9k89Q4AZqT49jOQK1A@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Paul Jakma <paul@jakma.org>
Content-Type: text/plain; charset="ISO-8859-1"
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:15:17 -0000

On Wed, Mar 28, 2012 at 12:01 PM, Paul Jakma <paul@jakma.org> wrote:
> 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.

or we could have fixed the problem with locator/id separation... oh well.

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

it's hardly a choice of one or the other, framing the question in this
manner is a 'suckers choice'.

<http://sourcesofinsight.com/refuse-the-suckers-choice-4/>

It's certianly possible that at some point when aggregation between
AS's becomes used properly and effectively... someone will figure out
the security properties if this configuration.

> (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).

it seems that to date, folk can't seem to figure out the aggregation
bits, maybe that will change in the future.

-chris