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

From: [email-masked]
Date: Wed, 19 Oct 2011 15:45:23 -0700

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:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-01.txt

---

From: "George, Wes" <[email-masked]>
Date: Mon, 31 Oct 2011 13:44:40 -0400

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.

Thanks
Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, October 19, 2011 6:45 PM
> To: [email-masked]
> Cc: [email-masked]
> 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.
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

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.

---

From: Randy Bush <[email-masked]>
Date: Mon, 31 Oct 2011 22:58:43 +0100

> given that current crypto hardware isn't really designed to accelerate
> the types of operations BGPSec would require of it

the extended instructions in westmere and sandy bridge are good for
ecdsa

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

good point

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

probably more appropriate in the protocol document, or an adjunct to it

randy