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

[Peter Psenak <[e-mail]>]

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.

> 
> 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.



> 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.

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.
>