Subject: Re: [Idr] New Version Notification for draft-liang-idr-flowspec-orf-00.txt

From: Haoweiguo <[email-masked]>
Date: Sat, 30 May 2015 05:55:50 +0000

Hi All,
A new draft of "BGP FlowSpec Outbound Route Filter" was proposed. 
Your comments and suggestions are appreciated.

Thanks,
weiguo
________________________________________
From: [email-masked] [[email-masked]]
Sent: Saturday, May 30, 2015 13:53
To: Qiandeng Liang; Youjianjie; Qiandeng Liang; Haoweiguo; Youjianjie; Haoweiguo
Subject: New Version Notification for draft-liang-idr-flowspec-orf-00.txt

A new version of I-D, draft-liang-idr-flowspec-orf-00.txt
has been successfully submitted by Weiguo Hao and posted to the
IETF repository.

Name:           draft-liang-idr-flowspec-orf
Revision:       00
Title:          BGP FlowSpec Outbound Route Filter
Document date:  2015-05-30
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-liang-idr-flowspec-orf-00.txt
Status:         https://datatracker.ietf.org/doc/draft-liang-idr-flowspec-orf/
Htmlized:       https://tools.ietf.org/html/draft-liang-idr-flowspec-orf-00

Abstract:
   This document defines a new ORF-type, called the "FlowSpec-ORF".
   FlowSpec-ORF is applicable in the networks supporting flow
   specifications (FlowSpec) [RFC5575].  It can be used to filter the
   FlowSpec rules on demand.

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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 30 May 2015 11:24:43 +0200

Hello Weiguo,

Hi All,
> Your comments and suggestions are appreciated.

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