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

[Peter Psenak <[e-mail]>]

Olivier,

On 20/08/2020 16:25, [e-mail] wrote:
> Peter,
> 
> Le 20/08/2020 à 14:12, Peter Psenak a écrit :
>> Hi Olivier,
>>
>> On 20/08/2020 13:58, [e-mail] wrote:
>>> Hi Peter,
>>>
>>> Thank for the new version.
>>>
>>> Le 19/08/2020 à 14:00, Peter Psenak a écrit :
>>>> Olivier, 
>>> [ ... ]
>>>>> 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.
>>>
>>> Regarding the new version you provided, new section 5.1 (for IS-IS) 
>>> and section 5.2 (for OSPF) mention respectively RFC 8570 and RFC 7471 
>>> for the definition of Min delay and TE metric which is fine for me. 
>>> But, they also made reference to draft isis-te-app, respectively 
>>> ospf-te-link-attr-reuse to encode these value. 
>>
>> that's what people were asking for. And it is right because we are 
>> mandating the usage of ALSA encoding for any flex-algo related link 
>> attributes.
>>
>>> Here, it is confusing. 
>>
>> I don't see how much more clear we can make it.
>>
>>> Indeed, RFC 8570 and RFC 7471 also define the way to encode TE metric 
>>> and Min delay.
>>
>> you have to distinguish between two things:
>>
>> a)  where Min delay and TE metric were defined - RFC 8570 and RFC 7471
>> b)  how we encode it for flex-algo - isis-te-app,
>> ospf-te-link-attr-reuse
>>
>>>
>>> What I'm suggesting, is a clear reference to the RFC for TE metric 
>>> and Min delay definition as well as the encoding (especially for the 
>>> delay) while leaving open the door to how the router acquire these 
>>> values: legacy a.k.a. RFC 8570 & 7471 or new draft a.k.a 
>>> draft-isis-te-app & draft-ospf-link-attr-reuse.
>>
>> no. This will not be done. We only allow ASLA advertisement for these 
>> metrics and other link attributes that are used for flex-algo. It is 
>> done for a reason and I have already explained that.
>>
> OK. Reading section 11 which clarify how metrics are convey, let me 
> suggest to make a reference to section 11 in section 5.1 and 5.2 instead 
> of reference to drafts.

what is the problem with using the reference to isis-te-app,
ospf-te-link-attr-reuse in 5.1 and 5.2?


>>>
>>> In fact, in section 17.1.2, you mention only reference to RFC 8570 & 
>>> RFC7471 for the IANA definition which is fine for me. 
>>
>> because in registry, we are defining a metric type, not how we are 
>> going to advertise it for the link.
>>
>>
> OK.
>>
>>> I would suggest the same wording for section 5.1. and 5.2 leaving 
>>> operator free about how it collect the values from the neighbour 
>>> routers: legacy or new method.
>>
>> please stop trying to make use of legacy RSVP-TE link advertisements 
>> for flex-algo - it will not be allowed.
> 
> This raise to me a simple question: Is it possible to use 2 different 
> Flex Algo with delay metric, one for App A and another one for App B ? 

sure

> if yes, how can we link metrics advertise in ALSA A from metrics 
> advertise in ALSA B ? The draft mention only one bit for Flex-Algo.

there is only single ASLA flex-algo delay metric advertisement per link, 
similar to only single RSVP-TE delay metric per link.


Advertisement is done per application type, flex-algo being one of them, 
not per each instance of the application (e.g. flex-algo number).


> 
> Regards,
> 
> Olivier
> 
> PS. I note a duplicate paragraph in section 12: "When computing the path 
> for a given Flex-Algorithm, the metric-type that is part of the 
> Flex-Algorithm definition (Section 5) MUST be used."

I don't see it. I see one talking about metric, the other one about the 
calculation type.

thanks,
Peter

> 
>>
>> thanks,
>> Peter
>>
>>>
>>> Regards
>>>
>>> Olivier
>>>
>>> PS. We have a pre-alpha implementation of flex algo using the legacy 
>>> metrics and I know that recent IOS-XR provided similar implementation 
>>> of flex algo based on legacy metrics.
>>>
>>>>
>>>> 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.
>>>>>
>>>>
>>>>
>>> -- 
>>> 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.
>>>
>>
>>
> -- 
> 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.
>