Hi Robert,
On 18/08/2020 19:10, Robert Raszuk wrote:
Hi Tony,
I am not sure what the deal is :)
But fact is that we never defined a type which this draft is referring to
"Min Unidirectional Link Delay" just does not exist in any IANA registry
so even any search for that will fail.
Perhaps authors assumed that:
Min/Max Unidirectional Link Delay means both "Min Unidirectional Link
Delay" & "Max Unidirectional Link Delay" but this is just asking
for ambiguity.
yes, Min/Max Unidirectional Link Delay advertise both Min and Max and we
use Min out of that.
I'll make the clarification in the draft, so we can close this discussion.
thanks,
Peter
Cheers,
R.
On Tue, Aug 18, 2020 at 7:02 PM <tony...@tony.li
<mailto:tony...@tony.li>> wrote:
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
<mailto: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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
