IETF Logo Mail Archive

Re: [Dime] OVLI: comments to 4.6

Ben Campbell <ben@nostrum.com> Fri, 06 December 2013 21:54 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 8B2DB1AE0ED for <dime@ietfa.amsl.com>; Fri, 6 Dec 2013 13:54:05 -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 WiBpN3KjTK-r for <dime@ietfa.amsl.com>; Fri, 6 Dec 2013 13:54:04 -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 A3C531ADE87 for <dime@ietf.org>; Fri, 6 Dec 2013 13:54:04 -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 rB6LrwTJ032206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 15:54:00 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net>
Date: Fri, 06 Dec 2013 15:53:58 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <C84C5762-45F6-4BD8-A73F-54E978872E39@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DCBC@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.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.6
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:54:05 -0000

On Dec 6, 2013, at 6:10 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> Dear all,
>  
> here are comments to clause 4.6:
>  
> It has already been proposed to change the type of the OC-Report-Type AVP from Enumerated to Unsinged64 in order to avoid potential extensibility problems.  
> In addition to that, I think that the purpose of the Report-Type is to let the reacting node know to which (future) request commands the overload treatment should apply:
> 
> For a host report-type the overload treatment should apply to all request commands for which
> a) The request command's Application-ID matches the Application-Id of the OC-Report-Type AVP's encapsulating answer command and
> b) The request command's Destination-Host is present and 
> c) The request command's Destination-Host matches the Origin-Host of the OC-Report-Type AVP's encapsulating answer command

We might consider whether a Host OLR would also apply to the selection of a next-hop peer, in cases where [B&C] were false. For example, if relay received a Host OLR from Server A, it might apply that OLR to requests it would ordinarily send to Server A, even if the client had not included a Destination-Host.

v2.23.0 | Report a Bug | By Email