IETF Logo Mail Archive

Re: [sidr] Burstiness of BGP updates

Christopher Morrow <morrowc.lists@gmail.com> Wed, 16 November 2011 04:39 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 0706B1F0C74 for <sidr@ietfa.amsl.com>; Tue, 15 Nov 2011 20:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.547
X-Spam-Level:
X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 3iawdXQPcwF2 for <sidr@ietfa.amsl.com>; Tue, 15 Nov 2011 20:39:53 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84D0F1F0C54 for <sidr@ietf.org>; Tue, 15 Nov 2011 20:39:53 -0800 (PST)
Received: by iaeo4 with SMTP id o4so72290iae.31 for <sidr@ietf.org>; Tue, 15 Nov 2011 20:39:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TrPQEp0W3E/LDHgdqI758kJyDHlsLDp7rRKjPapkhbs=; b=CHsgDGbDN7fGFT3tZtMeb2XfDbCgM1NeSvhHyEo5gzFzn3BYKmX4NMnn/Z5TTau/Gh yJchPNX5weHauITM1l4j+7gV9GNrp3PnLBcLZabBRoKY8kqqN8GasaXx9AeTpKKoIINZ p/CwsLBazZ+LKNCBCI0y/2q+i1bJ4UmucHmiE=
MIME-Version: 1.0
Received: by 10.50.184.202 with SMTP id ew10mr30964905igc.48.1321418393209; Tue, 15 Nov 2011 20:39:53 -0800 (PST)
Sender: christopher.morrow@gmail.com
Received: by 10.231.202.142 with HTTP; Tue, 15 Nov 2011 20:39:52 -0800 (PST)
In-Reply-To: <E2D346C7800D704DB41ED19D90434DA6320C15DF93@ESESSCMS0358.eemea.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C49308E9E35567@MBCLUSTER.xchange.nist.gov> <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <m2fwhqeq5i.wl%randy@psg.com> <CCE759E6-BEA6-433B-957A-6559C67BAD52@ericsson.com> <DCC302FAA9FE5F4BBA4DCAD4656937791452387941@PRVPEXVS03.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <DCC302FAA9FE5F4BBA4DCAD4656937791452387978@PRVPEXVS03.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <E2D346C7800D704DB41ED19D90434DA6320C15DF93@ESESSCMS0358.eemea.ericsson.se>
Date: Tue, 15 Nov 2011 23:39:52 -0500
X-Google-Sender-Auth: TqrKo6jKznJoGqee_2TpxkJE9WA
Message-ID: <CAL9jLaZZ6=ASKP+U4uix31w4SrBNviOdLQDMqi4eczGv975noA@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Shankar K A <shankar.k.a@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Burstiness of BGP updates
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, 16 Nov 2011 04:39:54 -0000

On Tue, Nov 15, 2011 at 11:06 PM, Shankar K A <shankar.k.a@ericsson.com> wrote:
> I would prefer signed updated over unsigned updates as Jakob suggested.
> But strictly speaking, IMO we should only accept signed updates, because it's the number of AS that we add in the update that we are protecting.
> By accepting unsigned update we may accept unprotected path information.
>

it really is, or was, the intent to permit operators of networks to
decide this on their own. They MAY want to prefer
unsigned/unknown/notfound/naked prefixes for certain things. It's
really not up to us to say, is it? we can SUGGEST that they SHOULD
prefer signed over unsigned, but in the end of the day it's on them.

v2.23.0 | Report a Bug | By Email