On 4/1/11 8:37 AM, Andrei Robachevsky wrote:
Hi,
I propose the inclusion of the following requirement:
3.x A BGPsec design should not decrease the performance characteristics
of the BGP, nor have a negative impact on the overall resilience of the
routing system.
"should not decrease" seems a bit literal and restrictive. One could
argue that no addition of a feature that put more bits on the wire could
meet that goal.
Maybe the operative requirement is that the performance implications
with respect to convergence be clearly defined (in an algorithmic sense
(e.g., require 1 RSA/SHA verification per hop, and the addition of x
bytes of new attributes per hop).
Maybe some follow up bench marking of independent implementations in the
protocol report later would further clarify the issue.
All other characterizations of larger impacts on convergence will be
based upon models ... and more speculative.
As for resilience, I think it also key to document what factors might
influence resilience issues of BGPSEC operations (e.g., distribution of
global RPKI data, etc).
One should also note that the goal of this protocol is to improve the
resilience of the system ... ;^).
As it stands now, BGPSEC is opt-in. So it seems that clearly
documenting these issues is more operative than make absolute
requirements about them.
Examples that I have in mind is the convergence time or a solution that
can make the global routing system more fragile (e.g. an expired
signature blacking out a significant part of the Internet). Perhaps that
should also be covered in the deployment considerations, since this
depends partly on local policy decisions.
Andrei
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
