Subject: Re: [Lsr] IGP TE Metric Extensions

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 5 Jun 2018 16:42:03 +0530

​Please see inline..​

On Fri, Jun 1, 2018 at 2:34 AM, Stefano Previdi (IETF) <[email-masked]>
wrote:

>
>
> On Thu, May 31, 2018, 6:15 PM Muthu Arul Mozhi Perumal <
> [email-masked]> wrote:
>
>> Thanks, Jeff. Would be good to have this clarified in
>> ​​
>> draft-ginsberg-isis-rfc7810bis. My original message seems to have been
>> stripped off, so including it again for the lsr list..
>>
>> ​Both RFC 7810 and RFC 7471 say that:
>>
>>    The measurement interval, any filter coefficients, and any
>>    advertisement intervals MUST be configurable per sub-TLV.
>>
>>    Additionally, the default measurement interval for all sub-TLVs
>>    SHOULD be 30 seconds.
>>
>> However, both RFCs initially say that they only describe mechanisms for
>> disseminating performance information and methods of measurements is
>> outside their scope.
>>
>> Moreover, for a first time reader, it seems to suggest that the
>> measurement interval and filter coefficient must be supported and
>> configurable under the IGP.
>>
>
>
> No. This is not suggested in any form.
> It is clearly indicated that the draft does not deal with measurements
> which means no recommendation is made.
>
>
> In a system supporting multiple IGPs, I would expect that they be
>> implemented outside the IGP and the IGPs just disseminate the information
>> provided to them.
>>
>> Thoughts, especially from an implementation standpoint?
>>
>
>
> Again, the draft is only about dissemination, not measurements.
>

​How is the measurement interval and filter coefficients described in the
draft related to dissemination?​

​   The measurement interval, any filter coefficients, and any
   advertisement intervals MUST be configurable per sub-TLV.

   Additionally, the default measurement interval for all sub-TLVs
   SHOULD be 30 seconds.​

> If your question is related to configuration and implementation of
> measurements, well it will not be addressed by this draft.
>
> We intentionally left out this part that does not belong to the igp
> protocol machinery.
>

​Which of the functionalities described in sections 5, 6, 7 of the draft
belong to the IGP protocol machinery?

Regards,
Muthu

>
> s.
>
>
>
>> Regards.
>> Muthu
>>
>> On Thu, May 31, 2018 at 11:37 AM, Jeff Tantsura <[email-masked]>
>> wrote:
>>
>>> Muthu,
>>>
>>> LSR would be a more suitable list to post to, CCed.
>>>
>>> Regards,
>>> Jeff
>>>
>>> > On May 30, 2018, at 18:06, Muthu Arul Mozhi Perumal <
>>> [email-masked]> wrote:
>>> >
>>> > Muthu
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 5 Jun 2018 11:30:02 +0000

Hi Muthu,

The Sections 5, 6 and 7 of these drafts are critical as it impacts the IGP protocol operation and stability though it is not an integral part of the IGP protocol machinery. This functionality in a system, whether achieved in the IGP/measurement/some-other module, is an implementation specific aspect.

To answer your question, these aspects may be implemented outside the core IGP module and the IGPs simply flood these while satisfying the aspects specified in the document.

Thanks,
Ketan

From: Lsr <[email-masked]> On Behalf Of Muthu Arul Mozhi Perumal
Sent: 05 June 2018 16:42
To: Stefano Previdi (IETF) <[email-masked]>
Cc: [email-masked]; Jeff Tantsura <[email-masked]>
Subject: Re: [Lsr] IGP TE Metric Extensions

​Please see inline..​

On Fri, Jun 1, 2018 at 2:34 AM, Stefano Previdi (IETF) <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, May 31, 2018, 6:15 PM Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Jeff. Would be good to have this clarified in
​​
draft-ginsberg-isis-rfc7810bis. My original message seems to have been stripped off, so including it again for the lsr list..

However, both RFCs initially say that they only describe mechanisms for disseminating performance information and methods of measurements is outside their scope.

Moreover, for a first time reader, it seems to suggest that the measurement interval and filter coefficient must be supported and configurable under the IGP.

No. This is not suggested in any form.
It is clearly indicated that the draft does not deal with measurements which means no recommendation is made.

In a system supporting multiple IGPs, I would expect that they be implemented outside the IGP and the IGPs just disseminate the information provided to them.

Again, the draft is only about dissemination, not measurements..

​How is the measurement interval and filter coefficients described in the draft related to dissemination?​

If your question is related to configuration and implementation of measurements, well it will not be addressed by this draft.

We intentionally left out this part that does not belong to the igp protocol machinery.

​Which of the functionalities described in sections 5, 6, 7 of the draft belong to the IGP protocol machinery?

Regards,
Muthu

s.

Regards.
Muthu

On Thu, May 31, 2018 at 11:37 AM, Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
Muthu,

Regards,
Jeff

> On May 30, 2018, at 18:06, Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:
>
> Muthu

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 5 Jun 2018 17:18:44 +0530

Sounds reasonable to me..

Adding a clarification note in the draft would be useful, IMHO.

Regards,
Muthu

On Tue, Jun 5, 2018 at 5:00 PM, Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> Hi Muthu,
>
>
>
> The Sections 5, 6 and 7 of these drafts are critical as it impacts the IGP
> protocol operation and stability though it is not an integral part of the
> IGP protocol machinery. This functionality in a system, whether achieved in
> the IGP/measurement/some-other module, is an implementation specific aspect.
>
>
>
> To answer your question, these aspects may be implemented outside the core
> IGP module and the IGPs simply flood these while satisfying the aspects
> specified in the document.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Muthu Arul Mozhi Perumal
> *Sent:* 05 June 2018 16:42
> *To:* Stefano Previdi (IETF) <[email-masked]>
> *Cc:* [email-masked]; Jeff Tantsura <[email-masked]>
> *Subject:* Re: [Lsr] IGP TE Metric Extensions
>
>
>
>
>
> ​Please see inline..​
>
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 5 Jun 2018 12:03:59 +0000

Hi Muthu,

These are implementation specific aspects and I am not sure if this is something that the draft should be getting into.

Thanks,
Ketan

From: Muthu Arul Mozhi Perumal <[email-masked]>
Sent: 05 June 2018 17:19
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Stefano Previdi (IETF) <[email-masked]>; [email-masked]; Jeff Tantsura <[email-masked]>
Subject: Re: [Lsr] IGP TE Metric Extensions

Regards,
Muthu

On Tue, Jun 5, 2018 at 5:00 PM, Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Muthu,

Thanks,
Ketan

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Muthu Arul Mozhi Perumal
Sent: 05 June 2018 16:42
To: Stefano Previdi (IETF) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] IGP TE Metric Extensions

​Please see inline..​

Regards,
Muthu

s.

Regards.
Muthu

Regards,
Jeff

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 5 Jun 2018 17:51:50 +0530

If these are only implementation specific aspects and shouldn't get into
the draft, what is the point of sections 5,6,7? Why would it hurt to say
what is generally expected to be part of the protocol machinery and what is
not?

BTW, any known implementation for RFC 7810, also supporting sections 5,6,7?

Regards,
Muthu

On Tue, Jun 5, 2018 at 5:33 PM, Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> Hi Muthu,
>
>
>
> These are implementation specific aspects and I am not sure if this is
> something that the draft should be getting into.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Muthu Arul Mozhi Perumal <[email-masked]>
> *Sent:* 05 June 2018 17:19
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* Stefano Previdi (IETF) <[email-masked]>; [email-masked]; Jeff Tantsura
> <[email-masked]>
>
> On Tue, Jun 5, 2018 at 5:00 PM, Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi Muthu,
>
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 5 Jun 2018 12:41:07 +0000

Hi Muthu,

The sections 5,6,7 specify the required aspects that an implementation needs to take care of (with all its normative language) - it specifies the “WHAT” part.

Your questions were related to the “WHERE” and “HOW” parts for the same (e.g. when you asked “configurable under IGP” and “outside the IGP” and so on) and these are implementation specific aspects which IMHO do not necessarily belong to this document.

Hope that clarifies.

I am aware of an implementation that does support certain aspects from section 5,6,7.

Thanks,
Ketan

Sent: 05 June 2018 17:52

If these are only implementation specific aspects and shouldn't get into the draft, what is the point of sections 5,6,7? Why would it hurt to say what is generally expected to be part of the protocol machinery and what is not?

Regards,
Muthu

On Tue, Jun 5, 2018 at 5:33 PM, Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Muthu,

Thanks,
Ketan

From: Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>>
Sent: 05 June 2018 17:19
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: Stefano Previdi (IETF) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>

Regards,
Muthu

Thanks,
Ketan

​Please see inline..​

Regards,
Muthu

s.

Regards.
Muthu

Regards,
Jeff

---

From: stefano previdi <[email-masked]>
Date: Tue, 5 Jun 2018 14:42:31 +0200

> On Jun 5, 2018, at 2:21 PM, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> 
> If these are only implementation specific aspects and shouldn't get into the draft, what is the point of sections 5,6,7?

these sections describe the requirements implementations must address. The way they address them is out of scope of the document.

s.

> Why would it hurt to say what is generally expected to be part of the protocol machinery and what is not?

> On Tue, Jun 5, 2018 at 5:33 PM, Ketan Talaulikar (ketant) <[email-masked]> wrote:
> Hi Muthu,
> 
>  
> 
> On Tue, Jun 5, 2018 at 5:00 PM, Ketan Talaulikar (ketant) <[email-masked]> wrote:
> 
> Hi Muthu,
> 
>  
> 
> On Fri, Jun 1, 2018 at 2:34 AM, Stefano Previdi (IETF) <[email-masked]> wrote:
> 
>  
> 
> On Thu, May 31, 2018, 6:15 PM Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> 
> On Thu, May 31, 2018 at 11:37 AM, Jeff Tantsura <[email-masked]> wrote:
> 
> Muthu,
> 
> > On May 30, 2018, at 18:06, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> > 
> > Muthu
> 
>  
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Jun 2018 17:58:47 +0200

​Muthu,​

> draft related to dissemination?​

​It is directly related. If you see the title of the section is:
"Announcement Thresholds and Filters"​

So measurement interval does not intend to describe how often you actually
measure ... it describes a time window where you report the value (which
could consist of many measurements actually taken).

> belong to the IGP protocol machinery?

​What draft are you talking about ? I was under impression that we are
discussing RFCs here.

​All functionality from sections 5-7 aim to provide machinery to control
stability of protocol operation. It is one how you measure and this is not
part of the RFCs. and completely different what and how you advertised
derived values from those gathered by your measurements. Now keeping in
mind that you do not advertise when you measure but only when you are
allowed by protocol rules it should be easy to see the point which Stefano
made above.

​Thx,
R.

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 6 Jun 2018 06:56:04 +0530

Robert,

> could consist of many measurements actually taken).

​Are you saying measurement interval is a misnomer? The draft clearly
distinguishes measurement interval from announcement interval:

​   Additionally, the default measurement interval for all sub-TLVs
   SHOULD be 30 seconds.

   Announcements MUST also be able to be throttled using configurable
   inter-update throttle timers.  The minimum announcement periodicity
   is 1 announcement per second.  The default value SHOULD be set to 120
   seconds.​

Yet, it claims measurements are outside its scope..

> ​What draft are you talking about ? I was under impression that we are

​Well, both -:) I am referring to draft-ginsberg-lsr-isis-rfc7810bis and I
believe there is a chance to improve some text in RFC7810..

Regards,
Muthu

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 6 Jun 2018 05:42:51 +0000

Muthu –

I agree with the comments from all of the folks who have responded to you thus far.
The RFC is specifying what the externally visible behavior needs to be in order for the feature to be safely and usefully deployed – it is not specifying HOW to implement that behavior.

But, let’s assume for the moment that you are “right” and that the draft wording is suggesting that configuration knobs for the thresholds/filters should be owned by the IGP.
If, despite this “suggestion”, you were to decide to implement the knobs elsewhere (e.g., under the interface) – would it affect interoperability? Would it be detectable from the vantage point of another router?

I don’t agree with your interpretation –and I don’t feel that any change in the text is needed.
But I do defend your right to implement the knobs wherever you like.

However, before making your decision you might want to consider https://tools.ietf.org/html/draft-ietf-teas-yang-te-14#section-3.2 - which is relevant from a manageability perspective. Your choice of where to put the knobs might indeed matter (though not to the IGP externally visible behavior).

   Les

From: Lsr <[email-masked]> On Behalf Of Muthu Arul Mozhi Perumal
Sent: Tuesday, June 05, 2018 6:26 PM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; Jeff Tantsura <[email-masked]>; Stefano Previdi (IETF) <[email-masked]>
Subject: Re: [Lsr] IGP TE Metric Extensions

Robert,

On Tue, Jun 5, 2018 at 9:28 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
​Muthu,​

​It is directly related. If you see the title of the section is: "Announcement Thresholds and Filters"​

So measurement interval does not intend to describe how often you actually measure ... it describes a time window where you report the value (which could consist of many measurements actually taken).

​Are you saying measurement interval is a misnomer? The draft clearly distinguishes measurement interval from announcement interval:

​What draft are you talking about ? I was under impression that we are discussing RFCs here.

​Well, both -:) I am referring to draft-ginsberg-lsr-isis-rfc7810bis and I believe there is a chance to improve some text in RFC7810..

Regards,
Muthu

​All functionality from sections 5-7 aim to provide machinery to control stability of protocol operation. It is one how you measure and this is not part of the RFCs. and completely different what and how you advertised derived values from those gathered by your measurements. Now keeping in mind that you do not advertise when you measure but only when you are allowed by protocol rules it should be easy to see the point which Stefano made above.

​Thx,
R.