Les, > and conclude that this is really “Unidirectional Link Delay” is a leap that I cannot follow.
I would never suggest to do that. My suggestion was to rename "Min Unidirectional Link Delay" to "minimum value of Min/Max Unidirectional Link Delay" and move on. Cheers, R. On Tue, Aug 18, 2020 at 9:18 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > Tony/Robert – > > > > Whatever clarification Peter may choose to make would be fine – but I do > question your casual ignoring of adjectives. 😊 > > > > There are three values being advertised: > > > > 33 - Unidirectional Link Delay > > 34 – Min/Max Unidirectional Link Delay > > Meaning two values are advertised in this codepoint: > > Min Unidirectional Link Delay > > Max Unidirectional Link Delay > > > > Now, the flex algo draft states: Min Unidirectional Link Delay > > > > If you want to argue that “Min Unidirectional Link Delay” != “Min/Max > Unidirectional Link Delay” – I think you are pedantically correct. > > > > But how that leads you to simply truncate “Min” and conclude that this is > really “Unidirectional Link Delay” is a leap that I cannot follow. > > > > Perhaps you don’t really like the fact that RFC 8570 encoding combined > Min/Max in a single codepoint – but that ship sailed years ago. > > > > Given that RFC 8570 is very clear in showing that the encoding includes: > > > > <snip> > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |A| RESERVED | Min Delay | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RESERVED | Max Delay | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > <end snip> > > > > my ability to see your POV is somewhat limited. > > > > Perhaps you could own that a more careful reading is possible? > > > > Les > > > > > > *From:* Lsr <[email protected]> *On Behalf Of * [email protected] > *Sent:* Tuesday, August 18, 2020 10:03 AM > *To:* Robert Raszuk <[email protected]> > *Cc:* Christian Hopps <[email protected]>; > [email protected]; Les Ginsberg (ginsberg) <ginsberg= > [email protected]>; [email protected]; [email protected]; Acee Lindem > (acee) <[email protected]>; Peter Psenak (ppsenak) <[email protected]> > *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo > > > > > > 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]> 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) <ginsberg= > [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]> *On Behalf Of *[email protected] > *Sent:* Tuesday, August 18, 2020 7:44 AM > *To:* Peter Psenak (ppsenak) <[email protected]> > *Cc:* [email protected]; [email protected]; Christian Hopps <[email protected]>; > Acee Lindem (acee) <[email protected]>; [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] > https://www.ietf.org/mailman/listinfo/lsr > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
