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

Jeffrey Haas <jhaas@pfrc.org> Wed, 26 February 2014 02:01 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87DC1A0833 for <i2rs@ietfa.amsl.com>; Tue, 25 Feb 2014 18:01:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.415
X-Spam-Level:
X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9NSQMwn5oHE for <i2rs@ietfa.amsl.com>; Tue, 25 Feb 2014 18:01:44 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AD36D1A038B for <i2rs@ietf.org>; Tue, 25 Feb 2014 18:01:44 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 71C70C38B; Tue, 25 Feb 2014 21:01:43 -0500 (EST)
Date: Tue, 25 Feb 2014 21:01:43 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: ramki Krishnan <ramk@Brocade.com>
Message-ID: <20140226020143.GE24908@pfrc>
References: <20140121013118.3737.29737.idtracker@ietfa.amsl.com> <C7634EB63EFD984A978DFB46EA5174F2C0013133D3@HQ1-EXCH01.corp.brocade.com> <20140217224356.GA445@pfrc> <C7634EB63EFD984A978DFB46EA5174F2C0032C227E@HQ1-EXCH01.corp.brocade.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C7634EB63EFD984A978DFB46EA5174F2C0032C227E@HQ1-EXCH01.corp.brocade.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/jPuL3FyfZSdH_XHtmKZE3QJNGgo
Cc: Jeffrey Haas <jhaas@pfrc.org>, "draft-krishnan-i2rs-large-flow-use-case@tools.ietf.org" <draft-krishnan-i2rs-large-flow-use-case@tools.ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>
Subject: Re: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-01.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 02:01:45 -0000

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.

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

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

-- Jeff