Providing some comments on the drafts as a whole. BGPsec Protocol spec - Section 4 requires that each update contain only one NLRI. While you explained in the presentation why this is, it is not adequately explained in the draft. Since this is a significant change, and is currently based on a technical limitation, please explain it here.
As stated at the mic, please consider a second (or third) state of validation - expired. It may be that different policy should be applied in these cases vs. known invalid. BGP Sec Overview - 3.2 talks about the recursive nature of the validation. It is probably worth noting that this is going to have at least some impact on convergence times - long AS paths may take longer to validate than shorter ones, for example, where this isn't really variable today. This may be an issue depending on how the validation is implemented and the order the updates come in, especially if you parallelize the processing of updates (that is, the router is still chewing on validation of one update while the next one is being processed on a different core) - it can cause route churn as one route is preferred and then discarded to pick up another, etc. This churn is a known issue on initial convergence, but there is often machinery in routers to allow for prioritization of certain prefixes, certain prefix lengths, etc to limit its effects. I am mainly saying that you should consider the implications of this. Worth discussing if it's even an option to consider parallelization of validation *within* a given update (feed one AS signature to each core so that you're processing multiples at once, for example) - I know we're not at the design optimization phase yet, but if there's a technical reason why this isn't possible or isn't recommended, might be worth making it clear. 4.3 - use case : while I understand we're talking about dumping AS-sets, I think that replace-AS to eliminate private AS is a valid use case that has to be supported by this implementation. It may be that we have to assume that the AS that is serving as the replacement is also serving as the originator and signing on behalf of the upstream private ASN, but that should be explicitly documented if that's what we're aiming for. Operational considerations - As I and others stated at the mic, while we're not expecting formal estimates of something that is in a pre-optimization stage of design, rough orders of magnitude in terms of the impact to processing and convergence time, CPU, and RIB memory are all things that would be extremely helpful in evaluating this. Assuming a certain crypto algorithm, what would the expected size of a single update be when compared with today, for example? Since we're not packing, the research that has been done to show that packing isn't that important should be directly referenced here, etc. We know that the design team considered scale and convergence as a top priority, but that's not well-covered in the current drafts. Security considerations - the same issues as origin validation has with existing routing policy (local pref, for example) being able to create a situation where an invalid route is preferred over a valid one should be either discussed here or referenced from the other document. Thanks, Wes _________________________________ Wesley George Sprint Core Network Engineering - IP O: 703-592-4847 M:703-864-4902 http://www.sprint.net Please note new office phone# This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
