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

Xuxiaohu <xuxiaohu@huawei.com> Sat, 11 October 2014 01:39 UTC

Return-Path: <xuxiaohu@huawei.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 E980A1A039C for <ospf@ietfa.amsl.com>; Fri, 10 Oct 2014 18:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.387
X-Spam-Level:
X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 W_LnWyi1dAXu for <ospf@ietfa.amsl.com>; Fri, 10 Oct 2014 18:39:25 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7591A039B for <ospf@ietf.org>; Fri, 10 Oct 2014 18:39:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKK76144; Sat, 11 Oct 2014 01:39:22 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 11 Oct 2014 02:39:20 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Sat, 11 Oct 2014 09:39:09 +0800
From: Xuxiaohu <xuxiaohu@huawei.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: AQHP5ID7X6P8kfIrXUKwt34LNaKEp5wqGWmQ
Date: Sat, 11 Oct 2014 01:39:09 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082C0509@NKGEML512-MBS.china.huawei.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> <F6C28B32DA084644BB6C8D0BD65B669D11A7AE@nkgeml509-mbs.china.huawei.com> <63CB93BC589C1B4BAFDB41A0A19B7ACDF95376@USIDCWVEMBX08.corp.global.level3.com>
In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACDF95376@USIDCWVEMBX08.corp.global.level3.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/MZZlhvMm4DLkGtln_S__-sd8yB0
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: Sat, 11 Oct 2014 01:39:28 -0000


> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Osborne, Eric
> Sent: Friday, October 10, 2014 7:54 PM
> To: Youjianjie; Hannes Gredler
> Cc: ospf@ietf.org
> Subject: Re: [OSPF] New Version Notification for
> draft-liang-ospf-flowspec-extensions-01.txt
> 
> 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
> 
> -----Original Message-----
> From: Youjianjie [mailto:youjianjie@huawei.com]
> Sent: Friday, October 10, 2014 6:04 AM
> To: Osborne, Eric; Hannes Gredler
> Cc: ospf@ietf.org
> 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:eric.osborne@level3.com]
> 发送时间: 2014年10月9日 20:31
> 收件人: Youjianjie; Hannes Gredler
> 抄送: ospf@ietf.org
> 主题: 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: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-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