Opened 6 years ago

Closed 5 years ago

#26 closed defect (fixed)

Overload Control Endpoints under specified

Reported by: srdonovan@… Owned by: draft-ietf-dime-ovli@…
Priority: blocker Milestone:
Component: draft-ietf-dime-ovli Version:
Severity: Submitted WG Document Keywords:
Cc: dime@…


This applies to draft-ietf-dime-ovli.

The concept of an overload control endpoint is under specified. For instance, a number of figures show DOIC associations that both end at an agent diameter overload endpoint and pass through an agent diameter overload endpoint.

If both cases apply then how do Diameter nodes know the identity of the other side of an endpoint.

Does this mean that a Diameter client can receive multiple capability advertisements in a single message, one created by the server and a separate one created by the agent?

My understanding of Diameter endpoints was that they were truly endpoints. If an agent was acting as an endpoint it would handle capability negotiation between all clients and the agent and between all servers and the agent. In essence it would be acting as a back-to-back diameter overload agent, as mentioned in section 3.1.5.

Change History (2)

comment:1 Changed 6 years ago by jouni.nospam@…

  • Component changed from draft-docdt-dime-ovli to draft-ietf-dime-ovli
  • Owner changed from draft-docdt-dime-ovli@… to draft-ietf-dime-ovli@…

comment:2 Changed 5 years ago by srdonovan@…

  • Resolution set to fixed
  • Status changed from new to closed

Concept of DOIC endpoint and DOIC associations removed from the document per agreement reached in the Toronto IETF meeting.

Note: See TracTickets for help on using tickets.