Opened 5 years ago

Closed 5 years ago

#72 closed enhancement (fixed)

Reporting Node Behaviour when OC-OLR is not received

Reported by: maria.cruz.bartolome@… Owned by: draft-ietf-dime-ovli@…
Priority: minor Milestone:
Component: draft-ietf-dime-ovli Version:
Severity: Active WG Document Keywords:
Cc:

Description

A clarification is required to consider that an answer message may not include OC-OLR and still the reporting node be overloaded, since it is considered as "no change", as documented in 4.2.1.3:

Reacting nodes do not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change").

Original text:

5.3. Reporting Node Behavior (Normative)

The method a reporting nodes uses to determine the amount of traffic reduction required to address an overload condition is an implementation decision.

When a reporting node that has selected the loss abatement algorithm determines the need to request a traffic reduction it must include an OC-OLR AVP in all response messages.

Proposed addition:

5.3. Reporting Node Behavior (Normative)

The method a reporting nodes uses to determine the amount of traffic reduction required to address an overload condition is an implementation decision.

When a reporting node that has selected the loss abatement algorithm determines the need to request a traffic reduction it must include an OC-OLR AVP in all response messages. OC-OLR AVP is not included when reporting node expectations on traffic reduction are not modified. That is, if OC-OLR AVP is not included it is interpreted as “no change”.

Change History (1)

comment:1 Changed 5 years ago by srdonovan@…

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

Added the following to section 4.2.3 per previous email discussions:

A reporting node MAY choose to not send an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node.

Note - In some cases (e.g. when there are one or multiple agents in the path between reporting and reacting nodes, or when overload reports are discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report.

Also changed wording in the loss section reporting node behavior section to refer to section 4.2.3.

Note: See TracTickets for help on using tickets.