Re: [Idr] New Version Notification for draft-liang-idr-flowspec-orf-00.txt
Robert Raszuk <robert@raszuk.net> Sat, 30 May 2015 09:24 UTC
Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B8C1A1A7F for <idr@ietfa.amsl.com>; Sat, 30 May 2015 02:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 a098xGA1_Mj0 for <idr@ietfa.amsl.com>; Sat, 30 May 2015 02:24:45 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A981A1A78 for <idr@ietf.org>; Sat, 30 May 2015 02:24:45 -0700 (PDT)
Received: by wicmx19 with SMTP id mx19so33168973wic.0 for <idr@ietf.org>; Sat, 30 May 2015 02:24:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZHwufhIOQmR9fO9cqd/OGJSszdTpwCvVJ8C/cPHDBH0=; b=ue0I3xlux/n3oNVzQ2i1+MM1ycvXlOER9o0nKprH0BNnRi3nVcmcdoGYnTkt2ZcJ6V 1eBLxIsg8Ri9ybFy4N/euTif4QhyAhczD5dFwm9LpKcmpAmp/fhQeKrtwBX8ZlVdSt6S uRiE1wXBDJk2nAWx/INF+y+ZbJAbpQ7mhbsIMSFN2eZJebO4WWAvc2bPgvaDmX+dfOfl jaRIa0w3IR0jGzOF/S3O4R7cpMvJ+tDG7KDiFg38b9K2mj+5wwFJvRgqyqLFxKYeW6sb 1gJLflcZhDTK9pI1WVMtTG1cpVM4YW1dgrudiz/i/rMjbnfTVEQqJxlYHoj0SBGXyDd+ 33wg==
MIME-Version: 1.0
X-Received: by 10.194.84.179 with SMTP id a19mr22612710wjz.29.1432977884030; Sat, 30 May 2015 02:24:44 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.28.4.81 with HTTP; Sat, 30 May 2015 02:24:43 -0700 (PDT)
In-Reply-To: <DD5FC8DE455C3348B94340C0AB5517334F86E8E4@nkgeml501-mbs.china.huawei.com>
References: <20150530055345.15364.12184.idtracker@ietfa.amsl.com> <DD5FC8DE455C3348B94340C0AB5517334F86E8E4@nkgeml501-mbs.china.huawei.com>
Date: Sat, 30 May 2015 11:24:43 +0200
X-Google-Sender-Auth: MkXpedL4PSF67LaF15784we8vGM
Message-ID: <CA+b+ER=oDMSkysWAXVO0z9_H-rM2di6irzVW8VQxD6NThWLmEw@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Haoweiguo <haoweiguo@huawei.com>, Qiandeng Liang <liuweihang@huawei.com>
Content-Type: multipart/alternative; boundary="047d7bfcfa0abfc209051749292a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/QOUSoJcZQUmOiFvuj_eXPZlgu3g>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] New Version Notification for draft-liang-idr-flowspec-orf-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 May 2015 09:24:47 -0000
Hello Weiguo, Hi All, > A new draft of "BGP FlowSpec Outbound Route Filter" was proposed. > Your comments and suggestions are appreciated. > > Thanks, > weiguo > Let me provide few comments why I think this work should be rather abandoned right at its -00 version: section 3.1 Figure 1 "Therefore, ASBR2 can send to ASBR1 a set of FlowSpec-ORF that can be used by ASBR1 to filter its outbound FlowSpec rules to ASBR2." - The above would result in dropping part of the flow descriptions between ASBR 1 and ASBR 2 such that neither ASBR 3 nor ASBR 4 would be able to ever receive it. Note that ASBR 2 may act only as transit and may not be willing to enable foregin filtering in their data plane at all. However it should have not limit it to carry BGP control plane SAFI 133 or 134 to the legitimate peers. So pushing Flow Spec ORF from ASBR 2 to ASBR 1 would be counterproductive. section 3.1 Figure 2 "Furthermore, ASBR2 and ASBR3 will distribute the FlowSpec rules to ASBR1 and ASBR4 respectively." - Sending FlowSpec information to ASBR1 would be acting against validation procedures as described in section 6 of RFC5575 which say: "A flow specification NLRI must be validated such that it is considered feasible if and only if: a) The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification." Summary: I think we should not suppress propagation of filtering rules in BGP control plane provided they are legitimate (ie. pass validation procedure) just based on cherry picking on the match or actions criteria they contain. Practically amount and churn of the amount of flow spec information would be rather in white noise levels compared to what BGP should be ready to carry. However if one would like to limit those other already available tools could be used: longer MRAI timer, dedicated BGP session for SAFI 133/134 with different input processing, FS NLRI dampening etc ... Regards, r.
- Re: [Idr] New Version Notification for draft-lian… Haoweiguo
- Re: [Idr] New Version Notification for draft-lian… Robert Raszuk
- [Idr] 答复: New Version Notification for draft-lian… Liangqiandeng
- Re: [Idr] 答复: New Version Notification for draft-… Robert Raszuk
- Re: [Idr] 答复: New Version Notification for draft-… Haoweiguo
- Re: [Idr] 答复: New Version Notification for draft-… Jeffrey Haas
- [Idr] 答复: 答复: New Version Notification for draft-… Liangqiandeng