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

[ramki Krishnan <[e-mail]>]

Hi Jeff,

Thanks, please find inline.

Thanks,
Ramki

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Tuesday, February 25, 2014 6:02 PM
To: ramki Krishnan
Cc: Jeffrey Haas; [e-mail]; [e-mail]
Subject: Re: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-01.txt

Ramki,

On Thu, Feb 20, 2014 at 04:44:05PM -0800, ramki Krishnan wrote:
> 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.

Thanks for the clarification.  I would suggest that you might want to point this out as somewhat of a divergence from the opsawg draft.  I think that while it fits within the very letter of the definition, it's pushing the spirit of it.
Ramki: Thanks, we will add some text to the draft to clarify this aspect.

> 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 ?

My point is that one may use I2RS notifications (mechanism, TBD) in order to flag such things.  This also opens avenues for additional integration with things like IPFIX; e.g. adding a new field to the template to correlate the ejection of a particular flow record with an alert to allow foreign key correlation of the two events.
Ramki: Got it, we will define a I2RS notification mechanism for large flows.

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

The thought I had was that part of the desire for entropy labels was to turn something into a large flow - i.e. influence load balancing.
Ramki: The goal of the entropy label is to perform fine grained load-balancing in the MPLS core without looking deeper inside the packet beyond the label stack. It doesn't care if the inner flow is large or small. 

-- Jeff