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

[Jouni Korhonen <[e-mail]>]

On Feb 7, 2014, at 3:54 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]> wrote:

> See inline
> 
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:[e-mail]] 
> Sent: Friday, February 07, 2014 11:09 AM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext [e-mail]; [e-mail]
> Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
> 
> 
> On Feb 5, 2014, at 10:03 AM, "Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]> wrote:
> 
>> Hi Loinel,
>> 
>> it seems that we can safely remove OC-Supported-Feature AVP from answer messages in the draft-ietf-dime-ovli (which does not define extensions to itself). This does not mean that a future extension cannot (re)-introduce it when needed. It also does not mean that reporting nodes are not allowed to include it in answer messages as long as answer messages have a *[AVP].
> 
> Not so fast. Leaving OC-Supported-Feature AVP away from the 
> answer is already supported by the -01. So there is nothing
> to fix in that part.
> <Ulrich> it seems you agree that 
> a) reporting nodes that only support OLR_DEFAULT_ALGO are not required to send OC-Supported-Features AVP in answer messages (of course they may if there is the *[AVP])

As I said this is already in the draft, thus ok. We just need to
clarify the use of OC-Supported-Features, remove the contradicting
text and clarify that the absence of the OC-Supported-Features
equals to the OLR_DEFAULT_ALGO (currently it only states that for
the OC-Feature-Vector).

- JOuni


> b) reacting nodes that only support  OLR_DEFAULT_ALGO can safely ignore OC-Supported-Features AVPs received in answer messages
> c) behavior of the reacting node that only supports OLR_DEFAULT_ALGO does not depend on presence/absence of OC-Supported-Features AVPs in received answer messages
> if that's agreed, why not say so clearly in the draft?
> (the clear way to say so is to remove this AVP from answers. </Ulrich>
> 
> 
> The thing that need to be fixed is the inconsistency on you
> pointed out which would make reacting node not to send any
> DOIC AVPs.
> 
> - JOuni
> 
>> 
>> Best regards
>> Ulrich
>> 
>> -----Original Message-----
>> From: ext [e-mail] [mailto:[e-mail]] 
>> Sent: Tuesday, February 04, 2014 5:51 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
>> Subject: RE: [dime] #30: OC-Supported-Features AVP in answer messages
>> 
>> Hi Ulrich,
>> 
>> For the point 2 and 3, the difference between the "Should" and the "May" is quite subtle here and is for me only an implementation option.
>> 
>> For 4 and 5, ok if the node only supports the default algo. In other words, only the OLR matters for nodes supporting only the default algo. The rest is purely for information and can be safely ignored.
>> 
>> For 6, if the new feature consists in a new algo, it would mean defining a new dedicated OLR AVP. So nodes supporting only the default algo will ignore any unknown AVP if received.
>> 
>> Regards,
>> 
>> Lionel
>> 
>> -----Message d'origine-----
>> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:[e-mail]] 
>> Envoyé : mardi 4 février 2014 17:04
>> À : MORAND Lionel IMT/OLN; [e-mail]
>> Objet : RE: [dime] #30: OC-Supported-Features AVP in answer messages
>> 
>> Dear Lionel,
>> 
>> thank you for your response.
>> 
>> If I correctly understand, the principles would be:
>> 1. Sending OC-Supported-Features in answer messages is syntactically optional.
>> 2. When the reacting node does only support OLR_DEFAULT_ALGO , the reporting node should not insert an OC-Supported-Features AVP in the answer message.
>> 3. When the reporting node does only support OLR_DEFAULT_ALGO, it should not insert an OC-Supported-Features AVP in the answer message.
>> 4. A reacting node that supports only OLR_DEFAULT_ALGO can safely ignore OC-Supported-Features AVPs received in answer messages.
>> 5. A reacting node that supports only OLR_DEFAULT_ALGO can safely ignor all extensions received in an OC-OLR.
>> 6. When a new feature is introduced, the spec introducing the new feature must define the details to ensure interoperability of nodes supporting the new feature with nodes that do not support the new feature (taking into account that nodes not supporting the new feature act according to the principles 1.-5.).
>> 
>> 
>> Best regards
>> Ulrich
>> 
>> 
>> 
>> -----Original Message-----
>> From: DiME [mailto:[e-mail]] On Behalf Of ext [e-mail]
>> Sent: Tuesday, February 04, 2014 4:01 PM
>> To: [e-mail]
>> Subject: Re: [Dime] [dime] #30: OC-Supported-Features AVP in answer messages
>> 
>> I think that there is actually an issue here but the proposed way to solve it is not the correct one.
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> It would be purely optional to send the Supported-Features AVP along with the OC-OLR AVP.
>> 
>> Lionel 
>> 
>> -----Message d'origine-----
>> De : dime issue tracker [mailto:[e-mail]] 
>> Envoyé : mardi 4 février 2014 09:48
>> À : MORAND Lionel IMT/OLN
>> Cc : [e-mail]
>> 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:  [e-mail]  |      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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>