Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Robert Raszuk <[e-mail]>]

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) <[e-mail]>
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 <[e-mail]> *On Behalf Of * [e-mail]
> *Sent:* Tuesday, August 18, 2020 10:03 AM
> *To:* Robert Raszuk <[e-mail]>
> *Cc:* Christian Hopps <[e-mail]>;
> [e-mail]; Les Ginsberg (ginsberg) <ginsberg=
> [e-mail]>; [e-mail]; [e-mail]; Acee Lindem
> (acee) <[e-mail]>; Peter Psenak (ppsenak) <[e-mail]>
> *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 <[e-mail]> 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=
> [e-mail]> 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 <[e-mail]> *On Behalf Of *[e-mail]
> *Sent:* Tuesday, August 18, 2020 7:44 AM
> *To:* Peter Psenak (ppsenak) <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Christian Hopps <[e-mail]>;
> Acee Lindem (acee) <[e-mail]>; [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
>
>