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 <rob...@raszuk.net> 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=40cisco....@dmarc.ietf.org <mailto:40cisco....@dmarc.ietf.org>> > 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 <lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>> On Behalf Of > tony...@tony.li <mailto:tony...@tony.li> > Sent: Tuesday, August 18, 2020 7:44 AM > To: Peter Psenak (ppsenak) <ppse...@cisco.com <mailto:ppse...@cisco.com>> > Cc: lsr@ietf.org <mailto:lsr@ietf.org>; lsr-...@ietf.org > <mailto:lsr-...@ietf.org>; Christian Hopps <cho...@chopps.org > <mailto:cho...@chopps.org>>; Acee Lindem (acee) <a...@cisco.com > <mailto:a...@cisco.com>>; draft-ietf-lsr-flex-algo....@ietf.org > <mailto:draft-ietf-lsr-flex-algo....@ietf.org> > 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 > Lsr@ietf.org <mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr > <https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr