Speaking as WG chair:
I'm delighted to see discussion on a draft that isn't in WG last call.
Speaking as WG member:
Maybe I'm missing something but do we really think we’re going to run out of
non-flexible algorithms with 128? I just don't see it happening in my lifetime.
Thanks,
Acee
On 6/30/20, 12:27 PM, "Lsr on behalf of Peter Psenak" <[email protected] on
behalf of [email protected]> wrote:
Hi Bruno,
On 30/06/2020 18:08, [email protected] wrote:
> Hi Peter,
>
> Thanks for your reply.
>
>> From: Peter Psenak [mailto:[email protected]]
>>
>> Hi Bruno,
>>
>> please see inline:
>>
>> On 30/06/2020 16:53, [email protected] 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
>>> [email protected]
>>> 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.
>
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
