Re: [MEXT] draft-larsson-mext-flow-distribution-rules-01.txt comments (was: draft-ietf-mext-flow-binding-00.txt - comments)

Michael Eriksson <michael.eriksson@ericsson.com> Fri, 21 November 2008 14:13 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: mext-archive@optimus.ietf.org
Delivered-To: ietfarch-mext-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE933A687D; Fri, 21 Nov 2008 06:13:49 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCD43A687D for <mext@core3.amsl.com>; Fri, 21 Nov 2008 06:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxsh8swlCVxF for <mext@core3.amsl.com>; Fri, 21 Nov 2008 06:13:48 -0800 (PST)
Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 003C53A67ED for <mext@ietf.org>; Fri, 21 Nov 2008 06:13:47 -0800 (PST)
Received: by kafka.verkstad.net (Postfix, from userid 20078) id 5B599710B17; Fri, 21 Nov 2008 15:13:46 +0100 (CET)
Date: Fri, 21 Nov 2008 15:13:46 +0100
From: Michael Eriksson <michael.eriksson@ericsson.com>
To: "Stuart W. Card" <stu.card@critical.com>
Message-ID: <20081121141346.GB26200@kafka.verkstad.net>
References: <C5489699.A2A2%hesham@elevatemobile.com> <49231705.9020406@ericsson.com> <17492.128.230.32.38.1227043564.squirrel@www.critical.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <17492.128.230.32.38.1227043564.squirrel@www.critical.com>
Cc: mext@ietf.org
Subject: Re: [MEXT] draft-larsson-mext-flow-distribution-rules-01.txt comments (was: draft-ietf-mext-flow-binding-00.txt - comments)
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

On Tue, Nov 18, 2008 at 16:26:04 -0500, Stuart W. Card wrote:
> conny.larsson@ericsson.com wrote --
> 
> > And the draft describing how this can be done is
> > http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-01.txt
> 
> I hadn't reviewed the latter draft before.
> Thank you for pointing it out.
> It looks like it may become very useful in my team's work.
> My comments follow.
> 
> From that draft:
> 
> > 5.4.  Conditional Rule-Sets
> >
> >   For some scenarios, it is useful to install or transmit a collection
> >   of rule-sets at the same time, and select which one to use depending
> >   on what PIDs are available.  How the set of available PIDs is
> >   determined is outside the scope of this document.
> 
> and:
> 
> > 5.14.  Round-robin
> >
> >   For load-sharing purposes, round-robin transmission is supported.  To
> >   use round-robin, a list of PIDs is given instead of just one:
> >
> >      udp peer 2001:db8:1c32::/48 port 44100 on 4, 4, 5
> >
> >   Here, UDP traffic from port 44100 at any node in prefix 2001:db8:
> >   1c32::/48 will be sent on PIDs 4 and 5.  Two out of three packets
> >   will go on PID 4, which presumably has twice the bandwidth of PID 5.
> 
> These specs make sense iff:
>  a PID is either available, or not; and
>  coarse granularity in bandwidth allocation is adequate.
> 
> However, a path may be 'available', but currently degraded.
> Or paths may simply have bandwidth that is highly variable.
> Likewise different paths may have slightly different bandwidths.

At the Home Agent, a path can only be "available" or "not available",
as it is determined by if a particular BID is bound or not
(draft-larsson PIDs map directly to MIPv6 BIDs).

If the availability is "fuzzy" (sometimes degraded), that would have
to be handled by some outside party that updates the flow rules at the
HA (and MN) according to the conditions of each path.

BR, Michael
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext