Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
Steve Donovan <srdonovan@usdonovans.com> Tue, 03 December 2013 15:35 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 9D7F01AE13A for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 07:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 JVb9xchy5vOk for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 07:34:52 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id BC8231AE08C for <dime@ietf.org>; Tue, 3 Dec 2013 07:34:52 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50131 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from <srdonovan@usdonovans.com>) id 1Vnrzr-0008Fw-D0 for dime@ietf.org; Tue, 03 Dec 2013 07:34:49 -0800
Message-ID: <529DFA17.1090507@usdonovans.com>
Date: Tue, 03 Dec 2013 09:34:47 -0600
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: dime@ietf.org
References: <A9CA33BB78081F478946E4F34BF9AAA014D22C9C@xmb-rcd-x10.cisco.com>
In-Reply-To: <A9CA33BB78081F478946E4F34BF9AAA014D22C9C@xmb-rcd-x10.cisco.com>
Content-Type: multipart/alternative; boundary="------------060200020206020203010408"
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: srdonovan@usdonovans.com
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
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, 03 Dec 2013 15:35:00 -0000
Nirav, If we allow AVPs to be added without a new report type then where will the behavior associated with the presence of that AVP be documented? Requiring the definition of a new registered report type insures that implementers have a well defined place to go to find out how to deal with the presence of that AVP. Steve On 12/3/13 3:25 AM, Nirav Salot (nsalot) wrote: > > Maria-Cruz, > > > > >we may think that we need two different OLRs with ReportType=host, and > one of them includes the extra info (AVPs) required for that application > > Yes. The above is my concern. I tried giving APN as one example AVP > which we may want to include in OC-OLR. Let me give another possible > example. > > As of now, the OC-OLR can indicate application + host/realm level > "required-reduction-percentage". > > However, for the given application (e.g. Gx) we may want to define a > narrower scope with "session-type = {M2M, Others}" AVP. So basically, > the Gx nodes can advertise different "required-reduction-percentage" > for M2M sessions v/s other type of sessions for the same application > Gx and for the same destination-host. > > > > So in general, if any application needs to define a different (i.e. > narrower) scope than application + host/realm, it can do so by adding > a new AVP in OC-OLR. > > And then we might have two instances of OC-OLR from the same host. > > > > We could achieve the above by defining new Report-Type for each new > AVP added by each application. But would this scale or is this a > reasonable approach? > > I am not sure and you have already identified one of my concerns below > > >if we extend ReportType, does it need to be done by IETF, or could it > be done per application by 3GPP? > > > > In summary, in my view, we need to define the handling of multiple > instances with the same Report-Type as part of the DOIC draft. Or we > say that multiple instances with the same Report-Type is not allowed > -- this seems unnecessary restriction to me. > > Otherwise, if later, we realize the need to do so then we may not be > able to do so since the handling is not defined in the base solution. > > > > Regards, > > Nirav. > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Maria Cruz > Bartolome > *Sent:* Tuesday, December 03, 2013 1:57 PM > *To:* dime@ietf.org > *Subject:* Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the > same type) within a response message > > > > Nirav, > > > > I think I understand your concern. It may occur that we need that a > reacting node should apply two different OLR when sending a request > towards one specific host. > > Then, we may think that we need two different OLRs with > ReportType=host, and one of them includes the extra info (AVPs) > required for that application, I think this is your interpretation, > but... we can as well consider a new ReportType=applicX_ReportY, that > may apply e.g. for any request send to this application, or just for > this application+host, and then Host could be another AVP to be > included in the OLR, or we could define expected behaviour when > defining this new ReportType. > > > > Would this cover your concerns? If not, could you try to provide an > example that requires two OLR with ReportType=host? > > > > A part from that, a question for all, if we extend ReportType, does it > need to be done by IETF, or could it be done per application by 3GPP? > > > > Thanks > > /MCruz > > > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Nirav Salot > (nsalot) > *Sent:* jueves, 28 de noviembre de 2013 17:11 > *To:* lionel.morand@orange.com <mailto:lionel.morand@orange.com> > *Cc:* dime@ietf.org <mailto:dime@ietf.org> > *Subject:* Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the > same type) within a response message > > > > Hi Lionel, > > > > I am not sure if defining new ReportType for every new AVP 3GPP would > add for a specific application would be a good solution. > > I thought ReportType would indicate if the corresponding OC-OLR should > be used while sending the traffic towards the host or towards the realm. > > So from that point of view, all the OC-OLR generated by the server > should have ReportType=host. i.e. when the reacting node sends the > traffic towards that host, it should make use of the corresponding > OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as > well as 3GPP application specific AVPs. > > > > In general, I was just thinking that it may be good idea to define > some of the principles such as > > - More than one instances of OC-OLR with ReportType=host may > be present in the answer message if the OC-OLR definition is extended > by the application using the same. In that case, it is the > responsibility of the application to define the valid combination of > OC-OLR instances in a given message > > - If the reporting node includes more than one instance of > OC-OLR, the reporting node shall always include all the active > instances of OC-OLR in a response message. > > - When the reacting node receives one or more instances of > OC-OLR with the given ReportType and with new timestamp value, it > should overwrite all the existing OC-OLR of the same ReportType. > > > > Regards, > > Nirav. > > > > *From:*lionel.morand@orange.com <mailto:lionel.morand@orange.com> > [mailto:lionel.morand@orange.com] > *Sent:* Thursday, November 28, 2013 7:39 PM > *To:* Nirav Salot (nsalot) > *Cc:* dime@ietf.org <mailto:dime@ietf.org> > *Subject:* RE: DOIC: Multiple instance of OC-OLR AVP (of the same > type) within a response message > > > > Hi Nirav, > > > > The Report Type should be able to differentiate such cases. In your > example, I would define a specific Report type. > > But difficult to appraise all the future use cases. But for me, the > main use of the report type is to differentiate OC-OLR received in the > same message. > > And it is the reasons of my recommendation. Actually, the exact > wording will be a "SHOULD" saying that it is recommended but you may > have serious reasons to do otherwise. > > > > Lionel > > > > *De :*Nirav Salot (nsalot) [mailto:nsalot@cisco.com] > *Envoyé :* jeudi 28 novembre 2013 13:00 > *À :* MORAND Lionel IMT/OLN > *Cc :* dime@ietf.org <mailto:dime@ietf.org> > *Objet :* RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) > within a response message > > > > Lionel, > > 3gpp may define an optional avp which can be included by the reporting > node if it wishes to do so. E.g. APN can be additionally included by > the reporting node to indicate APN specific overload within the given > application. > In that case, the reporting node may also want to indicate application > level overload without including the APN (e.g. this overload report is > applicable to all other APNs). > > And hence there is a possibility of including multiple instances of > the overload report. > > I am not suggesting that 3gpp will define APN (or any other avp) > within overload report. But later, if 3gpp need to define the same, > then corresponding handling needs to be defined within IETF now. > > Regards, > Nirav. > > On Nov 28, 2013 3:56 PM, "lionel.morand@orange.com > <mailto:lionel.morand@orange.com>" <lionel.morand@orange.com > <mailto:lionel.morand@orange.com>> wrote: > > Hi Nirav, > > > > Not sure to understand the proposal or question. > > The OLR is significant per application (piggybacking principle). So if > the 3GPP decides to add specific AVPs in the OLR (that will be > possible), what would be the need to add the OLR without the specific > 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities? > > > > Lionel > > > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Nirav Salot > (nsalot) > *Envoyé :* jeudi 28 novembre 2013 10:33 > *À :* dime@ietf.org <mailto:dime@ietf.org> > *Objet :* [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same > type) within a response message > > > > Hi, > > > > As I understand IETF will define the base overload control solution as > part of DOIC. Then 3GPP would adopt the defined solution for each of > its application. > > When that happens, 3GPP might want to add 3GPP specific AVP within > OC-OLR AVP. Based on the current definition of the OC-OLR AVP this > should be allowed since it contains "* [AVP]" in its definition. > > e.g. for a given application 3GPP decides to add information into > OC-OLR which changes the scope of the OC-OLR from application level to > the provided information level. > > Additionally, the reporting may want to advertise the OC-OLR at the > application level scope -- i.e. the OC-OLR without any 3GPP specific info. > > > > So if the above is allowed, we will have the possibility of the > reporting node wanting to include two instances of OC-OLR with the > Report-Type="host". > > And then we need to define the handling of multiple instances of > OC-OLR in the DOIC draft. > > > > So the questions are, > > - Is 3GPP (or any other SDO) allowed to extend the definition > of OC-OLR by adding information into it? > > - If no, can we guarantee that application level scope of > OC-OLR (which is what we have defined currently) is sufficient (and > not restricting) to all the applications of 3GPP? > > > > Regards, > > Nirav. > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime
- [Dime] DOIC: Multiple instance of OC-OLR AVP (of … Nirav Salot (nsalot)
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … lionel.morand
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Nirav Salot (nsalot)
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … lionel.morand
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Nirav Salot (nsalot)
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Steve Donovan
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Maria Cruz Bartolome
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Jouni Korhonen
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Nirav Salot (nsalot)
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Maria Cruz Bartolome
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … lionel.morand
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Jouni Korhonen
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Steve Donovan
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Ben Campbell
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Ben Campbell
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Jouni Korhonen
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Nirav Salot (nsalot)
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Jouni Korhonen
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Shishufeng (Susan)
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Ben Campbell
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Shishufeng (Susan)
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Ben Campbell
- Re: [Dime] DOIC: Multiple instance of OC-OLR AVP … Shishufeng (Susan)