Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages

On Feb 4, 2014, at 5:01 PM, lionel.morand@orange.com wrote:

> I think that there is actually an issue here but the proposed way to solve it is not the correct one.

Agree.

> The initial idea was to be able to use the same overload report with several algorithms. So the OLR was somehow only meaningful along with the OC-Feature-Vector AVP.

The initial idea was to go on lines of RFC5447.

> But because the OC-Feature-Vector AVP is defined as a set of flags, it is not possible to say that this OLR is to be used with only one given algo when more than one is defined (as the bit flags will advertize 1 AND 2 for 2 supported algos). So the OC-Feature-Vector cannot be used to indicate the abatement to perform.

My intention was always allow:

  client announces  ABC
  server supports    BCD
  server announced only  e.g. C since it is common
  alternatively server announced nothing and then the default applies

> As the syntax of the OC-Feature-Vector is adapted to advertize supported algos, it could be easier to clarify that the OC-OLR AVP is THE report AVP for the reduction algo (default) and a new dedicated report AVP must be created when a new algo is introduced. In this way, the OC-OLR is self-explicit.

Bah. OLR should work for additional abatement algorithms
IF we agree that the OLR is align with the announced
abatement algorithm.. 

> It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.

It is already today if you only support the default, right.

- Jouni

> 
> Lionel 
> 
> -----Message d'origine-----
> De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org] 
> Envoyé : mardi 4 février 2014 09:48
> À : MORAND Lionel IMT/OLN
> Cc : dime@ietf.org
> Objet : [dime] #30: OC-Supported-Features AVP in answer messages
> 
> #30: OC-Supported-Features AVP in answer messages
> 
> According to the current feature advertisement/negotiation mechanism in
> the -01 draft reporting DOIC endpoint insert an OC-Supported-Features AVP
> in answer messages to indicate their supported OC features to the reacting
> DOIC endpoint.
> The author of this document believes that  the best a reacting node can do
> with such information is to ignore it, and therefore proposes to allow
> reporting nodes not to insert OC-Supported-Features AVPs in answer
> messages.
> Currently only one feature is defined (OLR_DEFAULT_ALGO).
> A reacting DOIC endpoint that supports only OLR_DEFAULT_ALGO but no other
> feature is only interested in receiving/not receiving OC-OLR AVPs from
> reporting DOIC-endpoints. Receiving an OC-OLR AVP implicitly indicates
> support of OLR_DEFAULT_ALGO  by the reporting DOIC endpoint; not receiving
> an OC-OLR-AVP from the reporting DOIC endpoint may have two reasons:
> 
> a) There is no overload
> b) DOIC is not supported
> 
> The reacting DOIC endpoint does not need to differentiate between these
> two cases as the behavior (do not throttle) is the same in both cases.
> The -01 draft says in  clause 4.1:
>    If there is no single matching
>    capability the reacting node MUST act as if it does not implement
>    DOIC and cease inserting any DOIC related AVPs into any Diameter
>    messages with this specific reacting node.
> 
> This however is inconsistent.
> The reacting node that ceases sending DOIC related AVPs would never
> recognize when the server is upgraded to support DOIC.
> Subsequent requests (not including DOIC related AVPs) may take a different
> path towards the server and on that path there may be an agent that
> supports DOIC (with a match of supported features) and could take the role
> of the reporting DOIC endpoint; but the agent cannot take this role since
> the reacting node (although supporting DOIC) ceased sending of OC-
> Supported-Features AVPs.
> In summary: As long as no extension feature is defined within  draft-ietf-
> dime-ovli  (i.e. never, since extensions will  be defined in other
> drafts), there is no need for draft-ietf-dime-ovli  to mandate or even
> describe inclusion of OC-Supported-Features AVP in answer messages.
> 
> -- 
> --------------------------------------+--------------------------
> Reporter:  lionel.morand@orange.com  |      Owner:  Ulrich Wiehe
>     Type:  defect                    |     Status:  new
> Priority:  major                     |  Milestone:
> Component:  draft-docdt-dime-ovli     |    Version:
> Severity:  Active WG Document        |   Keywords:
> --------------------------------------+--------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/30>
> dime <http://tools.ietf.org/wg/dime/>
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime