Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

<lionel.morand@orange.com> Thu, 28 November 2013 14:09 UTC

Return-Path: <lionel.morand@orange.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 DC8261AD6BF for <dime@ietfa.amsl.com>; Thu, 28 Nov 2013 06:09:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 3IktQpXEuqDb for <dime@ietfa.amsl.com>; Thu, 28 Nov 2013 06:09:28 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6C18F1A1F54 for <dime@ietf.org>; Thu, 28 Nov 2013 06:09:27 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6CA9A324296; Thu, 28 Nov 2013 15:09:25 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4445727C07B; Thu, 28 Nov 2013 15:09:25 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 28 Nov 2013 15:09:25 +0100
From: lionel.morand@orange.com
To: "Nirav Salot (nsalot)" <nsalot@cisco.com>
Thread-Topic: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message
Thread-Index: Ac7sHN1kcwdoL1xIRoywlc8N1o+kQQABwsSAAANc20sABC8OAA==
Date: Thu, 28 Nov 2013 14:09:24 +0000
Message-ID: <30095_1385647765_52974E95_30095_213_1_6B7134B31289DC4FAF731D844122B36E307DF6@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <A9CA33BB78081F478946E4F34BF9AAA014D1EC79@xmb-rcd-x10.cisco.com>, <2901_1385634414_52971A6E_2901_2686_1_6B7134B31289DC4FAF731D844122B36E307743@PEXCVZYM13.corporate.adroot.infra.ftgroup> <A9CA33BB78081F478946E4F34BF9AAA014D1EDDE@xmb-rcd-x10.cisco.com>
In-Reply-To: <A9CA33BB78081F478946E4F34BF9AAA014D1EDDE@xmb-rcd-x10.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.5]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E307DF6PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
Cc: "dime@ietf.org" <dime@ietf.org>
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: Thu, 28 Nov 2013 14:09:33 -0000

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
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" <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
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.