On Wed, Dec 26, 2012 at 12:37 PM, Sriram, Kotikalapudi <kotikalapudi.sri...@nist.gov> wrote: >> >> However, I would note that the use case I've outlined above is more broad >> than 'just' DDoS attack. Specifically, think of "natural or man-made >> disasters". In the latter case, it's often the case that a customer's >> primary DataCenter is taken offline and, although they [may] have a >> secondary/backup DataCenter, they hadn't adequately provisioned capacity >> into it. In those cases, the answer is, generally, to bypass the undersized >> physical equipment/tail-circuit/whatever in order to restore service as >> quickly as possible. In the example diagram I've highlighted above, this >> could involve removing an undersized CE router from the physical path >> between my PE and their server farm, (because it's physical interfaces, >> processing power, whatever are not adequately sized). >> > > Would it be possible to leave the BGP session intact from their CE to your PE? > If not, can a new BGP session (possibly over a TCP session that may go over > multiple physical hops if necessary) be set up between your PE and the > customer? Customer could even use a simple PC emulating a BGP router to do > this. Then they can originate their own prefix and directly pass the > announcement to your PE; the update could be unsigned (when there is > origin-only validation) or signed in the future (when there is path > validation). > >>
I don't know that solving the many examples with many different solutions one at a time is helping here... In general: 1) there are cases where some relationship exists before the 'event', whatever that event may be 2) there are cases where no relationship exists before the 'event'. In both cases there are a myriad of solutions in place today, some of which will be complicated in a more 'bgpsec' world (or a more RPKI world). Making the potential new world be as nimble as the old seems to be what Shane/Danny are aiming for, right? Ratholing on the 12 sins of christmas doesn't seem helpful to the overall goal. -chris _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
