IETF Logo Mail Archive

Re: [Dime] DOIC #70 - Proposed resolution to core issue

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Wed, 01 October 2014 08: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 2A19A1A9175 for <dime@ietfa.amsl.com>; Wed, 1 Oct 2014 01:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UmAt0QivamZI for <dime@ietfa.amsl.com>; Wed, 1 Oct 2014 01:38:47 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C611A9173 for <dime@ietf.org>; Wed, 1 Oct 2014 01:38:46 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s918ciYR022614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Oct 2014 08:38:44 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s918ccqa030378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 10:38:43 +0200
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Oct 2014 10:38:39 +0200
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.218]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0195.001; Wed, 1 Oct 2014 10:38:39 +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] DOIC #70 - Proposed resolution to core issue
Thread-Index: AQHP3LzxVwlySCWp3U+Xg2cvYp/Vlpwa49oA
Date: Wed, 01 Oct 2014 08:38:39 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net>
References: <542AC192.9090600@usdonovans.com>
In-Reply-To: <542AC192.9090600@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.109]
Content-Type: multipart/mixed; boundary="_002_5BCBA1FC2B7F0B4C9D935572D90006681521304DDEMUMBX014nsnin_"
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: 26464
X-purgate-ID: 151667::1412152724-00001FC1-2BC4EB59/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/E313JdFRibiD0vRZr6Otv7Jjr9Y
Subject: Re: [Dime] DOIC #70 - Proposed resolution to core issue
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: Wed, 01 Oct 2014 08:38:49 -0000

Steve,

I agree that there may be cases where the agent that selects the server does not support DOIC, and consequently transparently forwards a host-type OLR to the client which then receives a host-type OLR in response to a realm-type request.

The example flow in Appendix B, however, assumes that the agent supports DOIC.

Please find the proposed modification attached.

Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, September 30, 2014 4:44 PM
To: dime@ietf.org
Subject: [Dime] DOIC #70 - Proposed resolution to core issue

All,

The core issue raised in issue #70 is whether a client can receive an 
OLR of type host when the request sent by the client was realm routed.

I do not support the suggested change as there are scenarios where 
clients MUST be prepared to receive the OLR of type host when the client 
does not do server selection.  This is required for the scenario where 
agents do not support DOIC.  If the request does not contain a 
Destination-Host AVP then agents will be responsible for server 
selection.   An overloaded server will send an OLR of type host that 
will find its way back to the client.

It is true that this might cause unneeded OCS entries in the client in a 
scenario where the client will never do server selection for that 
overloaded server.  This concern can be addressed by making it up to 
local policy whether or not the client saves OCS for the overload 
report.  If the client knows that it will never do server selection for 
a server indicated in a host OLR then the client can choose to not save 
the overload report.

Based on this, I propose that we close issue #70 without changes to the 
DOIC specification.

The discussion about the handling of a mix of overload abatement 
algorithms should continue.  We can open a separate issue if needed to 
address that functionality.

Regards,

Steve

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

v2.23.0 | Report a Bug | By Email