On Fri, 11 Jan 2013, SM wrote:
You seem to be asking about failures by entities outside your control and an "off" switch to avoid it from affecting your organization. draft-ietf-sidr-bgpsec-threats-03 doesn't get into that.
Well, both for me and for the other organisation. If they find out their information is corrupt and they don't know exactly how to fix it quickly, they should be able to send out something that recursively just turns off all filtering based on their entire information set.
What's important to realise is that the current state of affairs is that major outages are caused very rarely by fat-fingering or intentional disrupting the global BGP system. Getting origin verification is an extreme complication of this system that potentially can cause a lot more outages than the ones caused by not having it.
I still think origin verification is important and I want to have it, but it needs to be robust (as a complete system). A lot can be fixed by operational procedures (=money and time), but I really hope extra care is put into the design of it as well, to make it operationally more robust and easier to use. Also recommendations on what needs to be done over time to keep it running would be good.
Then I agree that actual operational procedures are probably best produced on the NOG and RIR level, but input from the designers would probably help here.
-- Mikael Abrahamsson email: [email protected] _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
