60sec OSPF convergence is pretty bad, and it's not something I'd want to achieve. That said, 100k OSPF routes means you're probably doing something wrong. I would expect any network big enough to have 100k legitimate flowspec entries to also have BGP. Note: the 100k number was Hannes', and I think it's awfully high.
If you really want this to scale you might try to find a distribution method that doesn't use AS-scoped LSAs. Doing this on a campus network means you're asking the smallest OSPF devices to handle a ton of information, and I don't think that's going to work very well. Doing this in a PE-CE context means you're spreading rules around to lots of places they may not need to be. For example, if you have flowspec routes with specific source addresses and you put those routes in parts of the network nowhere near those sources you'll end up burning a ton of scarce network resources unnecessarily. Constraining flowspec routes to BGP may mean you don't push them to the edges of the campus and have to drop traffic at the campus border router, but that's likely to be the most powerful router in the network anwyays. In his other email, Eric Wu said: --- My personal experience, for instance, CELCOM from Malaysia and KPN from Netherland are using ospf in their networks. --- Nobody's arguing that OSPF is rare. My statement was that OSPF *PE-CE* is rare; to Peter's point, perhaps less rare than I think, but I still really doubt there's much of it when compared to BGP. I'm also pretty sure that no VPN provider wants to open themselves up to carry 100k IGP routes per customer, as that's an increase of one or two orders of magnitude in the route counts. If everybody does this it takes a large provider's BGP infrastructure from millions of routes (doable, but not at zero cost) to hundreds of millions of routes. I think you need to think through the operational consequences of pushing a large number of flowspec routes into both the campus IGP and into the provider's VPN infrastructure. Think about efficiency (how do I get the right routes to the right places with a link-state protocol?) and about how you handle failures (what happens if some nodes in an area can't take all the routes?). I understand the spirit of the draft, and it's hard to argue that this sort of DDOS protection is, in spirit, a bad thing. But I don't think that link-state flooding of flowspec routes is the right way to do it. Openflow may be better here - push flow policies to only the points that need them or can handle them. eric -----Original Message----- From: Youjianjie [mailto:youjian...@huawei.com] Sent: Thursday, October 09, 2014 5:24 AM To: Hannes Gredler; Osborne, Eric Cc: ospf@ietf.org Subject: 答复: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt Hi Hannes, Usually there're no more than 100K routes in an area. Route advertisement is related to the network scale, for directly connected neighbors, OSPF's convergence time is about 1 minute for 100K routes. Actually, the signaling for FlowSpec routes and IP prefix routes are almost same. FlowSpec routes can be seen as more specific routing entries. Furthermore in this document, FlowSpec routes are mainly used in DDOS scenarios, instead of replacing the IP prefix routes. Thanks, Jianjie -----邮件原件----- 发件人: Hannes Gredler [mailto:han...@juniper.net] 发送时间: 2014年10月8日 23:54 收件人: Osborne, Eric 抄送: Youjianjie; ospf@ietf.org 主题: Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt +1 it would be furthermore interesting to hear from the authors how OSPF behaves once a massive scale of flow-routes (lets say in the order of > 100K is injected into OSPF). /hannes On Wed, Oct 08, 2014 at 03:45:24PM +0000, Osborne, Eric wrote: | I'm not sure this has much value. The vast majority of dynamic PE-CE is done with BGP; the little bit that isn't BGP is, in my experience, RIP. I don't think I've seen many (any?) OSPF PE-CE deployments. | | | | | eric | | -----Original Message----- | From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Youjianjie | Sent: Tuesday, October 07, 2014 10:11 PM | To: ospf@ietf.org | Subject: [OSPF] 转发: New Version Notification for | draft-liang-ospf-flowspec-extensions-01.txt | | Hi all, | | This document discusses the use cases that OSPF is used to distribute FlowSpec routes. This document also defines a new OSPF FlowSpec Opaque Link State Advertisement (LSA) encoding format. | Your comments are appreciated. | | Best Regards, | Jianjie | | -----邮件原件----- | 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] | 发送时间: 2014年9月28日 10:32 | 收件人: Youjianjie; Youjianjie; liuweihang; liuweihang | 主题: New Version Notification for | draft-liang-ospf-flowspec-extensions-01.txt | | | A new version of I-D, draft-liang-ospf-flowspec-extensions-01.txt | has been successfully submitted by Jianjie You and posted to the IETF repository. | | Name: draft-liang-ospf-flowspec-extensions | Revision: 01 | Title: OSPF Extensions for Flow Specification | Document date: 2014-09-27 | Group: Individual Submission | Pages: 11 | URL: http://www.ietf.org/internet-drafts/draft-liang-ospf-flowspec-extensions-01.txt | Status: https://datatracker.ietf.org/doc/draft-liang-ospf-flowspec-extensions/ | Htmlized: http://tools.ietf.org/html/draft-liang-ospf-flowspec-extensions-01 | Diff: http://www.ietf.org/rfcdiff?url2=draft-liang-ospf-flowspec-extensions-01 | | Abstract: | This document discusses the use cases why OSPF (Open Shortest Path | First) distributing flow specification (FlowSpec) routes is | necessary. This document also defines a new OSPF FlowSpec Opaque | Link State Advertisement (LSA) encoding format that can be used to | distribute FlowSpec routes. | | For the network only deploying IGP (Interior Gateway Protocol) (e.g. | OSPF), it is expected to extend IGP to distribute FlowSpec routes. | One advantage is to mitigate the impacts of Denial-of-Service (DoS) | attacks. | | | | | | Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. | | The IETF Secretariat | | _______________________________________________ | OSPF mailing list | OSPF@ietf.org | https://www.ietf.org/mailman/listinfo/ospf | _______________________________________________ | OSPF mailing list | OSPF@ietf.org | https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
