Re: [sidr] Beacons in a separate TCP

"George, Wes" <wesley.george@twcable.com> Sat, 12 November 2011 01:02 UTC

Return-Path: <wesley.george@twcable.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 C54C71F0C3B for <sidr@ietfa.amsl.com>; Fri, 11 Nov 2011 17:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.309
X-Spam-Level:
X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
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 L8h3r2yVg4-D for <sidr@ietfa.amsl.com>; Fri, 11 Nov 2011 17:02:38 -0800 (PST)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C362C1F0C36 for <sidr@ietf.org>; Fri, 11 Nov 2011 17:02:38 -0800 (PST)
X-SENDER-IP: 10.136.163.14
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,496,1315195200"; d="scan'208";a="281272691"
Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 Nov 2011 19:57:51 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 11 Nov 2011 20:02:38 -0500
From: "George, Wes" <wesley.george@twcable.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>, Eric Osterweil <eosterweil@verisign.com>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
Date: Fri, 11 Nov 2011 20:02:59 -0500
Thread-Topic: Beacons in a separate TCP
Thread-Index: AcyfLDg0j50Bi0neROCKFI3By4evPAA6KGgw
Message-ID: <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CC9C@PRVPEXVS03.corp.twcable.com>
References: <7309FCBCAE981B43ABBE69B31C8D21391A44963DA0@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <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: Re: [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: Sat, 12 Nov 2011 01:02:39 -0000

> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of
> Jakob Heitz
>
> 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.

[WEG] I'm not certain I understand how a separate TCP session would make a significant difference. When the update arrives, the router has to do something to it, either process it or slap it into a buffer (RAM or hard drive) for processing when it's less busy.
You could accomplish the same thing by flagging it with different QOS values, instructing the beacon sender to send the updates at pseudo-random intervals, and instructing the receiving router to always process update/withdraw messages before beacons, right? But really, this just ends up being part of the overall base CPU load of the BGPSec implementation. Either the routing system hardware has the scale to run it or it doesn't. If we're down to having to use separate TCP sessions to segregate important updates from less important ones, we have a larger problem IMO.

Wes George

This E-mail and any of its attachments 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 are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and 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 immediately and permanently delete the original and any copy of this E-mail and any printout.