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

[Liangqiandeng <[e-mail]>]

Thanks for your comments. My replies are as follows:



1. While disseminating FlowSpec rules among different provider's networks, it's reasonable to do some defensive policy to limit installing or
disseminating the injected FlowSpec rules for security consideration. Both dropping or transiting the illegal injected FlowSpec rules are acceptable choices.
 As in the Scenario 1 shown by Figure 1, if a customer hopes to disseminate a FlowSpec rule between its different sites, without any restriction of the provider network,
maybe it' better to establish BGP session between the ASBRs from different sites for disseminating their FlowSpec rules to each other.



2.Actually,our draft doesn't oppose the validation procedures as described in section 6 of RFC5575,
 the RFC checks whether a FlowSpec rule is valid for installing in the local FIB, while the FlowSpec-ORF only checks whether a FlowSpec rule should be disseminated to a specific BGP Peer.



In current FlowSpec deployment practice, there are only some small-scale deployments, single BGP router maybe supports no more than 64k FlowSpec rules. But the FlowSpec rule can be used as flow classifier and flow policy container for fine flow regulating, so there will be more than one million FlowSpec rules(for example flows described by source and destination ip prefix) that a single routing should support. In this case we think the FlowSpec-ORF is valuable.


发件人: Idr [mailto:[e-mail]] 代表 Robert Raszuk
发送时间: 2015年5月30日 17:25
收件人: Haoweiguo; Qiandeng Liang
抄送: [e-mail]
主题: Re: [Idr] New Version Notification for draft-liang-idr-flowspec-orf-00.txt

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