Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01

I am fine with all the principles mentioned below except for "Multiple OLRs can be found in the answer only if the OLRs have different Report types".
I am not 100% sure if the above restriction is needed yet. I will initiate a separate e-mail thread for the related discussion.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Thursday, November 28, 2013 1:53 PM
To: Jouni Korhonen; Ben Campbell; dime@ietf.org
Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01

I could discuss the need for the report type for a longtime...
But I can live with the following approach:

- Keep the report type AVP
- Keep the Report type as optional in the OC-OLR
- Clarify that the OC-OLR applies to the Origin-Host of the Answer when the report type is absent
- Multiple OLRs can be found in the answer only if the OLRs have different Report types e.g. response to an initial request (with only dest-Realm AVP) may contain overload status of the node and of the realm
- Remove "aggregated"

Is it OK for everyone?

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoyé : mercredi 27 novembre 2013 12:59 À : Ben Campbell; dime@ietf.org Objet : Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01

On Nov 26, 2013, at 10:20 PM, Ben Campbell <ben@nostrum.com> wrote:

> 2)  Lionel argued that OLRs are best used to describe overload for the realm as a whole. Overload for specific nodes would be better handled by sending Diameter error codes, either by fixing one or more existing error codes to have the correct semantics, or introducing new ones. If we did this, we would not need different report types.
> 
> My opinion is that I would like a consistent way of reporting overload, that is, I don't like using OLRs for one kind of overload, and error result codes for another. In particular, I would like to be able to report overload before reaching the point that I need to fail a transaction, i.e. I would like to be able to report any kind of overload in a Diameter answer message with a result code of DIAMETER_SUCCESS.

I am towards Ben's conclusion here.

> 3) Are we allowed to put more than one OLRs in a single answer, as my example shows in step 8?
> 
> It might be possible to construct an example where you never see more than one OLR in a single answer. But I don't see what purpose would be served by such a limitation, as long as multiple OLRs do not contradict each other. Since the reports in the example have different report types, there is no conflict. On disadvantage of _not_ allowing multiple reports in one answer is that, if the servers choose to send reports in every answer, life gets complicated for the agent when trying to find a place to put the "realm" report.  It either needs to strip the server reports (which is hard given that the server overload conditions are best handled by the clients.) Or it needs to originate its own answers, which means forcing the failure of at least some transactions.

My recollection was that we want to get rid off the ReportType in the baseline. That would also imply a single OLR in an answer. I might remember wrong, though.

Anyway, just to be on the safe side the current draft-ietf-*-01 still has the ReportType.

Could we conclude this point asap? Removing the ReportType has implications in multiple places.

- Jouni

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

_________________________________________________________________________________________________________________________

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