Hi Jeff, Thanks, please find inline.
Thanks, Ramki -----Original Message----- From: Jeffrey Haas [mailto:[email protected]] Sent: Tuesday, February 25, 2014 6:02 PM To: ramki Krishnan Cc: Jeffrey Haas; [email protected]; [email protected] 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
