Re: [ippm] Roman Danyliw's No Objection on draft-ietf-ippm-pam-08: (with COMMENT)

[Alexander L Clemm <[e-mail]>]

(Resending to complete list of recipients; apologies to ippm for the 
duplicate)

On 11/17/2023 7:54 PM, Alexander L Clemm wrote:
>
> Hi,
>
> Roman, thank you for your questions and suggestions; Greg, thank you 
> for for your responses.
>
> I actually disagree with one of the resolutions, as explained inline, 
> <ALEX>.  Specifically, I believe that the original text in 3.1 should 
> be reinstated as the new one is not only not quite correct but would 
> introduce additional issues.
>
> Thanks
>
> --- Alex
>
> On 11/17/2023 12:56 AM, Greg Mirsky wrote:
>> Hi Roman,
>> thank you for your questions and suggestions. Please find my notes 
>> in-lined below tagged GIM>>. Attached, please find the new working 
>> version (Gmail believes that diff contains a virus ;(. )
>>
>> Regards,
>> Greg
>>
>> On Thu, Nov 16, 2023 at 12:08 PM Roman Danyliw via Datatracker 
>> <[e-mail]> wrote:
>>
>>     Roman Danyliw has entered the following ballot position for
>>     draft-ietf-ippm-pam-08: No Objection
>>
>>     When responding, please keep the subject line intact and reply to all
>>     email addresses included in the To and CC lines. (Feel free to
>>     cut this
>>     introductory paragraph, however.)
>>
>>
>>     Please refer to
>>     https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>
>>     for more information about how to handle DISCUSS and COMMENT
>>     positions.
>>
>>
>>     The document, along with other ballot positions, can be found here:
>>     https://datatracker.ietf.org/doc/draft-ietf-ippm-pam/
>>
>>
>>
>>     ----------------------------------------------------------------------
>>     COMMENT:
>>     ----------------------------------------------------------------------
>>
>>     ** Section 3.1.  Consider defining or providing an explanation of
>>     “optimal
>>     level threshold” and “critical threshold” in the definitions of
>>     VI and SVI.
>>     I’m assuming that these are two configured threshold levels.
>>
>> GIM>> You are right. We planned that both thresholds are configured, 
>> i.e., pre-defined, as noted in the document. Both reflect what can be 
>> described as "an acceptable deviation from an ideal performance 
>> metric". The optimal level may be used by a service provider to 
>> detect performance degradation, while the critical level reflects the 
>> requirements of the service customer. Would adding the following 
>> sentence make it clearer:
>> OLD TEXT:
>>    The monitoring of performance parameters to determine the quality of
>>    an interval is performed between the elements of the network that are
>>    referred to for the SLO corresponding to the performance parameter.
>>    Mechanisms of setting levels of a threshold of an SLO are outside the
>>    scope of this document.
>> NEW TEXT:
>>    The monitoring of performance parameters to determine the quality of
>>    an interval is performed between the elements of the network that are
>>    referred to for the SLO corresponding to the performance parameter.
>>    The optimal level threshold may be used by a service provider to
>>    detect performance degradation, while the critical level threshold
>>    reflects the requirements of the service customer.  Mechanisms of
>>    setting levels of a threshold of an SLO are outside the scope of this
>>    document.
>
> <ALEX> Actually, I do not agree with this change.  In particular, I 
> would take issue with the term "optimal level threshold".  What 
> constitutes a Violated Interval is determined by the SLO.  It is the 
> service level objective that, when breached, will cause a 
> corresponding interval to be violated.
>
> Now, SVI has a notion of higher severity - and what constitutes that 
> is again up to the network provider to define.  But there is no notion 
> of optimality.  (Nor is there, in fact, a notion of criticality - it's 
> SVI, not CVI.)
>
> I therefore find the new text to be misleading and believe the 
> original text should be reinstated.  If we believe that additional 
> clarification is needed, we could add another sentence that indicates 
> that the configuration of a threshold which, when breached during an 
> interval, will cause a violation to be registered for that interface, 
> is determined per the definition of the SLO and configured accordingly.
>
> </ALEX>
>
>>
>>     ** Section 3.1.
>>        Beyond accounting for violated intervals, it is sometimes
>>     beneficial
>>        to maintain counts of packets for which a performance threshold is
>>        violated.
>>
>>     No question of the utility of counting packets. However,
>>     shouldn’t there be a
>>     count of flows too?  Section 1 said “This specification
>>     introduces a new set of
>>     metrics, Precision Availability Metrics (PAM), aimed at capturing
>>     end-to-end
>>     service levels for a flow, specifically the degree to which flows
>>     comply with
>>     the SLOs that are in effect.”
>>
>> GIM>> Thank you for the question and highlighted text. PAM is 
>> intended to characterize a single flow, and it seems to me that the 
>> use of plural is confusing. I propose the update as follows:
>> OLD TEXT:
>>    This specification introduces a new set of metrics, Precision
>>    Availability Metrics (PAM), aimed at capturing end-to-end service
>>    levels for a flow, specifically the degree to which flows comply with
>>    the SLOs that are in effect.
>> NEW TEXT:
>>    This specification introduces a new set of metrics, Precision
>>    Availability Metrics (PAM), aimed at capturing end-to-end service
>>    levels for a flow, specifically the degree to which the flow complies
>>    with the SLOs that are in effect.
>> I hope that this update clarifies the scope of PAM.
>>
>> _______________________________________________
>> ippm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ippm