> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Christopher Morrow > Sent: Friday, May 11, 2012 2:51 PM > hrm, so... normally something like this happens: > 1) router go boom > 2) troubleshooting ensues to see where the problem is (what to fix) > 3) RE/RSP is determined to be at fault > 4) spares call placed > 5) spare arrives and is placed into the chassis > 6) reboot/checkout happens > 7) customer links brought back online > 8) things return to 'normal' > > I think that at 1 all routing stops (or enough stops that you stop it all > anyway). > [WEG] How prevalent is this scenario going to be in the hardware of sufficient burliness and shiny newness to manage BGPSec in the first place? Isn't it far more likely that the router going boom because of an RE/RP problem is a transient while it switches to the backup, and the sync of the config between primary and backup includes syncing the keys? (and replacing the spare is now only to restore full redundancy) I do think that it's fair to know what the scenario looks like if you have a router that actually does go totally Tango Uniform and has to be resuscitated from spares including rebuilt configs and pushing keys, but I'm thinking that if it's a little more complex, that's not as big of a deal because of the fact that it's likely to be less common.
Wes George 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. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
