Re: 6MAN WG Last Call: <draft-ietf-6man-flow-3697bis-02.txt>

Scott Brim <> Wed, 06 April 2011 15:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF34E28C13D for <>; Wed, 6 Apr 2011 08:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.592
X-Spam-Status: No, score=-103.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iC3JRCRsjWUi for <>; Wed, 6 Apr 2011 08:47:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7DD4D28C122 for <>; Wed, 6 Apr 2011 08:47:33 -0700 (PDT)
Received: by iye19 with SMTP id 19so1949576iye.31 for <>; Wed, 06 Apr 2011 08:49:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AQCPhkLnS72RUzUlXf1GcuiYujuQJAWhwHssgr1ACgY=; b=TvXDaI8x+xN1D01YiH73nIfRHjDmf8Mi0F+DkWCdX8xlsoYUyBnNSt4k999BlackCZ m4bKkUQ9UhrHgil/TQtvmLJo7dMcn1RoFSW4SWtx9Bt1HTexg33vz5EawuTUOqmMvJGs xyX81BeRbuwS+r9YMB0SETO+DCG8PEBZmJsuw=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=PiktEt/JLK2HAG4GMFbMzzen+B/A/3RxdQyHl+l/iBvhSW5ZEBZjOKP4BYmmC9mRIU cWAPYhBpUHCvNO7goe4EwMpZooBATB5Rg16GO1uBZCMMisx3an2tJnPZzxsSbt3vVGx8 9jEMjNSFL1/wknE+9Zpr3AbYN1RRcVJCJSasQ=
Received: by with SMTP id w8mr1143477ibh.80.1302104957136; Wed, 06 Apr 2011 08:49:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 6 Apr 2011 08:48:57 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Scott Brim <>
Date: Wed, 6 Apr 2011 11:48:57 -0400
Message-ID: <>
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-flow-3697bis-02.txt>
To: Thomas Narten <>
Content-Type: multipart/alternative; boundary=000e0cd56c546e332a04a041efc2
Cc: 6man Mailing List <>, Brian Haberman <>, Bob Hinden <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Apr 2011 15:47:34 -0000

On Tue, Apr 5, 2011 at 13:40, Thomas Narten <>; wrote:

> Here are my detailed comments on the document. I did chat with Brian
> directly in Prague about these points as well. Overall, I support this
> document. But I think the wording in places needs another round of
> revision.
>   A flow is a sequence of packets sent from a particular source to a
>   particular unicast, anycast, or multicast destination that a node
>   desires to label as a flow.  A flow could consist of all packets in a
> This is a circular definition. I think it would be useful to give two
> definitions, something like the following:
>    A Flow is a sequence of packets originating from a particular
>    application that should be treated "the same" by the network as
>    they are forwarded along to their ultimate destination. Packets
>    within a flow should not be reordered, should not be given
>    dissimilar QOS treatment, etc. What constitutes a Flow can only be
>    defined by the application itself.

Sorry, Thomas, I don't think this will work.  First, I don't think we can
define a "flow" by what the network should do with it, whatever it is.  If
something is definable, then it has attributes independent of how other
things behave toward it.  It seems that a flow is anything the node labels
with the same flow label.  If so (as in your last sentence), then that's the
only definition you have.  Also, a flow doesn't necessarily originate from a
single application.  It could be multiple.  Some environments don't even
have applications.  My inclination would be to decline this definition

The rest looks good.

Thanks ... Scot