Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

["Osborne, Eric" <[e-mail]>]

The validation rules don't help you with a link-state protocol, though.  You still have to flood all the flowspec routes everywhere.  And yeha, you can configure the maximum amount, but what happens if a node receives more than that maximum?  Which ones does it leave out?

As far as OpenFlow, yes, controller scale is an issue.  There appears to be an entire industry building itself around solving this problem.



eric

-----Original Message-----
From: Youjianjie [mailto:[e-mail]] 
Sent: Friday, October 10, 2014 6:04 AM
To: Osborne, Eric; Hannes Gredler
Cc: [e-mail]
Subject: 答复: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

Hi Eric, et al,

Thanks for your comments! We do need to think about the network scale and efficiency issues.
 
Some of them we have considered before, but not reflected in the draft. For example, we can do the similar validation procedure as described in section 6 of [RFC5575] (Dissemination of Flow Specification Rules). i.e., only those FlowSpec entries passing the validation will be handled. 
Also in our draft, a new FlowSpec capability is defined. Only those routers supporting this capability will handle FlowSpec entries. This capability can be configured locally. Actually, for the small-to-medium sized networks, the total amount of FlowSpec entries is limited. Additionally, the maximum amount of FlowSpec entries on FlowSpec capable routers can be configured too. So we think these issues can be solved.

Regarding OpenFlow, if there're lots of points need the FlowSpec entries, then the controller has to communicate with all of them. This maybe be a challenge for the controller. 

Thanks,
Jianjie

-----邮件原件-----
发件人: Osborne, Eric [mailto:[e-mail]]
发送时间: 2014年10月9日 20:31
收件人: Youjianjie; Hannes Gredler
抄送: [e-mail]
主题: RE: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

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:[e-mail]]
Sent: Thursday, October 09, 2014 5:24 AM
To: Hannes Gredler; Osborne, Eric
Cc: [e-mail]
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:[e-mail]]
发送时间: 2014年10月8日 23:54
收件人: Osborne, Eric
抄送: Youjianjie; [e-mail]
主题: 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:[e-mail]] On Behalf Of Youjianjie
| Sent: Tuesday, October 07, 2014 10:11 PM
| To: [e-mail]
| 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
| 
| -----邮件原件-----
| 发件人: [e-mail] [mailto:[e-mail]]
| 发送时间: 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
| [e-mail]
| https://www.ietf.org/mailman/listinfo/ospf
| _______________________________________________
| OSPF mailing list
| [e-mail]
| https://www.ietf.org/mailman/listinfo/ospf