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

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-bounces@ietf.org on behalf of ppsenak=40cisco.com@dmarc.ietf.org> wrote:

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

    _______________________________________________
    Lsr mailing list
    Lsr@ietf.org
    https://www.ietf.org/mailman/listinfo/lsr