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