[sidr] Beacons in a separate TCP

Jakob Heitz <jakob.heitz@ericsson.com> Wed, 09 November 2011 22:11 UTC

Return-Path: <jakob.heitz@ericsson.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 DD00321F84A2 for <sidr@ietfa.amsl.com>; Wed, 9 Nov 2011 14:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.147
X-Spam-Level:
X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 iYQxBJTrHPUD for <sidr@ietfa.amsl.com>; Wed, 9 Nov 2011 14:11:10 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE40B21F84A1 for <sidr@ietf.org>; Wed, 9 Nov 2011 14:11:09 -0800 (PST)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA9MAm8J006410; Wed, 9 Nov 2011 16:11:09 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 9 Nov 2011 17:11:01 -0500
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Eric Osterweil <eosterweil@verisign.com>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
Date: Wed, 09 Nov 2011 17:11:00 -0500
Thread-Topic: Beacons in a separate TCP
Thread-Index: AcyfLDg0j50Bi0neROCKFI3By4evPA==
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A44963DA0@EUSAACMS0701.eamcs.ericsson.se>
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
Cc: sidr wg list <sidr@ietf.org>
Subject: [sidr] Beacons in a separate TCP
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, 09 Nov 2011 22:11:11 -0000

The beacons will be unlikely to come like the slow constant
drizzle of Seattle weather, but more like the quick cloudbursts
of Miami weather. Just guessing.

Such beacons will cause head-of-line blocking for more
urgent updates behind them. Beacons can be delayed for
hours without consequence. Not so for other updates.

I think beacons should be transmitted in a TCP session
separate from the normal BGP traffic, so as not to delay
that.

--
Jakob Heitz.

> -----Original Message-----
> From: Eric Osterweil [mailto:eosterweil@verisign.com]
> Sent: Wednesday, November 09, 2011 12:37 PM
> To: Sriram, Kotikalapudi
> Cc: Jakob Heitz; sidr wg list
> Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
> 
> Hey Sriram, Russ, and Jakob,
> 
> Thanks for the #s.  I think I get the general notion that adding n
> updates per day per prefix equals (n * #prefixes)/1. :)  I guess my
> question was kinda vague, sorry.  Upon reexamination, I see that I
> said "overhead" without being specific.  Since we can use the
> updates that are generated today to measure how much (for example)
> bandwidth is already needed, can we calculate how much extra
> bandwidth universal deployment would mean?  Also, perhaps this would
> be most informative in the form of a ratio (i.e. a factor of $x$
> increase).  That way, when people look at events like the one that
> the "General Internet Instability" thread that just happened on
> NANOG refer to, they can gauge the update amplification that was
> seen against what _would_ be seen given bgpsec.  I think this
> actually kind of came up on nanog, so it seems like maybe it would
> be a relevant thing to look at here?
> 
> Anyway, I guess I was mostly just curious about what kinds of
> evaluations have been done, thanks. :)
> 
> Eric
> 
> On Nov 8, 2011, at 12:19 PM, Sriram, Kotikalapudi wrote:
> 
> > Now the ops doc has much longer beaconing interval recommendations
> for
> > what you may consider a normal prefix.
> >
> > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-01#section-7
> >
> > 	Normal Prefix:  Most prefixes SHOULD announce with a
> signature
> > 	validity of a week and beacon every three days.
> >
> > Sriram
> >
> > -----Original Message-----
> > From: Jakob Heitz [mailto:jakob.heitz@ericsson.com]
> > Sent: Tuesday, November 08, 2011 12:09 PM
> > To: Sriram, Kotikalapudi
> > Cc: Christopher Morrow; Eric Osterweil; sidr wg list
> > Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
> >
> > Proposal was 24 hour beacon timeout and 3 beacons per timeout.
> That makes 3 beacons per day.
> >
> > --
> > Jakob Heitz.
> >
> >