Re: [Dime] Definition of host report

Ben Campbell <ben@nostrum.com> Thu, 17 April 2014 21:56 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 C087B1A0045 for <dime@ietfa.amsl.com>; Thu, 17 Apr 2014 14:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 eZiILEC1n9K6 for <dime@ietfa.amsl.com>; Thu, 17 Apr 2014 14:56:15 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7B81A01CF for <dime@ietf.org>; Thu, 17 Apr 2014 14:56:14 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s3HLu8xC040894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 16:56:10 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5343F470.50808@usdonovans.com>
Date: Thu, 17 Apr 2014 16:56:08 -0500
X-Mao-Original-Outgoing-Id: 419464568.761734-9c90bf3c7859babfaf2c247699c23a29
Content-Transfer-Encoding: quoted-printable
Message-Id: <98935E31-5866-4456-BFDF-D02FD2D0BDC6@nostrum.com>
References: <5342AAD9.9030803@usdonovans.com> <28937_1396879717_5342B165_28937_9147_1_6B7134B31289DC4FAF731D844122B36E548C2D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <534318C7.1060502@usdonovans.com> <7558_1396959635_5343E993_7558_7400_1_6B7134B31289DC4FAF731D844122B36E54C514@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5343F470.50808@usdonovans.com>
To: Steve Donovan <srdonovan@usdonovans.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aPN2JeHF6cxsDWNfoo_Gan7-qWw
Cc: "dime@ietf.org" <dime@ietf.org>
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: Thu, 17 Apr 2014 21:56:19 -0000

On Apr 8, 2014, at 8:06 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

> Lionel,
> 
> I'm not proposing adding an AVP to the overload report.  I should have said the Diameter ID in the overload control state.  I agree completely that the Diameter ID comes from the Origin-Host AVP in the answer message containing the OLR.

There's a potential issue here. Maybe we've discussed this before, but I've forgotten:

What happens if an intervening agent changes the Origin-Host AVP in the answer? I think we can take our previous discussions ofidentity-mapping server front end agents as an existence proof of agents that do that sort of thing.

The obvious answer is that any agent that did that sort of thing should remove the overload report, and perhaps replace it with one of it's own. But if the proxy does not support DOIC in the first place, it's likely not to do that. If a host report leaks past an agent that modifies the Origin-Host, then the reacting node is highly likely to do the Wrong Thing.


> 
> Regards,
> 
> Steve
> 
> On 4/8/14 7:20 AM, lionel.morand@orange.com wrote:
>> Hi Steve,
>> 
>> I understand your point now. Thank you for the clarification.
>> 
>> However, I don't think that it leads necessarily to the need for a Diameter Id in the OLR.
>> 
>> The clarification could be that, in case of direct connection between clients and servers, the Host report type applies also to the peer connection for which the peer id is equal to the origin-host in the answer containing the OLR. Such binding is required and the Diameter Id in the OLR will not provide added-value compared to the origin-host of the answer.