Re: [Dime] OVLI: comments to 4.2

Ben Campbell <ben@nostrum.com> Fri, 06 December 2013 21:31 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18BF1AE072 for <dime@ietfa.amsl.com>; Fri, 6 Dec 2013 13:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 FFYHi5gIOK4Q for <dime@ietfa.amsl.com>; Fri, 6 Dec 2013 13:31:56 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 89B621AE043 for <dime@ietf.org>; Fri, 6 Dec 2013 13:31:56 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB6LVbPW031100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 15:31:38 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <01D3D8A5-2584-4D81-A010-982C8BF77614@gmail.com>
Date: Fri, 6 Dec 2013 15:31:37 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <F9C9771E-A858-43B3-A707-CDD4425ABA8C@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DAA6@DEMUMBX014.nsn-intra.net> <01D3D8A5-2584-4D81-A010-982C8BF77614@gmail.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] OVLI: comments to 4.2
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 21:31:57 -0000

On Dec 6, 2013, at 4:19 AM, Jouni Korhonen <jouni.nospam@gmail.com>; wrote:

>> 
>> 2. Supporting OLR_DEFAULT_ALGO means different things depending on the endpoint’s role (reacting/reporting).
>> Proposal is to expand the text to read:
>> 
>> 
>>      When this flag is set by the overload control reacting endpoint it means
>>      that the default traffic abatement (loss) algorithm is supported by the
>>      reacting endpoint, i.e. the reacting endpont is able and willing to execute
>>     the default traffic abatement algorithm if so requested by the reporting
>>     endpoint.
>>      When this flag is set by the overload control reporting endpoint it means
>>     that the reporting endpoint when overloaded is able and willing to demand
>>     executing the default traffic abatement algorithm from the reacting endpoint.
> 
> OK with me.
> 

On reflection, if that's all it means why does the reporting node need to send it at all? It can just choose to send OLRs for the algorithm the reacting node has advertised. Or is the reporting node declaring that this is the algorithm it will use?

> - Jouni