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

"Acee Lindem (acee)" <> Thu, 09 October 2014 13:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3F2CC1ACED9 for <>; Thu, 9 Oct 2014 06:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -11.898
X-Spam-Status: No, score=-11.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L4kcMUEeOvtT for <>; Thu, 9 Oct 2014 06:47:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B97AD1ACECE for <>; Thu, 9 Oct 2014 06:47:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10868; q=dns/txt; s=iport; t=1412862434; x=1414072034; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XfesKfnmgq+uFXMl57SRDR09dteieOS66mqseBc2O2w=; b=g2yxg4ooZmGSeZoX2ggXTaFmiaNMiPkPnqB4PNO4yDVIYu7H6WJUD/Bw NfPicKZj7Nt8xQBbF3lDja6gZNjruzDCN/L+VThEZ+mLrXVpimp8hvtma zJudS5eZvXb2/oq66ITdfmvBI7Ztz4InGVeeBNI/Zk7S/x8s8bgcD9t97 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,684,1406592000"; d="scan'208";a="85438470"
Received: from ([]) by with ESMTP; 09 Oct 2014 13:47:13 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s99DlCkK010953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 13:47:12 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 08:47:12 -0500
From: "Acee Lindem (acee)" <>
To: "Osborne, Eric" <>, Youjianjie <>, Hannes Gredler <>
Thread-Topic: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt
Thread-Index: AQHP2sRacNlB1LfkPUCKV4l1MfxdD5wX3ddwgA2jYQCAAOUi0P//fhsAgAGjdgCAADkxoIAAKSoA
Date: Thu, 9 Oct 2014 13:47:11 +0000
Message-ID: <>
References: <> <> <20141008155350.GB34437@hannes-mba.local> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Oct 2014 13:47:17 -0000

On 10/9/14, 8:31 AM, "Osborne, Eric" <> wrote:

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

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

> 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

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


>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.
>-----Original Message-----
>From: Youjianjie []
>Sent: Thursday, October 09, 2014 5:24 AM
>To: Hannes Gredler; Osborne, Eric
>Subject: 答复: [OSPF] New Version Notification for
>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.
>发件人: Hannes Gredler []
>发送时间: 2014年10月8日 23:54
>收件人: Osborne, Eric
>抄送: Youjianjie;
>主题: Re: [OSPF] New Version Notification for
>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).
>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 [] On Behalf Of Youjianjie
>| Sent: Tuesday, October 07, 2014 10:11 PM
>| To:
>| 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
>| -----邮件原件-----
>| 发件人: []
>| 发送时间: 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
>| 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:            
>| Status:         
>| Htmlized:       
>| Diff:           
>| 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
>| The IETF Secretariat
>| _______________________________________________
>| OSPF mailing list
>| _______________________________________________
>| OSPF mailing list
>OSPF mailing list