Subject: [Dime] DOIC: Self-Contained OLRs

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Nov 2013 16:27:46 -0600

Hi,

I mentioned in another thread that I prefer putting an explicit ReportType AVP in an OLR, rather than making a responding node infer the type or meaning of the OLR from a Diameter request that corresponds to the answer containing the OLR. My reasons for that go beyond just ReportType, so I'm starting a separate thread.

As currently described, a consumer of an OLR must infer several things from other context. In most cases, that context is in the Diameter answer that carries the OLR. For example, the OLR implicitly refers to the application identified by the Application-Id field of the enclosing answer, the realm identified by Origin-Realm, and so on. This means that the "meaning" of an OLR cannot be determined from the OLR contents alone; OLRs only have meaning in the context of the enclosing answer. If you moved an OLR from one answer to another, it's meaning may change completely.

I think this approach is a mistake. I would greatly prefer that we explicitly include such values in the OLR itself, for multiple reasons:

1) It's more complex to interpret implicit, contextual values than explicit values. The consumer cannot simply look at the OLR; it must look in various other AVPs to find all the information it needs. For example, I think a common software design for overload control processing to be separated from application processing. The consumer cannot simply hand the OLR to that module and expect things to work. The OC module must not only parse the OLR, but parse any other AVPs that are relevant. As OLR contents get extended (assumedly following the same strategy as the base spec), the number of "context" avps that must be interpreted can grow large. This approach is error prone, and will likely encourage brittle, hard-to-maintain code. Self-contained OLRs would keep all the information related to overload in one place. making for simpler implementations.

2) It's more complex for the reporting node to send implicit values than explicit values. The sender cannot simply set the context to match the OLR--all those other AVPs have application or protocol layer meanings. Once a reporting node realizes that it is overloade, it has to wait for the right answer that contains the right context before it can send the OLR. This is particularly troublesome for agents, since they will typically have to insert OLRs into answers created by other nodes. 

If the reporting node screws this up, the meaning of the OLR may change significantly. So again, implicit meaning gives us error prone implementations. Self-contained OLRs are simpler to create and send.

3) Implicit values don't work at all for certain problems. For example, if an agent needs to originate an OLR, it typically needs to insert that OLR into an existing Diameter answer created by a server. It can't create its own answer without affecting the application state. If the responding node assumes the OLR comes from or refers to the node identified by the Origin-Host AVP in the enclosing answer, things break. (For examples of when an agent needs to send OLRs that are distinct from those sent by a server, see Steve's agent overload draft, or my dh/dr example.)

OTOH, explicit values will work for all cases where we need to associate some arbitrary value with an OLR.

4) Implicit values seriously constrain the future evolution of Diameter OC standards. For example, lets say we find a good reason to allow OLRs to be sent out of band, or be sent in a dedicated Diameter application. If overload reports were self-contained, one could just reuse the report format we specify here. But if the meaning of an OLR depends on the way it's transported, this won't work. We would have to create a new or significantly modified OLR format if we found a need to transport OLRs in different ways. Self-contained OLRs would allow much greater flexibility.

So, in summary, I think that self-contained OLRs would lead to simpler implementations, less brittle deployments, and more flexibility for future evolution of standards.

Thanks!

Ben.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 27 Nov 2013 22:29:07 +0000

Agree

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards  
AT&T Standards and Industry Alliances
+1-609-903-3360
[email-masked]

> On Nov 27, 2013, at 5:28 PM, "Ben Campbell" <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 28 Nov 2013 00:43:44 +0200

On Nov 28, 2013, at 12:27 AM, Ben Campbell <[email-masked]> wrote:

> Hi,
> 
> I mentioned in another thread that I prefer putting an explicit ReportType AVP in an OLR, rather than

The more I spent time thinking/writing the actual procedures on the endpoints,
the more it makes sense to me to keep the ReportType in the OC-OLR. Even if the
baseline does not have agent overload etc, the ReportType fits well to the
"endpoint principle" we have in the draft. It indeed gives more tools to make
a host vs. realm base decision on the reacting node and is plain more clear.

I skip the rest of the mail.. too much text ;-)

- Jouni

> making a responding node infer the type or meaning of the OLR from a Diameter request that corresponds to the answer containing the OLR. My reasons for that go beyond just ReportType, so I'm starting a separate thread.
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Nov 2013 16:49:24 -0600

> I skip the rest of the mail.. too much text ;-)

Heh. Okay, short version:

I think we should also include explicit values for things like Application, Realm, etc, in the OLR itself, where applicable. I'd like to have fully self-contained OLRs that do not depend on their enclosing Diameter message. For example, I might decide to save the OLR separately from the rest of the message, or I might want to send an OLR over some out-of-band mechanism (or perhaps a dedicated overload application ;-)  ) without having to define a new format.

I've got reasons, but you will have to read the long text for those :-)

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 28 Nov 2013 08:57:25 +0000

Ben,

what you propose is an optimization.
And I do not object.

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Ben Campbell
Sent: Wednesday, November 27, 2013 11:28 PM
To: [email-masked] list
Subject: [Dime] DOIC: Self-Contained OLRs

Hi,

Thanks!

Ben.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 28 Nov 2013 09:25:33 +0000

Hi,

I don't see how the possibility to send more than one OLR in an answer is aligned with the "endpoint principle". If the ReportType is "realm" this indicates to the reacting end point that the reporting end point is an agent (e.g. SFE) rather than a server. If the ReportType is "host" this indicates to the reacting end point that the reporting end point is a server. How can the reporting end point be both agent and server?

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: <[email-masked]>
Date: Thu, 28 Nov 2013 09:30:43 +0000

Hi,

There is no assumption on which entity is providing the realm overload status. It could be provided an agent inserting this info in answers received from a server behind but also from a server that would know this info by some internal magic.
But in any case, if we assume that the client will received a successful answer from the server for an initial request with only Dest-Realm AVP, it should be possible to have both report types in the answer: one for the server itself, one for the realm for new request sent to the realm with only Dest-Realm AVP.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : jeudi 28 novembre 2013 10:26
À : ext Jouni Korhonen; Ben Campbell
Cc : [email-masked] list
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

_________________________________________________________________________________________________________________________

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.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 28 Nov 2013 10:30:10 +0000

Lionel,

my understanding was that _the_ reporting end point provides _the_ OLR.

If we go for two OLRs in the answer we should indicate which OLR is the actual OLR created by the reporting end point and which OLR is an additional OLR created by another node.

We have two cases:
a) The request sent by the client (reacting end point) contains no Destination Host. The agent (reporting node) (after forwarding the request to the selected server and receiving the answer) returns a realm-type OLR as the actual reporting-node-created OLR and optionally in addition a host-type OLR as learned from the selected server.  The client may ignore the additional OLR.
b) The request sent by the client (reacting endpoint) contains the Destination Host. The Server (reporting node) returns a host-type OLR as the actual reporting-node-created OLR in the answer. The agent may optionally insert a realm-type OLR as additional OLR to the answer. The client may ignore the additional OLR.

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

-----Message d'origine-----

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 28 Nov 2013 10:40:02 +0000

Hi,

another question:

If we go for explicit self contained OLRs, why would we then need the ReportType?

The realm-type OLR would explicitly contain application-Id, Realm, but no Host whereas the host-type OLR would explicitly contain application-Id, Host, but probably (I'm not sure) no Realm.

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

-----Message d'origine-----

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 29 Nov 2013 11:20:20 +0200

So, are we reaching any level of consensus here?

- JOuni

(as a note.. that we are converging back to where we started with OLRs ;)

---

From: <[email-masked]>
Date: Fri, 29 Nov 2013 10:13:26 +0000

Hi Ulrich,

Using the Report Type "host report", you know that the OLR applies for subsequent request towards the origin-host of the answer containing the OLR. Using the report Type "Realm report", you know that the OLR has to be used as soon as a request needs to be sent without destination-realm. 

It is not so important to know what the type of request was and which node inserts this information. It can be any node having sufficient knowledge of the realm overload status. An agent in the path could be this one but, for instance, future development could allow a distributed server architecture to provide the same information.

I'm not sure of what is missing in this reasoning...

Lionel

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] 
Envoyé : jeudi 28 novembre 2013 11:30
À : MORAND Lionel IMT/OLN; ext Jouni Korhonen; Ben Campbell
Cc : [email-masked] list
Objet : RE: [Dime] DOIC: Self-Contained OLRs

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

-----Message d'origine-----

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Fri, 29 Nov 2013 11:24:12 +0000

Jouni, Ben,

I am totally against the idea of self-contained OC-OLR specifically since we have adopted the principles of piggybacking the OC-OLR over existing application message.
Self-contained OC-OLR - which means adding all the information which defines the scope of the OC-OLR into the OC-OLR - does not make sense in the piggybacking approach. In fact, it is adding lot of information, which is anyway available within the message containing the OC-OLR, into the OC-OLR. So it is adding lot of redundant information in a message which increases the processing requirement for the sender as well as the receiver. (And this is un-optimization, in my view).

Besides, I am not convinced with the other reasons provided here:
- One software module within a node can provide OC-OLR to another software module in the same node without passing other related info
   Within a node, based on the design, lots of information may need to be passed between two software modules and we cannot optimize those aspects by replicating unnecessary information in a protocol message.
   In summary, it is node's internal software design issue and we need not optimize that at protocol level.

- Once the reporting node realizes that it is overloaded, it has to wait for right answer to send OC-OLR
  What is the point of sending OC-OLR for a context for which there is no messaging? Why should the reacting node care if it never sends a message for a context for which the reporting node is overloaded?
  So this waiting is justified since it ensures that the overload is reported only when necessary and only to the applicable reacting node. Not to all the nodes in the network.

- The agent needs to wait for the answer generated by the server and the right context
   The same argument as applicable for the server applies here. The agent need not send out-of-context overload info to a node.
   Why should reacting node receive/process/store the overload info for the scope for which it is not sending any messages.

- For sending OC-OLR in dedicated Diameter application???
  Piggybacking was the first basic principle we agreed before putting other principles in place. So we may want to go back the drawing board if we decide to change this principle.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked] list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- JOuni

On Nov 28, 2013, at 12:40 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> wrote:

> De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich 
> (NSN - DE/Munich) Envoyé : jeudi 28 novembre 2013 10:26 À : ext Jouni 
> Korhonen; Ben Campbell Cc : [email-masked] list Objet : Re: [Dime] 
> DOIC: Self-Contained OLRs
> 
> Hi,
> 
> The more I spent time thinking/writing the actual procedures on the 
> endpoints, the more it makes sense to me to keep the ReportType in the 
> OC-OLR. Even if the baseline does not have agent overload etc, the 
> ReportType fits well to the "endpoint principle" we have in the draft. 
> It indeed gives more tools to make a host vs. realm base decision on the reacting node and is plain more clear.
> 
>> 3) Implicit values don't work at all for certain problems. For 
>> example, if an agent needs to originate an OLR, it typically needs to 
>> insert that OLR into an existing Diameter answer created by a server. 
>> It can't create its own answer without affecting the application 
>> state. If the responding node assumes the OLR comes from or refers to 
>> the node identified by the Origin-Host AVP in the enclosing answer, 
>> things break. (For examples of when an agent needs to send OLRs that 
>> are distinct from those sent by a server, see Steve's agent overload 
>> draft, or my dh/dr example.)
>> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 29 Nov 2013 12:06:25 +0000

Hi Lionel,

there is nothing missing exept the clarification that everything works fine when only one OLR (the OLR created by the reporting endpoint) is present in the answer and additional OLRs (not created by the reporting endpoint) may just be present as an optional optimization i.e. optionally inserted by the reporting endpoint and optionally ignored by the reacting endpoint.

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Lionel

-----Message d'origine-----

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

-----Message d'origine-----

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- Jouni

---

From: <[email-masked]>
Date: Fri, 29 Nov 2013 14:31:45 +0000

I totally agree with Nirav. No need to revert at this stage the working assumption on piggybacking of OLR in application answer messages, especially when the aim is to define a basic mechanism called "reduction".

Anyone would be able to further add extra info for optimization if needed but there is no need at all for the basic mechanism.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot)
Envoyé : vendredi 29 novembre 2013 12:24
À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked] list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Jouni, Ben,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked] list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- JOuni

---

From: Ben Campbell <[email-masked]>
Date: Fri, 29 Nov 2013 08:43:37 -0600

Hi,

It's a holiday weekend in the US. It will be Tuesday before I have a chance to jump back into the fray :-) Other US based people may be in a similar situation.

Thanks!

Ben.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Fri, 29 Nov 2013 15:05:21 +0000

Dear all

In the baseline mechanism as currently defined in the draft, the OLR content is simple, and is related to the message conveying it in particular application  origin host/realm and destination to which the OLR is sent back. As Lionel indicated, it is not so important to know which node inserts the OLR or to have other information.
 
There is a performance aspect to consider: the OLRs defined in the baseline  may be frequently sent  (in particular to compensate possible message losses and to manage the loopback to the reporting node ensuring the quick convergence towards the optimal throughput). So we have to minimize the processing of these OLRs. As OLRs are piggybacked  in the relevant messages,  they may be simply forwarded in the same message by the DAs on the path except if there are particular reasons a DA to act on them.  

I am cautious about duplication of information, it always means additional checks to ensure consistency. If  the OLR has  an application id and origin host  different from the message conveying it, what to do with this OLR, is it an error case? or should it be put in another message in the path? Our current piggybacking mechanism allows the OLR to remain in the same message from the reporting node to the reacting node. 

An important  point is extensibility, as we may have to introduce other type of OLRs, additional AVPs, more sophisticated processing, but these extensions  should not impact the baseline mechanism by making the baseline more complex. the current draft allows extensions without impacting the baseline.

Currently I do not see drawbacks on the OLRs defined for the baseline mechanism. So my comments join the Nirav and Lionel's ones.

Best regards 

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 29 novembre 2013 15:32
À : Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked] list
Cc : Ben Campbell
Objet : Re: [Dime] DOIC: Self-Contained OLRs

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot) Envoyé : vendredi 29 novembre 2013 12:24 À : Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked] list Cc : Ben Campbell Objet : Re: [Dime] DOIC: Self-Contained OLRs

Jouni, Ben,

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Friday, November 29, 2013 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked] list
Cc: Ben Campbell
Subject: Re: [Dime] DOIC: Self-Contained OLRs

- JOuni

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.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Fri, 29 Nov 2013 15:48:31 +0000

Hi Ulrich,

If an additional OLR is present with a different ReportType, why it should be ignored by the reacting node?

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Friday, November 29, 2013 5:36 PM
To: ext [email-masked]; ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

Hi Lionel,

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Friday, November 29, 2013 11:13 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi Ulrich,

Lionel

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]] Envoyé : jeudi 28 novembre 2013 11:30 À : MORAND Lionel IMT/OLN; ext Jouni Korhonen; Ben Campbell Cc : [email-masked] list Objet : RE: [Dime] DOIC: Self-Contained OLRs

Lionel,

We have two cases:

Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 10:31 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen; Ben Campbell
Cc: [email-masked] list
Subject: RE: [Dime] DOIC: Self-Contained OLRs

Hi,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : jeudi 28 novembre 2013 10:26 À : ext Jouni Korhonen; Ben Campbell Cc : [email-masked] list Objet : Re: [Dime] DOIC: Self-Contained OLRs

Hi,

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, November 27, 2013 11:44 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] DOIC: Self-Contained OLRs

> ReportType AVP in an OLR, rather than

The more I spent time thinking/writing the actual procedures on the endpoints, the more it makes sense to me to keep the ReportType in the OC-OLR. Even if the baseline does not have agent overload etc, the ReportType fits well to the "endpoint principle" we have in the draft. It indeed gives more tools to make a host vs. realm base decision on the reacting node and is plain more clear.

- Jouni