Re: [Dime] [dime] #65 (draft-ietf-dime-ovli): Definition of messages impacted by host overload report

[Steve Donovan <[e-mail]>]

All,

I am planning to update the wording per the following minor adjustment 
to Lionel's suggested wording for second paragraph of the following.

Let me know if there are any objections to closing this issue with the 
proposed wording.

       Either the Destination-Host AVP is present in the request and its value

       matches the value of the Origin-Host AVP of the received message

       that contained the OC-OLR AVP; or the Destination-Host is not present

       in the request but the value of peer identity associated with the connection

       used to send the request matches the value of the Origin-Host AVP of the

       received message that contained the OC-OLR AVP.

Regards,

Steve

On 4/23/14, 10:03 AM, dime issue tracker wrote:
> #65: Definition of messages impacted by host overload report
>
>   The current definition of a host overload needs to be enhanced.
>
>   The following is what is currently in the -02 draft:
>
>      0  A host report.  The overload treatment should apply to requests
>         for which all of the following conditions are true:
>
>         The Destination-Host AVP is present in the request and its value
>         matches the value of the Origin-Host AVP of the received message
>         that contained the OC-OLR AVP.
>
>         The value of the Destination-Realm AVP in the request matches the
>         value of the Origin-Realm AVP of the received message that
>         contained the OC-OLR AVP.
>
>         The value of the Application-ID in the Diameter Header of the
>         request matches the value of the Application-ID of the Diameter
>         Header of the received message that contained the OC-OLR AVP.
>
>
>   The second paragraph says that only requests that contain a Destination-
>   Host AVP can be used for overload treatment.
>
>   This does not address the case where there is no agent between the
>   reacting and reporting nodes.  In other words, the reacting node has a
>   direct connection to the reporting node.  In this case the reacting node
>   should include all messages that would be sent to the reporting node,
>   including those that do not contain a Destination-Host AVP and those that
>   the reacting node would sent to the reporting node through normal route
>   selection for requests that do not contain a Destination-Host AVP.
>
>   I propose that the second paragraph be changed to the following:
>
>   "The reacting node knows that the request will be routed to the overloaded
>   Diameter node identified by the Diameter ID in the OLR.  This is the value
>   of the Origin-Host AVP in the message that carried the OLR.  There are two
>   cases where the reacting node will know that the request will be routed to
>   the overloaded node.  The first is the request contains a Destination-Host
>   AVP that matches the Diameter ID contained in the OLR.  The second is when
>   the reacting node selects a route that is a direct connection to the
>   overloaded Diameter node."
>