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

Hi Jeff,

Many thanks for your detailed comments. Please find answers inline.

Thanks,
Ramki

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Monday, February 17, 2014 2:44 PM
To: ramki Krishnan
Cc: draft-krishnan-i2rs-large-flow-use-case@tools.ietf.org; i2rs@ietf.org
Subject: Re: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-01.txt

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.

Ramki: "a sequence of packets for which ordered delivery should be maintained" -- what we mean is that the router does not re-order packets of a flow. For example, a flow could be based on destination IP which would include traffic from multiple ingress ports.

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.

Ramki: Communicating the large flow to external entities can be effectively handled by IPFIX (changes may be needed to IPFIX protocol) without I2RS involvement; same with sampling technologies too. Do you see any additional benefits by collapsing the IPFIX/sFlow agent functionality into I2RS ?

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.

Ramki: Agreed, will add it.

There is also a typo: "a mechanism  a programmable mechanism"

Ramki: Thanks, will fix it.

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.

Ramki: Thanks, will make the text more readable.

Section 2.3.2.2 for MPLS Networks should probably include mention of the Entropy Label feature (RFC 6790).

Ramki: In this case, the entropy label feature does not apply. We are talking about an indivisible large flow.

In section 3, another potential mitigation is I2RS initiating BGP Flowspec.

Ramki: Makes sense, will add it.

-- Jeff

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs