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

[Peter Psenak <[e-mail]>]

Olivier,

On 19/08/2020 13:42, [e-mail] wrote:
> Hi all
> 
> I think the clarification is mandatory and not only in section 5.1 and 
> not only for the delay.
> 
> Indeed, section 5.1 makes reference to [I-D.ietf-isis-te-app] while 
> section 17.1.2 makes reference to RFC8570 with the same error. And what 

ok, I will make the same clarification there.


> about reference to RFC7471 for OSPF ? 

will add that.


> And, I also notice the same 
> problem with the TE metric (ref to draft te app in section 5.1 and 
> reference to RFC 5305 in section 17.1.2).

will fix that.


> 
> So, we need a clear reference to the same document/section/TLVs in both 
> section 5.1 and section 17.1.2 for both delay and TE metric.
> 
> But, the question behind, it is which documents ? Future RFC about TE 
> app ? RFC 8570 ? RFC 7471 ?

I don't understand. Min/Max Unidirectional Link Delay is clearly defined 
in RFC 8570 RFC 7471. For flex-algo it is advertised using ASLA 
advertisement. I don't see a problem.


> 
> As an operator, as of today, I have not the possibility to advertise 
> min/max delay in our network as requested in the draft just because it 
> is not available in all commercial routers. So, referring to a future 
> RFC which take months/years before it becomes 
> available/deploy/operational, leave flex algo with delay not ready 
> before a while.

sorry, but we are defining a new extension. This require new encodings 
for flex-algo, so anyone implementing flex-algo needs to implement this 
new encodings.

> 
> So, to speed up the deployment, I would prefer a reference to a delay 
> value that could be advertise by means of RFC7471, RFC8570 and/or TE-App 
> draft. It is then up to the operator to ensure the coherency of what it 
> is announced in its network by the different routers.

I know you don't like the app specific link advertisement, but I'm 
afraid what you ask for is absolutely wrong.

We defined the ASLA encoding to address a real problems for advertising 
the link attributes. We allow the link attributes to be advertised in 
both legacy and ASLA advertisement for legacy application (RSVP-TE, 
SRTE) to address the backward compatibility. Flex-algo is a new 
application, there is absolutely no need to use the legacy 
advertisement. Doing so would just extend the problem to the flex-algo 
application.

regards,
Peter

> 
> Regards
> 
> Olivier
> 
> Le 18/08/2020 à 19:02, [e-mail] a écrit :
>>
>> 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] 
>>> <mailto:[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] 
>>> <mailto:[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] <mailto:[e-mail]>>
>>>     *On Behalf Of *[e-mail] <mailto:[e-mail]>
>>>     *Sent:* Tuesday, August 18, 2020 7:44 AM
>>>     *To:* Peter Psenak (ppsenak) <[e-mail]
>>>     <mailto:[e-mail]>>
>>>     *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail]
>>>     <mailto:[e-mail]>; Christian Hopps <[e-mail]
>>>     <mailto:[e-mail]>>; Acee Lindem (acee) <[e-mail]
>>>     <mailto:[e-mail]>>; [e-mail]
>>>     <mailto:[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] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/lsr
>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
> -- 
> Orange logo <http://www.orange.com>
> 
> Olivier Dugeon
> Orange Expert, Future Networks
> Open Source Referent
> Orange/IMT/OLN/WTC/IEE/iTeQ
> 
> fixe : [phone]
> mobile : [phone]
> [e-mail] <mailto:[e-mail]>
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>