Re: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-01.txt

[Jeffrey Haas <[e-mail]>]

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