Hi all I think the clarification is mandatory and not only in section 5.1 and not only for the delay.
Indeed, section 5.1 makes reference to [I-D.ietf-isis-te-app] while section 17.1.2 makes reference to RFC8570 with the same error. And what about reference to RFC7471 for OSPF ? And, I also notice the same problem with the TE metric (ref to draft te app in section 5.1 and reference to RFC 5305 in section 17.1.2). So, we need a clear reference to the same document/section/TLVs in both section 5.1 and section 17.1.2 for both delay and TE metric. But, the question behind, it is which documents ? Future RFC about TE app ? RFC 8570 ? RFC 7471 ? As an operator, as of today, I have not the possibility to advertise min/max delay in our network as requested in the draft just because it is not available in all commercial routers. So, referring to a future RFC which take months/years before it becomes available/deploy/operational, leave flex algo with delay not ready before a while. So, to speed up the deployment, I would prefer a reference to a delay value that could be advertise by means of RFC7471, RFC8570 and/or TE-App draft. It is then up to the operator to ensure the coherency of what it is announced in its network by the different routers. Regards Olivier Le 18/08/2020 à 19:02, [email protected] a écrit : > > Robert, > > Thank you, exactly. > > We just need a clarification of the document. I don’t understand why this is > such a big deal. > > Tony > > >> On Aug 18, 2020, at 9:22 AM, Robert Raszuk <[email protected] >> <mailto:[email protected]>> wrote: >> >> Les, >> >> I think this is not very obvious as Tony is pointing out. >> >> See RFC 8570 says: >> >> Type Description >> ---------------------------------------------------- >> 33 Unidirectional Link Delay >> >> 34 Min/Max Unidirectional Link Delay >> >> That means that is someone implementing it reads text in this draft >> literally (meaning Minimum value of Unidirectional Link Delay) it may pick >> minimum value from ULD type 33 :) >> >> If you want to be precise this draft may say minimum value of Min/Max >> Unidirectional Link Delay (34) and be done. >> >> That's all. >> >> Cheers, >> R. >> >> >> >> On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> Tony – >> >> >> >> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure >> why you are confused – nor why you got misdirected to code point 33. >> >> >> >> RFC 8570 (and its predecessor RFC 7810) define: >> >> >> >> 34 Min/Max Unidirectional Link Delay >> >> >> >> This sub-TLV contains two values: >> >> >> >> “Min Delay: This 24-bit field carries the minimum measured link delay >> >> value (in microseconds) over a configurable interval, encoded as >> >> an integer value. >> >> >> >> Max Delay: This 24-bit field carries the maximum measured link delay >> >> value (in microseconds) over a configurable interval, encoded as >> >> an integer value.” >> >> >> >> It seems clear to me that the flex-draft is referring to Min >> Unidirectional Link Delay in codepoint 34. >> >> >> >> I agree it is important to be unambiguous in specifications, but I think >> Peter has been very clear. >> >> Please explain how you managed to end up at code point 33?? >> >> >> >> Les >> >> >> >> >> >> >> >> *From:* Lsr <[email protected] <mailto:[email protected]>> *On >> Behalf Of * [email protected] <mailto:[email protected]> >> *Sent:* Tuesday, August 18, 2020 7:44 AM >> *To:* Peter Psenak (ppsenak) <[email protected] >> <mailto:[email protected]>> >> *Cc:* [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]>; Christian Hopps <[email protected] >> <mailto:[email protected]>>; Acee Lindem (acee) <[email protected] >> <mailto:[email protected]>>; [email protected] >> <mailto:[email protected]> >> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo >> >> >> >> >> >> Hi Peter, >> >> >> >> >> >> section 5.1 of the draft-ietf-lsr-flex-algo says: >> >> >> Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app]. >> >> We explicitly say "Min Unidirectional Link Delay", so this cannot be >> mixed with other delay values (max, average). >> >> >> >> >> >> The problem is that that does not exactly match “Unidirectional Link >> Delay” or “Min/Max Unidirectional Link Delay”, leading to the ambiguity. >> Without a clear match, you leave things open to people guessing. Now, it’s a >> metriic, so of course, you always want to take the min. So type 33 seems >> like a better match. >> >> >> >> >> >> section 7.3. of ietf-isis-te-app says: >> >> Type Description Encoding >> Reference >> --------------------------------------------------------- >> 34 Min/Max Unidirectional Link Delay RFC8570 >> >> >> >> >> >> And it also says: >> >> >> >> 33 Unidirectional Link Delay RFC8570 >> <https://tools.ietf.org/html/rfc8570> >> >> >> >> >> >> This does not help. >> >> >> >> >> >> So, IMHO what we have now is correct and sufficient, but I have no >> issue adding the text you proposed below. >> >> >> >> >> >> What you have now is ambiguous. We have a responsibility, as writers of >> specifications, to be precise and clear. We are not there yet. >> >> >> >> >> >> BTW, before I posted 09 version of flex-algo draft, I asked if you >> were fine with just referencing ietf-isis-te-app in 5.1. I thought you were, >> as you did not indicate otherwise. >> >> >> >> >> >> My bad, I should have pressed the issue. >> >> >> >> >> >> Anyway, I consider this as a pure editorial issue and hopefully not >> something that would cause you to object the WG LC of the flex-algo draft. >> >> >> >> >> >> I’m sorry, I think that this is trivially resolved, but important >> clarification. >> >> >> >> You also have an author’s email that is bouncing, so at least one more >> spin is required. >> >> >> >> Sorry, >> >> Tony >> >> >> >> _______________________________________________ >> Lsr mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/lsr >> > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr -- Orange logo <http://www.orange.com> Olivier Dugeon Orange Expert, Future Networks Open Source Referent Orange/IMT/OLN/WTC/IEE/iTeQ fixe : +33 2 96 07 28 80 mobile : +33 6 82 90 37 85 [email protected] <mailto:[email protected]> _________________________________________________________________________________________________________________________ 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.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
