> On Jun 5, 2018, at 2:21 PM, Muthu Arul Mozhi Perumal <[email protected]> > 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? > > 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 protected]> > 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 protected]> > Sent: 05 June 2018 17:19 > To: Ketan Talaulikar (ketant) <[email protected]> > Cc: Stefano Previdi (IETF) <[email protected]>; [email protected]; Jeff Tantsura > <[email protected]> > > > Subject: Re: [Lsr] IGP TE Metric Extensions > > > > 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 protected]> > 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 protected]> On Behalf Of Muthu Arul Mozhi Perumal > Sent: 05 June 2018 16:42 > To: Stefano Previdi (IETF) <[email protected]> > Cc: [email protected]; Jeff Tantsura <[email protected]> > Subject: Re: [Lsr] IGP TE Metric Extensions > > > > > > Please see inline.. > > > > On Fri, Jun 1, 2018 at 2:34 AM, Stefano Previdi (IETF) <[email protected]> > wrote: > > > > On Thu, May 31, 2018, 6:15 PM Muthu Arul Mozhi Perumal <[email protected]> > 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 protected]> > 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 protected]> > > wrote: > > > > Muthu > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
