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

From: Youjianjie <[email-masked]>
Date: Wed, 8 Oct 2014 02:11:18 +0000

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

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 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

---

From: "Osborne, Eric" <[email-masked]>
Date: Wed, 8 Oct 2014 15:45:24 +0000

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:[email-masked]] On Behalf Of Youjianjie
Sent: Tuesday, October 07, 2014 10:11 PM
To: [email-masked]
Subject: [OSPF] 转发: New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

Hi all,

Best Regards,
Jianjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2014年9月28日 10:32
收件人: Youjianjie; Youjianjie; liuweihang; liuweihang
主题: New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

Abstract:

                                                                                  

The IETF Secretariat

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 8 Oct 2014 17:53:50 +0200

+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:[email-masked]] On Behalf Of Youjianjie
| Sent: Tuesday, October 07, 2014 10:11 PM
| To: [email-masked]
| 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
| 
| -----邮件原件-----
| 发件人: [email-masked] [mailto:[email-masked]] 
| 发送时间: 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
| [email-masked]
| https://www.ietf.org/mailman/listinfo/ospf
| _______________________________________________
| OSPF mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/ospf

---

From: Peter Psenak <[email-masked]>
Date: Wed, 08 Oct 2014 18:16:04 +0200

Hi Eric,

there are definitely deployments using OSPF as PE-CE. It's typically 
used for enterprise customers, that use OSPF as their IGP and use L3 VPN 
service to interconnect their sites.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 8 Oct 2014 16:36:19 +0000

Hi Peter, et al, 
I’ve also seen many OSPF PE-CE deployments as well. One question is whether the CE is under the administrative control of the provider or the customer? 
Note that this was proposed at least once before - http://www.ietf.org/archive/id/draft-shrivastava-ospf-flow-spec-01.txt bit it didn’t gain momentum. 

With respect to Hannes’ comment, Les Ginsberg said he sees this as a candidate for the ISIS Generic Information instance (RFC 6823). We could do the same and push it to the OSPF transport instance which has also lost momentum as a draft. 

We’ve heard from one provider (Eric) who doesn’t think this is useful - any other input?  

One thing I hope is that no sees this a generic flow-spec distribution mechanism for SDN. The reason being that you really need per peer granularity of advertisement and policy, e.g. BGP. 

Thanks,
Acee 

On Oct 8, 2014, at 12:16 PM, Peter Psenak <[email-masked]> wrote:

> Hi Eric,
> 
> there are definitely deployments using OSPF as PE-CE. It's typically used for enterprise customers, that use OSPF as their IGP and use L3 VPN service to interconnect their sites.
> 
> thanks,
> Peter
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 9 Oct 2014 05:15:14 +0000

Adding the IS-IS WG since there is an equivalent draft for IS-IS submitted by the same authors.

"IF" this were something the respective WGs decide the protocol should support, then running a separate instance of the protocol so that the flowspec  advertisements can be isolated from the primary function of the IGP (routing) would be the right way to implement it - and this is precisely what GENINFO/MI (RFC 6823/6822) were defined to address. OSPF Transport instance would be the analogous mechanism for OSPF.

But the first question is whether this is something the IGPs should support at all. As Acee has indicated this was proposed previously in OSPF and there was little interest. In the case of IS-IS there is even less reason to consider it since IS-IS is NOT deployed as a PE-CE protocol.

   Les

> From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem
> (acee)
> Sent: Wednesday, October 08, 2014 9:36 AM
> To: Peter Psenak (ppsenak)
> Cc: [email-masked]
> Subject: Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-
> extensions-01.txt
> 
> Hi Peter, et al,
> I’ve also seen many OSPF PE-CE deployments as well. One question is
> whether the CE is under the administrative control of the provider or the
> customer?
> Note that this was proposed at least once before -
> http://www.ietf.org/archive/id/draft-shrivastava-ospf-flow-spec-01.txt bit
> it didn’t gain momentum.
> 
> With respect to Hannes’ comment, Les Ginsberg said he sees this as a
> candidate for the ISIS Generic Information instance (RFC 6823). We could do
> the same and push it to the OSPF transport instance which has also lost
> momentum as a draft.
> 
> One thing I hope is that no sees this a generic flow-spec distribution
> mechanism for SDN. The reason being that you really need per peer
> granularity of advertisement and policy, e.g. BGP.
> 
> Thanks,
> Acee
> 
> > there are definitely deployments using OSPF as PE-CE. It's typically used
> for enterprise customers, that use OSPF as their IGP and use L3 VPN service
> to interconnect their sites.
> >
> > thanks,
> > Peter
> >
> >> 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
> >>
> >> 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.
> >> 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
> >>

---

From: Youjianjie <[email-masked]>
Date: Thu, 9 Oct 2014 09:23:45 +0000

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:[email-masked]] 
发送时间: 2014年10月8日 23:54
收件人: Osborne, Eric
抄送: Youjianjie; [email-masked]
主题: 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

| Subject: [OSPF] 转发: New Version Notification for 
| draft-liang-ospf-flowspec-extensions-01.txt
| 主题: New Version Notification for 
| draft-liang-ospf-flowspec-extensions-01.txt

---

From: "Osborne, Eric" <[email-masked]>
Date: Thu, 9 Oct 2014 12:31:09 +0000

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:[email-masked]] 
Sent: Thursday, October 09, 2014 5:24 AM
To: Hannes Gredler; Osborne, Eric
Cc: [email-masked]
Subject: 答复: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

Hi Hannes,

Thanks,
Jianjie

-----邮件原件-----
发件人: Hannes Gredler [mailto:[email-masked]]
发送时间: 2014年10月8日 23:54
收件人: Osborne, Eric
抄送: Youjianjie; [email-masked]
主题: Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

+1

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 9 Oct 2014 14:37:42 +0200

On Thu, Oct 09, 2014 at 12:31:09PM +0000, Osborne, Eric wrote:
| 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.  

yes, apologies - i have this unpleasant habit of asking the scaling questions first ;-)

it should be obvious that the OSPF control-plane (zero-window protocol, no flow-control)
is not particular well suited for distributing that amount of state information,
which gets me to the question "is an IGP the right place for this"

/hannes

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 9 Oct 2014 13:47:11 +0000

On 10/9/14, 8:31 AM, "Osborne, Eric" <[email-masked]> wrote:

>60sec OSPF convergence is pretty bad, and it's not something I'd want to
>achieve. 

I’d agree unless you’re talking about bringing up a large number of
neighbors with 100K routes from scratch. OSPF, as a protocol, is I/O
bound. 

> 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.

As I stated in my last E-mail, the IGPs aren’t really a good tool for
generic flow-spec distribution. Other than perhaps DDoS mitigation, I
don’t see a real use case for flooding the same flow-spec to everyone in
the routing domain or, even worse, flooding everybody’s flow-specs
everywhere.

>
>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.

You make a good point. There is also the question of administrative
control. Are SP customers going to want to let ISPs inject flow-specs for
DDoS attacks into their routing domains? For L3VPN OSPF PE-CE, the SP are
advertising routes but these are, in fact, the customer’s routes.

Thanks,
Acee 

>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
>
>
>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
>
>-----邮件原件-----
>主题: 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
>
>| 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
>| 
>| This document discusses the use cases that OSPF is used to distribute
>| URL:            
>http://www.ietf.org/internet-drafts/draft-liang-ospf-flowspec-extensions-0
>1.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:
>| Please note that it may take a couple of minutes from the time of

---

From: Youjianjie <[email-masked]>
Date: Fri, 10 Oct 2014 10:03:44 +0000

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:[email-masked]] 
发送时间: 2014年10月9日 20:31
收件人: Youjianjie; Hannes Gredler
抄送: [email-masked]
主题: RE: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

---

eric

-----Original Message-----
From: Youjianjie [mailto:[email-masked]]
Sent: Thursday, October 09, 2014 5:24 AM
To: Hannes Gredler; Osborne, Eric
Cc: [email-masked]
Subject: 答复: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

Hi Hannes,

Thanks,
Jianjie

-----邮件原件-----
发件人: Hannes Gredler [mailto:[email-masked]]
发送时间: 2014年10月8日 23:54
收件人: Osborne, Eric
抄送: Youjianjie; [email-masked]
主题: Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

+1

/hannes

---

From: "Osborne, Eric" <[email-masked]>
Date: Fri, 10 Oct 2014 11:54:29 +0000

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:[email-masked]] 
Sent: Friday, October 10, 2014 6:04 AM
To: Osborne, Eric; Hannes Gredler
Cc: [email-masked]
Subject: 答复: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

Hi Eric, et al,

Thanks,
Jianjie

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

---

eric

-----Original Message-----
From: Youjianjie [mailto:[email-masked]]
Sent: Thursday, October 09, 2014 5:24 AM
To: Hannes Gredler; Osborne, Eric
Cc: [email-masked]
Subject: 答复: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

Hi Hannes,

Thanks,
Jianjie

-----邮件原件-----
发件人: Hannes Gredler [mailto:[email-masked]]
发送时间: 2014年10月8日 23:54
收件人: Osborne, Eric
抄送: Youjianjie; [email-masked]
主题: Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

+1

/hannes

---

From: "Mike Dubrovskiy (mdubrovs)" <[email-masked]>
Date: Fri, 10 Oct 2014 18:07:18 +0000

Ideal solution would be to use separate ospf transport topology.
And ideally sparse transport topology should be able to do automatic self-healing if partitioned.

But in real world - proposed solution to flood everywhere
is a good engineering compromise between implementation 
/ deployment complexity and giving network  administrators new functionality.

We can say in the draft that it could be done either way and the separate topology is preferred
when fast convergence is important.

Thank you,
Mike

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Osborne, Eric
Sent: Friday, October 10, 2014 4:54 AM
To: Youjianjie; Hannes Gredler
Cc: [email-masked]
Subject: Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

eric

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

Hi Eric, et al,

Thanks,
Jianjie

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

---

eric

-----Original Message-----
From: Youjianjie [mailto:[email-masked]]
Sent: Thursday, October 09, 2014 5:24 AM
To: Hannes Gredler; Osborne, Eric
Cc: [email-masked]
Subject: 答复: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

Hi Hannes,

Thanks,
Jianjie

-----邮件原件-----
发件人: Hannes Gredler [mailto:[email-masked]]
发送时间: 2014年10月8日 23:54
收件人: Osborne, Eric
抄送: Youjianjie; [email-masked]
主题: Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt

+1

/hannes

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 11 Oct 2014 01:39:09 +0000

> Sent: Friday, October 10, 2014 7:54 PM
> Subject: Re: [OSPF] New Version Notification for
> 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?

Assume the target network is a small-to-medium sized network where a limited number of flowspec entires is usually enough, as the whole network is well-managed and fully under the control of the operators, by limiting the maximum amount of flowspec entries to be originated on each router which is allowed to originate flowspec related LSAs, the overflow concerns that you had mentioned can be addressed. 

Best regards,
Xiaohu

> As far as OpenFlow, yes, controller scale is an issue.  There appears to be an
> entire industry building itself around solving this problem.
> 
> 
> 
> eric
> 
> 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
> 
> -----邮件原件-----
> 主题: RE: [OSPF] New Version Notification for
> 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.
> 
> 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
> 
> 
> 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
> 
> -----邮件原件-----
> 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
> 
> | 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
> |
> | 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.
> http://www.ietf.org/internet-drafts/draft-liang-ospf-flowspec-extensions-01.txt
> | Status:
> | 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
> |

---

From: "Russ White" <[email-masked]>
Date: Sat, 11 Oct 2014 10:07:40 -0400

> As I stated in my last E-mail, the IGPs aren't really a good tool for
generic
> flow-spec distribution. Other than perhaps DDoS mitigation, I don't see a
real
> use case for flooding the same flow-spec to everyone in the routing domain
> or, even worse, flooding everybody's flow-specs everywhere.

Agreed. It always looks more and more like we need a "generic transport
protocol" for flooding various bits of information through a domain. We seem
to consistently reject the idea, and then we consistently have ideas thrown
around about how to do this very same thing in some existing protocol...

Let's just add another AFI to BGP. :-)

Anyway, OSPF isn't the right place for this sort of thing.

:-)

Russ

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 11 Oct 2014 15:04:35 +0000

Hey Russ, 

>around about how to do this very same thing in some existing protocol...

OSPF is a good choice for quickly disseminating the same piece of
information to multiple OSPF routers using the same policy and I believe
that the transport instance
http://www.ietf.org/id/draft-ietf-ospf-transport-instance-11.txt
facilitates this. However, I see flow-spec distribution in the general
controller case as being peer specific or even peer interface specific. Do
you disagree? 

The use case in question is mitigating attacks closer to the compromised
system by pushing the flow-spec to the customer sites using OSPF as a
PE-CE protocol (RFC 4577). Are there any other instances where we¹d want
to push the same flow-spec to the routers in an IGP domain using OSPF or
ISIS? 

Thanks,
Acee

---

From: "Russ White" <[email-masked]>
Date: Sat, 11 Oct 2014 11:30:07 -0400

> OSPF is a good choice for quickly disseminating the same piece of
information
> to multiple OSPF routers using the same policy and I believe that the
> transport instance http://www.ietf.org/id/draft-ietf-ospf-transport-
> instance-11.txt
controller
> case as being peer specific or even peer interface specific. Do you
disagree?

> system by pushing the flow-spec to the customer sites using OSPF as a
PE-CE
> protocol (RFC 4577). Are there any other instances where we¹d want to push
> the same flow-spec to the routers in an IGP domain using OSPF or ISIS?

Why isn't this use case extendable to all edge OSPF routers, and not just
CE's? I would think the same reasoning would apply...

So -- if we are going to do this, we should specifically design it more like
a type 5, perhaps, or something with a very limited flooding scope to solve
the specific use case in hand, rather than in a way that encourages general
use...

Does this make sense?

:-)

Russ

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 11 Oct 2014 19:10:43 +0000

>the specific use case in hand, rather than in a way that encourages

It depends whether you want to send the flow-spec to every PE under your
administrative domain of only those PE close to the source of the attack.
If it is the latter, the current BGP mechanism Is better suited to the
task. 

Thanks,
Acee