Re: [Dime] DOIC #70 - Proposed resolution to core issue
Steve Donovan <srdonovan@usdonovans.com> Wed, 01 October 2014 13:34 UTC
Return-Path: <srdonovan@usdonovans.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 27DD91A044F for <dime@ietfa.amsl.com>; Wed, 1 Oct 2014 06:34:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level:
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] 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 2VAnckDgcdhy for <dime@ietfa.amsl.com>; Wed, 1 Oct 2014 06:34:03 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B06E1A0410 for <dime@ietf.org>; Wed, 1 Oct 2014 06:34:03 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53367 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <srdonovan@usdonovans.com>) id 1XZK2a-0006Q2-76; Wed, 01 Oct 2014 06:34:02 -0700
Message-ID: <542C02C5.40202@usdonovans.com>
Date: Wed, 01 Oct 2014 08:33:57 -0500
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>, "dime@ietf.org" <dime@ietf.org>
References: <542AC192.9090600@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681521304D@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/WNAhifsuZSdQc-W87gZfezoAWg8
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 13:34:04 -0000
Ulrich, I'm ok with your proposed wording for step 4 in the diagram that the agent MAY removed the host overload report. I just don't think it should be a MUST. Regards, Steve On 10/1/14, 3:38 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > 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
- [Dime] DOIC #70 - Proposed resolution to core iss… Steve Donovan
- Re: [Dime] DOIC #70 - Proposed resolution to core… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] DOIC #70 - Proposed resolution to core… Steve Donovan
- Re: [Dime] DOIC #70 - Proposed resolution to core… Steve Donovan
- Re: [Dime] DOIC #70 - Proposed resolution to core… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] DOIC #70 - Proposed resolution to core… Ben Campbell
- Re: [Dime] DOIC #70 - Proposed resolution to core… Wiehe, Ulrich (NSN - DE/Munich)