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" <lsr-boun...@ietf.org on behalf of ppsenak=40cisco....@dmarc.ietf.org> wrote: Hi Bruno, On 30/06/2020 18:08, bruno.decra...@orange.com wrote: > Hi Peter, > > Thanks for your reply. > >> From: Peter Psenak [mailto:ppse...@cisco.com] >> >> Hi Bruno, >> >> please see inline: >> >> On 30/06/2020 16:53, bruno.decra...@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. > > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr