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