Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Bruno,

On 30/06/2020 18:08, bruno.decraene@orange.com wrote:
> Hi Peter,
> 
> Thanks for your reply.
> 
>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>
>> Hi Bruno,
>>
>> please see inline:
>>
>> On 30/06/2020 16:53, bruno.decraene@orange.com wrote:
>>> Hi all,
>>>
>>> I can live with the current text, but I'm just raising the point for discussion
>> (better safe than sorry).
>>>
>>> "16.1.1.  IGP Algorithm Types Registry
>>>
>>>      This document makes the following registrations in the "IGP Algorithm
>> Types" registry:
>>>
>>>         Type: 128-255.
>>>
>>>         Description: Flexible Algorithms.
>>> "
>>> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1
>>>
>>> This is essentially burning half of the registry for flex-algo. Indeed, any
>> network operator could use any value, e.g. 222, hence the IETF could never
>> define a different usage for this value without creating interop issues for the
>> network operator.
>>
>> what is the real problem? Is the space 2-127 that is free not sufficient
>> for other standardized algorithms that may come?
>>
>>>
>>> We could discuss whether we really need 127 values for this. (i.e. a
>> network operator requiring 127 flex algo, typically multiplying its IGP FIB
>> entries by 127...).
>>
>> above is not necessarily true and more importantly completely irrelevant
>> to the number of algos we reserve for FA.
>>
>>
>>> We could also discuss whether this range could be change to the IANA well-
>> known "Private Use" [1]. This would allow for alternative private usages in
>> the future (e.g. Flexible Alorithms v2).
>>> [1] https://tools.ietf.org/html/rfc8126#section-4.1
>>>
>>> It seems to me that the latter would equally work for flex algo, but would
>> provide more flexibility :-) for the future.
>>
>> I don't think so. We need an allocated range of algos for FA for
>> compatibility.
> 
> The allocated range of algos for FA would be the same. Just not dedicated to FA.

this would not work. If I have a mix of routers, one set using value 222 
for flex-algo and another set for something else, how are they going to 
interoperate?

We need a standardized range, using Private Use is not an option here.

thanks,
Peter

> 
> --Bruno
>   
>>
>> thanks,
>> Peter
>>>
>>> Regards,
>>> --Bruno
>>>
>>>
>> __________________________________________________________
>> __________________________________________________________
>> _____
>>>
>>> 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.
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>>
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> 
> 