Re: [Dime] WLGC #2 for draft-ietf-dime-ovli-06

[Maria Cruz Bartolome <[e-mail]>]

Dear all,

A) About 'M' bit:

My understanding of RFC6733:

      The 'M' bit, known as the Mandatory bit, indicates whether the
      receiver of the AVP MUST parse and understand the semantics of the
      AVP including its content.  The receiving entity MUST return an
      appropriate error message if it receives an AVP that has the M-bit
      set but does not understand it.  An exception applies when the AVP
      is embedded within a Grouped AVP.  See Section 4.4 for details.

       4.4:
   Receivers of a Grouped AVP that
   does not have the 'M' (mandatory) bit set and one or more of the
   encapsulated AVPs within the group has the 'M' (mandatory) bit set
   MAY simply be ignored if the Grouped AVP itself is unrecognized.  The
   rule applies even if the encapsulated AVP with its 'M' (mandatory)
   bit set is further encapsulated within other sub-groups, i.e., other
   Grouped AVPs embedded within the Grouped AVP.


If the Grouped AVP does not have the 'M' bit set, but one (or more) of its sub-AVPs do have it, then the grouped AVP may be ignored (instead of sending an error) if the Grouped AVP itself is "unrecognized"
But what "unrecognized" mean in this context? In my opinion, the grouped AVP is not recognized as long as mandatory sub-AVPs are missed, this includes conditionally mandatory (up to negotiation) sub AVPs.
Then I would proposed a variant to your proposal 2 below:

3) sub-AVPs of DOIC grouped AVPs MUST NOT  have the m-bit set unless the sub-avp is mandatory or conditionally mandatory (i.e. part of an extension explicitly negotiated in the feature vector).


B) Going out of 100% reduction

I think we should keep 5.2.2 as it is.
But I think there is a bit of misalignment with 6.3. I will propose following rephrasing:

Now: 5th paragraph:

   If reacting node comes out of the 100 percent traffic reduction as a
   result of the overload report timing out, the following procedures
   are RECOMMENDED to be applied.  The reacting node sending the traffic
   should be conservative and, for example, first send "probe" messages
   to learn the overload condition of the overloaded node before
   converging to any traffic amount/rate decided by the sender.  Similar
   concerns apply in all cases when the overload report times out unless
   the previous overload report stated 0 percent reduction.

Proposed: 5th paragraph:

   If reacting node comes out of the 100 percent traffic reduction as a
   result of the overload report timing out,					<--
                                                                the reacting node sending the traffic	<--
   SHOULD be conservative and, for example, first send "probe" messages	<--
   to learn the overload condition of the overloaded node before
   converging to any traffic amount/rate decided by the sender.  Similar
   concerns apply in all cases when the overload report times out unless
   the previous overload report stated 0 percent reduction.


Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of Steve Donovan
Sent: jueves, 22 de enero de 2015 15:38
To: [e-mail]
Subject: Re: [Dime] WLGC #2 for draft-ietf-dime-ovli-06

All,

We need to close these two issues to finish WGLC #2.

Please review an let me know if the alternatives I have outlined below are acceptable.

Thanks,

Steve

On 1/20/15 3:08 PM, Steve Donovan wrote:
>
> On 1/20/15 1:20 PM, Ben Campbell wrote:
>>> On Jan 20, 2015, at 12:42 PM, Steve Donovan 
>>> <[e-mail]> wrote:
>>>
>>> The following is the resolution of Ben's issues that were not 
>>> addressed directly in an email thread started by Ulrich.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>>> -- 5.3, 4th paragraph:
>>>>
>>>> As I mentioned in previous discussion, after re-reading the related 
>>>> text in 6733, it's no longer clear to me this works like we thought 
>>>> it did. That is, I think any attempt to make sub-AVPs mandatory 
>>>> risks causing errors in the enclosing Diameter transaction. I don't 
>>>> know how to solve this, other just disallowing mandatory sub-AVPs.
>>>> (Jouni previously convinced me 6733 treatment of the m-bit in 
>>>> sub-avps worked like we wanted--perhaps he can re-convince me :-)
>>>>
>>> SRD>Given that Jouni successfully convinced Ben about the 6733
>>> treatment, I'm not planning to make any changes, as I'm assuming he 
>>> can be just as successful the second time.
>> I think that's a bad assumption.
>>
>> We had previously assumed that if a node receives a grouped AVP 
>> (without the m-bit set) that includes an unrecognized sub-avp with 
>> the m-bit set, then the receiver could just ignore the entire grouped 
>> AVP, and otherwise process the transaction. But 6733 actually says 
>> the following:
>>
>> "Receivers of a Grouped AVP that
>>     does not have the 'M' (mandatory) bit set and one or more of the
>>     encapsulated AVPs within the group has the 'M' (mandatory) bit set
>>     MAY simply be ignored if the Grouped AVP itself is unrecognized.  
>> The
>>     rule applies even if the encapsulated AVP with its 'M' (mandatory)
>>     bit set is further encapsulated within other sub-groups, i.e., other
>>     Grouped AVPs embedded within the Grouped AVP."
>>
>> Note the "... if the Grouped AVP itself is unrecognized." clause.
>>
>> The case we have in mind is when you receive a _recognized_ grouped 
>> AVP (that is, you implement DOIC), but it includes an unrecognized 
>> sub-avp with the M-bit set. This is not covered by the exception.
>> This would seem to indicate that the entire request must fail. I 
>> don't think that's what we want.
> SRD> I see how it could be interpreted that way.
>>
>> At this point, I think we need to either say that sub-avps of DOIC 
>> grouped AVPs either 1) MUST NOT have the m-bit set, or 2) MUST NOT 
>> have the m-bit set unless the sub-avp is part of an extension 
>> explicitly negotiated in the feature vector.
> SRD> I'm ok either way but prefer number 2).
>>
>>
>>
> [...]
>>>> Paragraph 5:
>>>>
>>>> Is this redundant to the last paragraph of 5.2.2?
>>>>
>>> SRD> I don't see an issue.  One is general and the other specific to
>>> the loss algorithm.  They don't conflict.
>> The one in 5.2.2 is specific to situations where an OLR quenches all 
>> requests, and says MUST. So is this, and says RECOMMENDED (which 
>> means SHOULD in 2119).
> SRD>Actually 5.2.2 isn't only about quenching.  It's also about the
> reacting node having sent no traffic, because it had no traffic to 
> send, and now needs to send traffic soon after the OCS expires. The 
> reporting node might still be in an overload state but the reacting 
> node doesn't know until the first request is sent.
>>
>> If the idea is that the text in 6.3 is the recommended way to fulfill 
>> the MUST in 5.2.2, then that's okay I guess (although I would prefer 
>> one of the two to be non-normative.)
> SRD> 6.3 deals specifically with quenching, thus is a little different
> than 5.2.2, although there is overlap.
>>
>> Another approach would to leave this to 6.3, and add something to the 
>> effect that any new algorithm that can cause total quenching of 
>> requests must address how the reacting node restarts from that state.
> SRD> I prefer to leave it as it currently is.
>>
>> [...]
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime