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

Reply via email to