Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-01.txt

"George, Wes" <> Mon, 31 October 2011 17:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC82D1F0C8C for <>; Mon, 31 Oct 2011 10:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.705
X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SN0OL+Of2Xi3 for <>; Mon, 31 Oct 2011 10:44:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 36F8C1F0C67 for <>; Mon, 31 Oct 2011 10:44:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.69,432,1315195200"; d="scan'208";a="291651275"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 31 Oct 2011 13:40:40 -0400
Received: from ([]) by ([]) with mapi; Mon, 31 Oct 2011 13:44:41 -0400
From: "George, Wes" <>
To: "" <>
Date: Mon, 31 Oct 2011 13:44:40 -0400
Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-01.txt
Thread-Index: AcyOsOPUGs3OYPpdTl+wZ42afk8AigJQgpRw
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Oct 2011 17:44:45 -0000

Intro: I'm wondering whether instead of specifically saying "may require large memory and crypto assist" it would make more sense to discuss this more in terms of the hardware catching up with the software to ensure minimal performance impacts. Especially given that current crypto hardware isn't really designed to accelerate the types of operations BGPSec would require of it, I'm not sure it makes sense to be that specific right now.

Section 3 reuses a good bit of text from sidr-origin-ops regarding placement of caches (local vs remote, "close", etc). Same comments apply here. More to the point, perhaps simply referencing the other document and leaving this one to document things that are specific to BGPSec would be cleaner.

Bgpsec-reqs 3.4 provides a list of operational considerations to discuss. Would probably make sense to ensure that the document covers all of the listed items, perhaps even using those items as section headings for continuity's sake.
As I recommended in my comments on design-reqs, I think that a performance impacts section would be helpful in any discussion of operational considerations. This is especially important for BGPSec since much more of the processing has to happen on-box vs being farmed out to external commodity server hardware.

Wes George

> -----Original Message-----
> From: [] On Behalf Of
> Sent: Wednesday, October 19, 2011 6:45 PM
> To:
> Cc:
> Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-01.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Secure Inter-Domain
> Routing Working Group of the IETF.
>       Title           : BGPsec Operational Considerations
>       Author(s)       : Randy Bush
>       Filename        : draft-ietf-sidr-bgpsec-ops-01.txt
>       Pages           : 10
>       Date            : 2011-10-19
>    Deployment of the BGPsec architecture and protocols has many
>    operational considerations.  This document attempts to collect and
>    present them.  It is expected to evolve as BGPsec is formalized and
>    initially deployed.
> A URL for this Internet-Draft is:
> Internet-Drafts are also available by anonymous FTP at:
> This Internet-Draft can be retrieved at:
> _______________________________________________
> sidr mailing list

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.