-- snip -- >> If we reprioritise BGPSec, we could make it work. Sugestion: >> during bringup, send routes without the BGPSec attribute. > >I think there is a significant risk that this would cause unnecessary >Internet wide churn. > >I would propose and alternative approach. To send the routes with >whatever attributes sender decides to send then with and do it only once. > >Up-on reception if indeed inline CPU processing is an issue on given >platform store the BGPSec related attributes without any processing then >when CPU get's idle .. verify them. > >Hoping that only small fraction of all routes could be considered >invalid you may later withdraw them. > >Of course this only attempts to fix inbound processing issue. You can >not do the same when signing the routes outbound.
Jakob: Robert: The protocol permits the ideas you are proposing -- see Section 4.2. http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-00#section-4.2 The key wording there is: .... it is RECOMMENDED that if the BGPSEC speaker chooses to propagate the route that it generate an update message containing the BGPSEC_Path_Signatures attribute. However, a BGPSEC speaker MAY propagate a route advertisement by generating a (non-BGPSEC) update message that does not contain the BGPSEC_Path_Signatures attribute. Also, the optimizations you mention are included/discussed in Section 5.4 of the draft-sriram-bgpsec-design-choices document: 5.4. Temporary Suspension of Attestations and Validations http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-5.4 Robert seems to be asserting that the router must always sign and propagate the update (if it selected a signed update for best path). However, the current protocol specification allows for dropping BGPSEC_Path_Signatures attribute (potentially for cases when the route-processor is in overload state). Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
