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

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

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2CC1ACED9 for <ospf@ietfa.amsl.com>; Thu, 9 Oct 2014 06:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4kcMUEeOvtT for <ospf@ietfa.amsl.com>; Thu, 9 Oct 2014 06:47:14 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97AD1ACECE for <ospf@ietf.org>; Thu, 9 Oct 2014 06:47:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: AkkFAHORNlStJV2Q/2dsb2JhbABfgw5TUwUEgwLICgyHSwIZbhYBe4QDAQEBAwEBAQExOgkCBQcEAgEGAhEEAQEBBCMFAgIlCxQJCAIEAQ0FCYgtCAgFkhqcRwiUTAEXgSiJIoUYEQEdGBsHBoJtgVgBBJF5hEKCQoROgS48gwqNH4N+gXIYFoFDbIEPOYECAQEB
X-IronPort-AV: E=Sophos;i="5.04,684,1406592000"; d="scan'208";a="85438470"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP; 09 Oct 2014 13:47:13 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-8.cisco.com (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 xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 08:47:12 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Osborne, Eric" <eric.osborne@level3.com>, Youjianjie <youjianjie@huawei.com>, Hannes Gredler <hannes@juniper.net>
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: <D05C07DB.4A98%acee@cisco.com>
References: <F6C28B32DA084644BB6C8D0BD65B669D11A0A9@nkgeml509-mbs.china.huawei.com> <63CB93BC589C1B4BAFDB41A0A19B7ACDF930C2@USIDCWVEMBX08.corp.global.level3.com> <20141008155350.GB34437@hannes-mba.local> <F6C28B32DA084644BB6C8D0BD65B669D11A486@nkgeml509-mbs.china.huawei.com> <63CB93BC589C1B4BAFDB41A0A19B7ACDF93F22@USIDCWVEMBX08.corp.global.level3.com>
In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACDF93F22@USIDCWVEMBX08.corp.global.level3.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="gb2312"
Content-ID: <1F582550CDD6D245A26D2BEE14A2F521@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/-1yTPSvM2pIwS6ettG23gYYLx9c
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] New Version Notification for draft-liang-ospf-flowspec-extensions-01.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Oct 2014 13:47:17 -0000


On 10/9/14, 8:31 AM, "Osborne, Eric" <eric.osborne@level3.com> 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 




>
>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:youjianjie@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:hannes@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-bounces@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-drafts@ietf.org [mailto:internet-drafts@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-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:
>|    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