Re: [Dime] Definition of host report

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Tue, 08 April 2014 07:38 UTC

Return-Path: <ulrich.wiehe@nsn.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 330DB1A0168 for <dime@ietfa.amsl.com>; Tue, 8 Apr 2014 00:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 0_YDEn9LCCia for <dime@ietfa.amsl.com>; Tue, 8 Apr 2014 00:38:20 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id F3F651A0143 for <dime@ietf.org>; Tue, 8 Apr 2014 00:38:19 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s387cDPP014755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Apr 2014 07:38:13 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s387cCNw002429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 09:38:12 +0200
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 8 Apr 2014 09:38:12 +0200
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.65]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 09:38:12 +0200
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] Definition of host report
Thread-Index: AQHPUmcExmbK8hK+6kuc9JeDZTxITZsHUAcg
Date: Tue, 08 Apr 2014 07:38:12 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3@DEMUMBX014.nsn-intra.net>
References: <5342AAD9.9030803@usdonovans.com>
In-Reply-To: <5342AAD9.9030803@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.119]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151DB8D3DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 13422
X-purgate-ID: 151667::1396942693-00001564-43654412/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/clocF2X-knMoV_tMeXQmu2qJP3k
Subject: Re: [Dime] Definition of host report
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: Tue, 08 Apr 2014 07:38:25 -0000

Steve,
I tend to agree.
However, wouldn't this mean that also the current definition of realm report (which actually is RRR) needs to be enhanced?

e.g. replace
The Destination-Host AVP is absent in the request.

with something like
"The reacting node does not know to which Diameter Host the request will be routed."

I was also wondering if there may be cases where
a) the reacting node selects the host, detects that it has a direct connection to that host and therefore does not include the Destination-Host AVP in the request. The selected host, however, when receiving the Destination-Host-less request decides to forward the request to another host. Or
b) the reacting node does not select a host and therefore does not include a Destination-Host AVP, but sends the request to the next hop, which happens to be a Host that decides to handle the request.


Are those cases valid and covered?

Ulrich





From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, April 07, 2014 3:41 PM
To: dime@ietf.org
Subject: [Dime] Definition of host report

All,

I believe that the current definition of the host report needs to be enhanced.

The following is what is currently in the -02 draft:

   0  A host report.  The overload treatment should apply to requests

      for which all of the following conditions are true:



      The Destination-Host AVP is present in the request and its value

      matches the value of the Origin-Host AVP of the received message

      that contained the OC-OLR AVP.



      The value of the Destination-Realm AVP in the request matches the

      value of the Origin-Realm AVP of the received message that

      contained the OC-OLR AVP.



      The value of the Application-ID in the Diameter Header of the

      request matches the value of the Application-ID of the Diameter

      Header of the received message that contained the OC-OLR AVP.

The second paragraph says that only requests that contain a Destination-Host AVP can be used for overload treatment.

This does not address the case where there is no agent between the reacting and reporting nodes.  In other words, the reacting node has a direct connection to the reporting node.  In this case the reacting node should include all messages that would be sent to the reporting node, including those that do not contain a Destination-Host AVP and those that the reacting node would sent to the reporting node through normal route selection for requests that do not contain a Destination-Host AVP.

I propose that the second paragraph be changed to the following:

"The reacting node knows that the request will be routed to the overloaded Diameter node identified by the Diameter ID in the OLR.  This is the value of the Origin-Host AVP in the message that carried the OLR.  There are two cases where the reacting node will know that the request will be routed to the overloaded node.  The first is the request contains a Destination-Host AVP that matches the Diameter ID contained in the OLR.  The second is when the reacting node selects a route that is a direct connection to the overloaded Diameter node."

Regards,

Steve