Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Ben Campbell <ben@nostrum.com> Thu, 20 February 2014 23:16 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 59BFF1A033D for <dime@ietfa.amsl.com>; Thu, 20 Feb 2014 15:16:35 -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 x4kjRVScBSef for <dime@ietfa.amsl.com>; Thu, 20 Feb 2014 15:16:33 -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 B8BE71A0304 for <dime@ietf.org>; Thu, 20 Feb 2014 15:16:33 -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 s1KNGRHa010149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Feb 2014 17:16:29 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5303742C.50902@usdonovans.com>
Date: Thu, 20 Feb 2014 17:16:29 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum.com>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup> <E194C2E18676714DACA9C3A2516265D2026644D6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <D2D4DD91-8F3D-4C24-9E3A-E2AE3918D468@gmail.com> <52FCBBF7.7000700@usdonovans.com> <D4BE67F7-6D7B-4DB2-8DF0-D430A8FC6582@nostrum.com> <5302351F.6050902@usdonovans.com> <E194C2E18676714DACA9C3A2516265D2026697DE@FR712WXCHMBA12.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com>
To: Steve Donovan <srdonovan@usdonovans.com>
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KYNBDklR2mRvwGMjavQURM3WPLY
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
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: Thu, 20 Feb 2014 23:16:35 -0000

On Feb 18, 2014, at 8:54 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

> Ulrich,
> 
> All good questions.
> 
> I mapped out the use case in a previous email with discussing the realm-routed overload report type.  
> 
> Maria Cruz also indicated that this is a 3GPP DOC requirement.  I'm hoping someone involved in the discussions that lead to that requirement can speak up on the use case driving the need for realm reports.
> 
> The means of detection is out of scope for the DOIC draft, just as it is for host and realm-routed report types.  We should, however, include wording to explain how it might be done.  
> 
> A few bullet points outlining a proposed solution.  I can put together a couple of slides explaining this if it would be helpful.
> 
> - The method of detection can be based on the collected status of Diameter nodes in the realm.  It can also be based on the status of the underlying network.  For instance, if there is a network outage that reduces the effective throughput of the signaling network, the best method for handling this might be to signal a realm overload report.
> 
> - The network element detecting the realm status is out of scope for the DOIC document.
> 
> - The Diameter node that reports realm overload can be any Diameter node and is up to the service provider to define.  Assuming we are using Diameter answer messages to transport the realm reports, it would need to be either all agents or all servers.  This is to guarantee that all reacting nodes get the report.

I think "any Diameter node" is too broad. It has to be node that is, at least sometimes, in the path for requests for that particular realm+application.  (Although I note that explicit realm and application AVPs in an OLR would fix that ;-)  )

> 
> - The method that the reporting node is told that the realm is overloaded, triggering the realm overload report, is out of scope for this document.
> 

Agreed, although one possible way to do it would be for the reporting node to be an agent that infers general realm overload based on upstream overload information.

> - Reacting nodes should listen to only one realm overload reporting node.  It is up to the implementation of the realm overload detection element to make sure that all reporting nodes have the same state.

I think this should be restated that realm reports should only be _sent_ by reporting nodes that have full knowledge of and authority for the realm's overload state. But there's no requirement that there be only one, just that if there are more than one they don't contradict each other.

> 
> One way to model this is for an external element being responsible for detecting realm overload and signaling the realm overload reporting nodes of the status using an out of bands mechanism.  All realm overload reporting nodes would be responsible for sending realm overload reports.  Reacting nodes would only listen to one of the reporting nodes.
> 
> There are also security considerations similar to host reports, except that an attack using realm overload reports has a much bigger impact than an attack using host reports.

Yep. IIRC, We already have language in the security considerations that reacting nodes need to properly authorize sources of OLRs. That applies here as well.

(Maybe it's time to propose an "all-realms" report type :-) )