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

From: "dime issue tracker" <[email-masked]>
Date: Wed, 23 Apr 2014 15:03:05 -0000

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

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-dime-
  [email-masked]           |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-ietf-dime-ovli     |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/65>
dime <http://tools.ietf.org/wg/dime/>

---

From: Steve Donovan <[email-masked]>
Date: Mon, 28 Apr 2014 13:35:00 -0500

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

       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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Apr 2014 15:46:50 -0500

On Apr 28, 2014, at 1:35 PM, Steve Donovan <[email-masked]> wrote:

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

s/"of peer identity"/"of the peer identity"

Otherwise WFM.

/Ben

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 29 Apr 2014 07:24:51 +0000

Steve,

I agree with the principle, however, with regard to e.g. issue #66, it may eventually not be the "value of the Origin-Host AVP of the received message that contained the OC-OLR AVP".

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Ben Campbell
Sent: Monday, April 28, 2014 10:47 PM
To: Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] [dime] #65 (draft-ietf-dime-ovli): Definition of messages impacted by host overload report

Otherwise WFM.

/Ben
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Apr 2014 09:17:05 -0500

> I agree with the principle, however, with regard to e.g. issue #66, it may eventually not be the "value of the Origin-Host AVP of the received message that contained the OC-OLR AVP".

Thank's for bring that up!

I think it likely we will have to put the origin-host identity inside the OLR before this is all said and done, but I think Steve's language makes sense until such time that we have a conclusion on issue 66.

Thanks!

/Ben