Ramki, On Mon, Jan 20, 2014 at 09:43:24PM -0800, ramki Krishnan wrote: > Besides load balancing, we have added an additional use of case for DDoS > attack mitigation in the latest draft. Looking forward to your comments.
Below, please find some comments on -03: I'm having some difficulty reconciling the idea of typical DDoS traffic as being considered a "large flow". While your definition of a flow (section 1.3) leaves some latitude for which fields are used to identify a flow, that definition doesn't quite align with that in section 4.3.1 of draft-ietf-opsawg-large-flow-load-balancing. In particular, "a sequence of packets for which ordered delivery should be maintained". This may be intentional since the use cases are somewhat different, however I think it doesn't help the i2rs DDoS use case. In such a case, the flow is only long-lived in the sense that it is out of specification traffic for an extended period that is unwanted. In many cases, such traffic may only share the destination. This seems to stretch the definition a little bit. In section 2.1, you're intentionally setting aside involvement of an I2RS agent as being the entity that shares the communication of recognizing large flows. While I understand that existing mechanisms like IPFIX may be a better (initial) fit, why put it out of scope? For my own part, I believe that IPFIX collectors are likely participants in I2RS, long term. This would align with the second case where sampling collectors are used. In section 2.3.1, I believe there's also an implicit requirement that network elements be able to report if they are *capable* of permitting the programming of PBR entries to specific components. For example, if a LAG only carries a single IP address as an endpoint, sufficient information may not be available for layer 3 nexthop programming to distribute the traffic across the LAG and interaction with the load balancer at a deeper level may be required. There is also a typo: "a mechanism a programmable mechanism" I believe the intention of the section with this typo is that when traffic may be distributed over an ECMP path that the weights of the contributing nexthops for the ECMP path can be adjusted. If so, that's not clear in the way the text is currently written. Section 2.3.2.2 for MPLS Networks should probably include mention of the Entropy Label feature (RFC 6790). In section 3, another potential mitigation is I2RS initiating BGP Flowspec. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
