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

From: Shraddha Hegde <[email-masked]>
Date: Wed, 2 Sep 2020 04:45:34 +0000

Peter,

It is worthwhile to note the history of the flex-algo draft and the
te-app draft and how many  backward incompatible changes have been 
introduced in the course of the flex-algo draft.

The original drafts of flex-algo did not mention the te-app draft 
and was completely based on legacy advertisements.
Two years ago, after the working group adopted the original drafts without the ASLA TLV,
the text was changed to require the ASLA TLV.  

ASLA TLV had the L-Bit and it was always valid to advertise link attributes
for flex-algo with L-bit set which means the link attributes could still be sent
in legacy TLVs.
In a conversation last year, you had agreed that advertising link attributes with 
L-bit set is valid for Flex-algo.

Towards the end of 2019, draft-ietf-isis-te-app-08 was posted. This version said
that only RSVP, SR-TE and LFA can use legacy advertisements. 
This change in a different draft made using flex-algo with 
legacy advertisements invalid.

So implementations from 2 yrs ago may not inter-operate with 
the ones implemented a year ago or the ones implemented based on published RFC.
Implementations from a year ago may not interoperate with published RFC.

I don’t agree with this series of backward incompatible changes that have been
made in this document.  However, if the working group decides to go ahead and request publication
of the current version,  which has broken backward compatibility twice with previous versions,
 I want the history to be accurately  recorded. This allows network
operators to better understand the history and ensure interoperability across vendors before deploying.

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Thursday, August 27, 2020 3:34 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]

Hi Shraddha,

draft-ietf-lsr-flex-algo-00 was published May 15, 2018 (over two years ago).

It clearly stated:

https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00*section-9__;Iw!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_03Sd1J7b$

"To advertise a link affinity in a form of the AG or EAG that is used
  during Flex-Algorithm calculation, an Application Specific Link
  Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
  of Extended Link TLV as described in [I-D.ietf-ospf-te-link-attr-reuse]
  MUST be used. The advertisement MUST indicate that it is usable by the
  Flex-Algorithm application."

This is consistent with normative statements in both https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-isis-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_09_HTtuT$  and https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_08_P1Wmy$
which REQUIRE the use of application specific advertisements by all applications other than the legacy applications (RSVP-TE, Segment Routing Policy,  Loop Free Alternate).

draft-hegdeppsenak-isis-sr-flex-algo had a lifetime of 10 months(V00 published in July 2017) and draft-ppsenak-ospf-sr-flex-algo only 3 months (V00 published in Feb 2018).

Juniper may have its own reasons why over the course of the past two years it has chosen not to modify its early implementation to be compatible with what is defined in the WG adopted draft. We do not question this choice. But it seems the most appropriate way to communicate this is for Juniper to document in its vendor specific documents that its implementation is based on a pre-WG draft and is incompatible with the IETF defined standard. IETF documents are not the correct place for such proprietary information.

It is obvious that the implementation that is not following the final specification will not interoperate with other implementations that do so. There is no need to mention that in the RFC.

thanks,
Peter and Les

On 25/08/2020 17:27, Shraddha Hegde wrote:
> Hi All,
>
> draft-lsr-flex-algo-00 was created by combining
>
> draft-hegdeppsenak-isis-sr-flex-algo-02 and 
> draft-ppsenak-ospf-sr-flex-algo-00.
>
> When draft-lsr-flex-algo-00 was published as a WG document, it 
> included
>
> a requirement for using te-app encodings that did not exist in either
>
> draft-hegdeppsenak-isis-sr-flex-algo-02 and 
> draft-ppsenak-ospf-sr-flex-algo-00.
>
> Juniper's currently released implementation of flex-algo uses legacy 
> encodings,
>
> as opposed to te-app encodings.  I would like the following text added 
> to
>
> draft-lsr-flex-algo in order to record the history of these changes 
> and to make
>
> operators aware of possible inter-op problems that may arise due to 
> the
>
> non-backward compatible nature of mandating ASLA encodings.
>
> =====
>
> 11.  Advertisement of Link Attributes for Flex-Algorithm
>
> " Earlier versions of this draft did not mandate the use of ASLA TLVs 
> for encoding the
>
> link attributes. There may be implementations that depend on legacy 
> encodings as defined in
>
> RFC 5305, RFC 7810 , RC 3630 and RFC 7471. Implementations that look 
> at only ASLA encodings
>
> for flex-algo based on this version of the document will not 
> interoperate with versions
>
> that use legacy advertisements. "
>
> ========
>
> Rgds
>
> Shraddha
>
> Juniper Business Use Only
>
> *From:[email-masked] <[email-masked]>
> *Sent:* Thursday, August 20, 2020 7:56 PM
> *To:* Peter Psenak <[email-masked]>; [email-masked]; Robert Raszuk 
> <[email-masked]>
> *Cc:* Christian Hopps <[email-masked]>; 
> [email-masked]; Les Ginsberg (ginsberg) 
> <ginsberg=[email-masked]>; [email-masked]; [email-masked]; 
> Acee Lindem (acee) <[email-masked]>
> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
> *[External Email. Be cautious of content]*
>
> Peter,
>
> Le 20/08/2020 à 14:12, Peter Psenak a écrit :
>
>     Hi Olivier,
>
>     On 20/08/2020 13:58, [email-masked]
>     <mailto:[email-masked]> 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.
>
> OK. Reading section 11 which clarify how metrics are convey, let me 
> suggest to make a reference to section 11 in section 5.1 and 5.2 
> instead of reference to drafts.
>
>
>         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.
>
> OK.
>
>         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.
>
> This raise to me a simple question: Is it possible to use 2 different 
> Flex Algo with delay metric, one for App A and another one for App B ?
> if yes, how can we link metrics advertise in ALSA A from metrics 
> advertise in ALSA B ? The draft mention only one bit for Flex-Algo.
>
> Regards,
>
> Olivier
>
> PS. I note a duplicate paragraph in section 12: "When computing the 
> path for a given Flex-Algorithm, the metric-type that is part of the 
> Flex-Algorithm definition (Section 5) MUST be used."
>
>
>     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, [email-masked]
>                 <mailto:[email-masked]> 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
>                         <[email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>> 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=[email-masked]
>                         <mailto:ginsberg=[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>> 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 <[email-masked]
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>>
>                              *On Behalf Of [email-masked]
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]> <mailto:[email-masked]>
>                              *Sent:* Tuesday, August 18, 2020 7:44 AM
>                              *To:* Peter Psenak (ppsenak)
>                         <[email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>>
>                              *Cc:* [email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]> <mailto:[email-masked]>;
>                         [email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>; Christian Hopps
>                         <[email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>>; Acee Lindem (acee)
>                         <[email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>>;
>                         [email-masked]
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                              *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://urldefense.com/v3/__https://tools.ietf.org/html/rfc8570__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_03pN2Sfl$ >
>                         
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__;!!NE
> t6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ir2Q
> Dxsg$>
>
>
>                              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
>                         [email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]> <mailto:[email-masked]>
>                         https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_07ffIqQQ$
>                         
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgy
> h1ivswJmIk$>
>
>
>
>
>                     _______________________________________________
>                     Lsr mailing list
>                     [email-masked] <mailto:[email-masked]>
>                     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_07ffIqQQ$
>                     
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_
> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgy
> h1ivswJmIk$>
>
>
>                 --
>                 Orange logo <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ >
>                 
> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuL
> WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
>
>
>                 Olivier Dugeon
>                 Orange Expert, Future Networks
>                 Open Source Referent
>                 Orange/IMT/OLN/WTC/IEE/iTeQ
>
>                 fixe : +33 2 96 07 28 80
>                 mobile : +33 6 82 90 37 85
>                 [email-masked]
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked]>
>
>                 
> ______________________________________________________________________
> ___________________________________________________
>
>
>                 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 <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ >
>         
> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuL
> WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
>
>
>         Olivier Dugeon
>         Orange Expert, Future Networks
>         Open Source Referent
>         Orange/IMT/OLN/WTC/IEE/iTeQ
>
>         fixe : +33 2 96 07 28 80
>         mobile : +33 6 82 90 37 85
>         [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>
>
>         
> ______________________________________________________________________
> ___________________________________________________
>
>
>         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
> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuL
> WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
>
> *Olivier Dugeon
> *Orange Expert, Future Networks
> Open Source Referent
> Orange/IMT/OLN/WTC/IEE/iTeQ
>
> fixe : +33 2 96 07 28 80
> mobile : +33 6 82 90 37 85
> [email-masked] <mailto:[email-masked]>
>
> ______________________________________________________________________
> ___________________________________________________
>
> 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.
>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 2 Sep 2020 11:12:37 +0200

Hi Shraddha,

please see inline:

> the text was changed to require the ASLA TLV.

draft-ietf-lsr-flex-algo-00, which was the initial version of the WG 
document already mandated the ASLA usage. I don't believe we have to go 
back to the individual drafts that predated the WG version.

> L-bit set is valid for Flex-algo.

what we say in flex-algo draft in section 11 is:

    "Link attribute advertisements that are to be used during Flex-
    Algorithm calculation MUST use the Application-Specific Link
    Attribute (ASLA) advertisements defined in [I-D.ietf-isis-te-app] or
    [I-D.ietf-ospf-te-link-attr-reuse]."

ietf-isis-te-app clearly allows the app specific value of the attribute 
to be advertised in legacy TLV and be pointed to by ASLA with L-bit. 
This is perfectly valid for Flex-algo with ISIS.

Please note that etf-ospf-te-link-attr-reuse does not have the concept 
of L-bit.

> legacy advertisements invalid.

no, not really. From the version 00, the WG version of the flex-algo 
draft mandated the usage of ASLA. And from day one of the 
draft-ietf-isis-te-app draft we mandated the usage of the ALSA for new 
applications, including the flex-algo. And usage of ASLA with L-bit 
together with the legacy advertisement of the link attribute is valid 
for any new application.

> the ones implemented a year ago or the ones implemented based on published RFC.

let's be more precise here. The implementation of the pre-WG version may 
not inter-operate with WG version. I don't see a problem there really.

> Implementations from a year ago may not interoperate with published RFC.

no, that is not true.

> of the current version,  which has broken backward compatibility twice with previous versions,

above statement is not correct. The WG document has been consistent in 
terms of ASLA usage from day one.

thanks,
Peter

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 3 Sep 2020 03:39:01 +0000

Peter,

In order to make the document clearer on this point, I would like the text below to be added
to section 11 to make it explicit that setting the L-bit is valid for flex-algo for ISIS.

=============
Section 11.

“The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 of 
[draft-ietf-isis-te-app]. When the L-bit is set, applications MUST use
legacy advertisements for that link. Flex algorithm application MUST support
sending and receiving link attributes with ASLA TLV having L-bit set.

Note that earlier versions of this document did not mandate use of ASLA TLVs
and hence may not inter-operate with early implementations that use legacy advertisements."
============

Rgds
Shraddha

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Wednesday, September 2, 2020 2:43 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Shraddha,

please see inline:

On 02/09/2020 06:45, Shraddha Hegde wrote:
> The original drafts of flex-algo did not mention the te-app draft and 
> was completely based on legacy advertisements.
> Two years ago, after the working group adopted the original drafts 
> without the ASLA TLV, the text was changed to require the ASLA TLV.

draft-ietf-lsr-flex-algo-00, which was the initial version of the WG document already mandated the ASLA usage. I don't believe we have to go back to the individual drafts that predated the WG version.

>
>
> ASLA TLV had the L-Bit and it was always valid to advertise link 
> attributes for flex-algo with L-bit set which means the link 
> attributes could still be sent in legacy TLVs.
> In a conversation last year, you had agreed that advertising link 
> attributes with L-bit set is valid for Flex-algo.

ietf-isis-te-app clearly allows the app specific value of the attribute to be advertised in legacy TLV and be pointed to by ASLA with L-bit.
This is perfectly valid for Flex-algo with ISIS.

Please note that etf-ospf-te-link-attr-reuse does not have the concept of L-bit.

>
> Towards the end of 2019, draft-ietf-isis-te-app-08 was posted. This 
> version said that only RSVP, SR-TE and LFA can use legacy advertisements.
> This change in a different draft made using flex-algo with legacy 
> advertisements invalid.

no, not really. From the version 00, the WG version of the flex-algo draft mandated the usage of ASLA. And from day one of the draft-ietf-isis-te-app draft we mandated the usage of the ALSA for new applications, including the flex-algo. And usage of ASLA with L-bit together with the legacy advertisement of the link attribute is valid for any new application.

>
> So implementations from 2 yrs ago may not inter-operate with the ones 
> implemented a year ago or the ones implemented based on published RFC.

let's be more precise here. The implementation of the pre-WG version may not inter-operate with WG version. I don't see a problem there really.

no, that is not true.

>
> I don’t agree with this series of backward incompatible changes that 
> have been made in this document.  However, if the working group 
> decides to go ahead and request publication of the current version,  
> which has broken backward compatibility twice with previous versions,

above statement is not correct. The WG document has been consistent in terms of ASLA usage from day one.

thanks,
Peter

> To: Shraddha Hegde <[email-masked]>; [email-masked]; 
> [email-masked]; Robert Raszuk <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; 
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr
> -flex-algo-00*section-9__;Iw!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnY
> KFPl7DWC_fZCGDapvakBVKlZPth_03Sd1J7b$
>
> This is consistent with normative statements in both 
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-isi
> s-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGD
> apvakBVKlZPth_09_HTtuT$  and 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> f-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jn
> YKFPl7DWC_fZCGDapvakBVKlZPth_08_P1Wmy$
>> as opposed to te-app encodings.  I would like the following text 
>> added to
>>
>> *To:* Peter Psenak <[email-masked]>; [email-masked]; Robert 
>> Raszuk <[email-masked]>
>> <ginsberg=[email-masked]>; [email-masked]; 
>> [email-masked]; Acee Lindem (acee) <[email-masked]>
>> <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8570__;!!
>> NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0
>> 3pN2Sfl$ >
>>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZ
>> Pth_07ffIqQQ$
>>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZ
>> Pth_07ffIqQQ$
>>
>> <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk!U6
>> 9buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ >
>>
>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKu
>> L WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
>>
>>
>>                  Olivier Dugeon
>> _____________________________________________________________________
>> _ ___________________________________________________
>>
>>
>> <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk!U6
>> 9buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ >
>>
>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKu
>> L WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
>>
>>
>>          Olivier Dugeon
>> _____________________________________________________________________
>> _ ___________________________________________________
>>
>>
>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKu
>> L WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
>>
>> *Olivier Dugeon
>> _____________________________________________________________________
>> _ ___________________________________________________
>>
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous 
>> avez recu ce message par erreur, veuillez le signaler
>>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 3 Sep 2020 09:54:45 +0200

Hi Shraddha,

> to section 11 to make it explicit that setting the L-bit is valid for flex-algo for ISIS.

I can add the above, although, it's clear from the 
draft-ietf-isis-te-app that L-bit with legacy advertisement MAY be used 
for any app.

> and hence may not inter-operate with early implementations that use legacy advertisements."

it is not true that "earlier versions of this document" did not mandate 
ASLA.

https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only 
supported the include/exclude Admin Groups, clearly stated:

9.  Advertisement of Link Attributes for Flex-Algorithm

    Various link include or exclude rules can be part of the Flex-
    Algorithm definition.  These rules use Admin Groups (AG) as defined
    in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
    as defined in [RFC7308].

    To advertise a link affinity in a form of the AG or EAG that is used
    during Flex-Algorithm calculation, an Application Specific Link
    Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
    of Extended Link TLV as described in
    [I-D.ietf-ospf-te-link-attr-reuse] MUST be used.  The advertisement
    MUST indicate that it is usable by the Flex-Algorithm application.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 3 Sep 2020 11:19:17 +0200

Hi Rudy,

On 03/09/2020 11:01, Selderslaghs, Rudy (Nokia - BE/Antwerp) wrote:
> Hi Peter,
> 
> My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit set to 1, cannot be used for Flex-Algo.

no, that is not correct.

> This can only be used for RSVP-TE, SR-Policy and LFA as specified in chapter 6.1.

no.

> 
>>From chapter 6.1 Use of Legacy advertisements:
>     ...
>     New applications that future documents define to make use of the
>     advertisements defined in this document MUST NOT make use of legacy
>     advertisements.  This simplifies deployment of new applications by
>     eliminating the need to support multiple ways to advertise attributes
>     for the new applications.

ASLA with L-bit pointing to legacy TLV is NOT considered legacy 
advertisement. It is valid ASLA advertisement.

> 
> Chapter 4.2. states that ASLA TLV with L-bit set means "using legacy advertisements":

no. It says that if L-flag is set, all apps mentioned in the bitmask 
MUST use the legacy advertisement to derive the value of the attribute. 
It does NOT say that ASLA TLV with L-bit set means "using legacy 
advertisements". It does not.

thanks,
Peter

>     ...
>     When the L-flag is set in the Application Identifier Bit Mask, all of
>     the applications specified in the bit mask MUST use the legacy
>     advertisements for the corresponding link found in TLVs 22, 23, 25,
>     141, 222, and 223 or TLV 138 or TLV 139 as appropriate.
> 
> Regards,
> Rudy
> 
> From: Lsr <[email-masked]> On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 9:55 AM
>> In order to make the document clearer on this point, I would like the
>> text below to be added to section 11 to make it explicit that setting the L-bit is valid for flex-algo for ISIS.
>>
>> =============
>> Section 11.
>>
>> “The ASLA TLV in ISIS supports the L-Bit as described in section 4.2
>> of [draft-ietf-isis-te-app]. When the L-bit is set, applications MUST
>> use legacy advertisements for that link. Flex algorithm application
>> MUST support sending and receiving link attributes with ASLA TLV having L-bit set.
> 
> 
> I can add the above, although, it's clear from the draft-ietf-isis-te-app that L-bit with legacy advertisement MAY be used for any app.
> 
>>
>> Note that earlier versions of this document did not mandate use of
>> ASLA TLVs and hence may not inter-operate with early implementations that use legacy advertisements."
> 
> it is not true that "earlier versions of this document" did not mandate ASLA.
> 
> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only supported the include/exclude Admin Groups, clearly stated:
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
> 
>

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 3 Sep 2020 09:53:15 +0000

Hi Peter, All,

Let me chime in.

When the L-bit is set in an ASLA TLV, then for all applications marked, indeed only legacy attributes can be used.
Of course an ASLA TLV with the L-bit set is a valid ASLA advertisement. That is not the point.

>     141, 222, and 223 or TLV 138 or TLV 139 as appropriate.

This clearly says that when the L-bit is set, the LEGACY ADVERTISEMENTS have to be used.
However chapter 6.1 is saying that legacy advertisements can only be used for RSVP-TE, SR-Policy and LFA.

So in my opinion the draft is saying the opposite and legacy advertisements MUST NOT be used for flex-algo.
Hence, I suggest that we should make it explicit clear that L-bit set for flex-algo is MUST NOT be allowed.

G/

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 11:19
To: Selderslaghs, Rudy (Nokia - BE/Antwerp) <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Rudy,

no, that is not correct.

no.

>     for the new applications.

ASLA with L-bit pointing to legacy TLV is NOT considered legacy advertisement. It is valid ASLA advertisement.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Thu, 3 Sep 2020 12:02:18 +0200

Gunter,

> However chapter 6.1 is saying that legacy advertisements can only be used for RSVP-TE, SR-Policy and LFA.

where? Please point me to the text.

If you are referring to the text:

"New applications that future documents define to make use of the
advertisements defined in this document MUST NOT make use of legacy
advertisements."

then it is NOT preventing L-bit with legacy advertisement for new apps, 
because ASLA with L-bit in combination with legacy advertisement is not 
considered as legacy advertisement, but as a valid ASLA advertisement.

> So in my opinion the draft is saying the opposite and legacy advertisements MUST NOT be used for flex-algo.

again, L-bit with legacy advertisement is NOT a legacy advertisement. It 
is ASLA advertisement.

> Hence, I suggest that we should make it explicit clear that L-bit set for flex-algo is MUST NOT be allowed.

L-bit is allowed with any app, including the flex-algo.

thanks,
Peter

---

From: "Selderslaghs, Rudy (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 3 Sep 2020 09:01:22 +0000

Hi Peter,

Regards,
Rudy

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 9:55 AM
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Shraddha,

thanks,
Peter

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 3 Sep 2020 12:49:45 +0000

I think that some misunderstanding comes from a different definition of " LEGACY ADVERTISEMENTS" between section 4.2 and 6.1

In section 4.2:
LEGACY ADVERTISEMENTS means that *ASLA is used* and point to the attributes found in legacy TLVs for example EAG, Delay and TE-metric

In section 6.1:
LEGACY ADVERTISEMENTS means that *ASLA is NOT used* and allows RSVP-TE, SR-Policy and LFA to interoperate between systems that do not, and do, support ASLA

Taking this understanding to flex-algo:
* Interop: traditionally we use the L-bit=SET for application interoperability when not all nodes understand valid ASLA encoding. 
* Interop: by design of flex-algorithm technology, we mandate ASLA encoding. No interop issues should exist with nodes not understanding ASLA encodings.
* Why would a flex-algo node, ever, advertise legacy TLVs for flex-algo attributes? There seems no use-case and no logic for such. 
* OSPF has no existing L-bit

For flex-algo simplicity, we could agree that legacy attribute advertisements MUST NOT be used and agree that flex-algo ASLA L-bit MUST be UNSET 
(This is unrelated that flex-algo ASLA with L-bit SET is semantically a valid ASLA. This also simplifies and align ISIS and OSPF routing protocol behavior. It reduce interop issues footprint with systems not supporting ASLA.)

G/

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Thursday, September 3, 2020 12:02
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; Selderslaghs, Rudy (Nokia - BE/Antwerp) <[email-masked]>; Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Gunter,

"New applications that future documents define to make use of the advertisements defined in this document MUST NOT make use of legacy advertisements."

then it is NOT preventing L-bit with legacy advertisement for new apps, because ASLA with L-bit in combination with legacy advertisement is not considered as legacy advertisement, but as a valid ASLA advertisement.

> So in my opinion the draft is saying the opposite and legacy advertisements MUST NOT be used for flex-algo.

again, L-bit with legacy advertisement is NOT a legacy advertisement. It is ASLA advertisement.

thanks,
Peter

> To: Selderslaghs, Rudy (Nokia - BE/Antwerp) 
> <[email-masked]>; Peter Psenak 
> <ppsenak=[email-masked]>; Shraddha Hegde 
> <[email-masked]>; [email-masked]; [email-masked]; 
> Robert Raszuk <[email-masked]>
>>> In order to make the document clearer on this point, I would like 
>>> the text below to be added to section 11 to make it explicit that setting the L-bit is valid for flex-algo for ISIS.
>>>
>>> =============
>>> Section 11.
>>>
>>> of [draft-ietf-isis-te-app]. When the L-bit is set, applications 
>>> MUST use legacy advertisements for that link. Flex algorithm 
>>> application MUST support sending and receiving link attributes with ASLA TLV having L-bit set.
>>
>>
>>> To: Shraddha Hegde <[email-masked]>; 
>>> [email-masked]; [email-masked]; Robert Raszuk 
>>> <[email-masked]>
>>>> So implementations from 2 yrs ago may not inter-operate with the 
>>>> ones implemented a year ago or the ones implemented based on published RFC.
>>>
>>>> I don’t agree with this series of backward incompatible changes 
>>>> that have been made in this document.  However, if the working 
>>>> group decides to go ahead and request publication of the current 
>>>> version, which has broken backward compatibility twice with 
>>>> previous versions,
>>>
>>>>      I want the history to be accurately  recorded. This allows 
>>>> network operators to better understand the history and ensure interoperability across vendors before deploying.
>>>>
>>>>
>>>> Rgds
>>>> Shraddha
>>>>
>>>>
>>>> To: Shraddha Hegde <[email-masked]>; 
>>>> [email-masked]; [email-masked]; Robert Raszuk 
>>>> <[email-masked]>
>>>> -flex-algo-00*section-9__;Iw!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-
>>>> jnY KFPl7DWC_fZCGDapvakBVKlZPth_03Sd1J7b$
>>>>
>>>> f-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2
>>>> -jn YKFPl7DWC_fZCGDapvakBVKlZPth_08_P1Wmy$
>>>>> Juniper's currently released implementation of flex-algo uses 
>>>>> legacy encodings,
>>>>>
>>>>> draft-lsr-flex-algo in order to record the history of these 
>>>>> changes and to make
>>>>>
>>>>> operators aware of possible inter-op problems that may arise due 
>>>>> to the
>>>>>
>>>>> " Earlier versions of this draft did not mandate the use of ASLA 
>>>>> TLVs for encoding the
>>>>>
>>>>> link attributes. There may be implementations that depend on 
>>>>> legacy encodings as defined in
>>>>>
>>>>> RFC 5305, RFC 7810 , RC 3630 and RFC 7471. Implementations that 
>>>>> look at only ASLA encodings
>>>>>
>>>>> OK. Reading section 11 which clarify how metrics are convey, let 
>>>>> me suggest to make a reference to section 11 in section 5.1 and 
>>>>> 5.2 instead of reference to drafts.
>>>>>
>>>>>
>>>>> This raise to me a simple question: Is it possible to use 2 
>>>>> different Flex Algo with delay metric, one for App A and another one for App B ?
>>>>> PS. I note a duplicate paragraph in section 12: "When computing 
>>>>> the path for a given Flex-Algorithm, the metric-type that is part 
>>>>> of the Flex-Algorithm definition (Section 5) MUST be used."
>>>>>
>>>>>
>>>>>         thanks,
>>>>>         Peter
>>>>>
>>>>>
>>>>>             Regards
>>>>>
>>>>>             Olivier
>>>>>
>>>>> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__;
>>>>> !!N
>>>>> E
>>>>> t6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1
>>>>> ir2
>>>>> Q
>>>>> Dxsg$>
>>>>>
>>>>>
>>>>>                                  This does not help.
>>>>>
>>>>>
>>>>>
>>>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/
>>>>> lsr
>>>>> _
>>>>> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAu
>>>>> fXg
>>>>> y
>>>>> h1ivswJmIk$>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/
>>>>> lsr
>>>>> _
>>>>> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAu
>>>>> fXg
>>>>> y
>>>>> h1ivswJmIk$>
>>>>>
>>>>>
>>>>>                     --
>>>>>                     Orange logo
>>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!
>>>>> WKu L 
>>>>> __________________________________________________________________
>>>>> ___ _ ___________________________________________________
>>>>>
>>>>>
>>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!
>>>>> WKu L 
>>>>> __________________________________________________________________
>>>>> ___ _ ___________________________________________________
>>>>>
>>>>>
>>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!
>>>>> WKu L 
>>>>> __________________________________________________________________
>>>>> ___ _ ___________________________________________________
>>>>>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 3 Sep 2020 15:11:47 +0200

Gunter,

> * Why would a flex-algo node, ever, advertise legacy TLVs for flex-algo attributes? There seems no use-case and no logic for such.

because the draft-ietf-isis-te-app allows it.

> For flex-algo simplicity, we could agree that legacy attribute advertisements MUST NOT be used and agree that flex-algo ASLA L-bit MUST be UNSET

not really. Flex-algo draft simply refers to draft-ietf-isis-te-app, 
which allows L-bit (with legacy adv) to be used for any application.
There are vendors that have implemented flex-algo this way and we MUST 
be able to interoperate.

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 3 Sep 2020 15:18:37 +0000

Gunter -

You are very close to "the truth" with your post.

The point of the L-flag is to minimize duplicate advertisement of link attributes. In order to justify use of the L-flag all of the following needs to be true:

  *   Both a legacy application and a non-legacy application have to be in use
  *   For a given link, all of the link attribute values associated with the legacy application and with the non-legacy application have to be identical

How could this apply to Flex-algo? Only if (for example) both RSVP-TE and Flex-algo were in use and on a given link all link attribute values were shared.

Peter is absolutely correct in saying use of L-flag is allowed for non-legacy applications (such as flex-algo). But doing so in the absence of a legacy application is not at all what is intended. As the intent of L-flag is to avoid duplicate advertisements and in the absence of a legacy application there can be no duplicate advertisements there is no point in using the L-flag in such a situation.

   Les

> From: Van De Velde, Gunter (Nokia - BE/Antwerp)

> <[email-masked]>

> Sent: Thursday, September 03, 2020 5:50 AM

> To: Peter Psenak (ppsenak) <[email-masked]>; Selderslaghs, Rudy

> (Nokia - BE/Antwerp) <[email-masked]>; Shraddha Hegde

> Cc: Christian Hopps <[email-masked]>; draft-ietf-lsr-flex-

> [email-masked]; Les Ginsberg (ginsberg) <[email-masked]>;

> [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>

> Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

> I think that some misunderstanding comes from a different definition of "

> LEGACY ADVERTISEMENTS" between section 4.2 and 6.1

> LEGACY ADVERTISEMENTS means that *ASLA is used* and point to the

> attributes found in legacy TLVs for example EAG, Delay and TE-metric

> LEGACY ADVERTISEMENTS means that *ASLA is NOT used* and allows RSVP-

> TE, SR-Policy and LFA to interoperate between systems that do not, and do,

> support ASLA

> * Interop: traditionally we use the L-bit=SET for application interoperability

> when not all nodes understand valid ASLA encoding.

> * Interop: by design of flex-algorithm technology, we mandate ASLA

> encoding. No interop issues should exist with nodes not understanding ASLA

> encodings.

> * Why would a flex-algo node, ever, advertise legacy TLVs for flex-algo

> attributes? There seems no use-case and no logic for such.

> For flex-algo simplicity, we could agree that legacy attribute advertisements

> MUST NOT be used and agree that flex-algo ASLA L-bit MUST be UNSET

> (This is unrelated that flex-algo ASLA with L-bit SET is semantically a valid

> ASLA. This also simplifies and align ISIS and OSPF routing protocol behavior. It

> reduce interop issues footprint with systems not supporting ASLA.)

> From: Peter Psenak <[email-masked]<mailto:[email-masked]>>

> To: Van De Velde, Gunter (Nokia - BE/Antwerp)

> <[email-masked]<mailto:[email-masked]>>; Selderslaghs, Rudy (Nokia -

> BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde

> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> Robert Raszuk <[email-masked]<mailto:[email-masked]>>

> Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>; draft-ietf-lsr-flex-<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>;

> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>

> > When the L-bit is set in an ASLA TLV, then for all applications marked,

> indeed only legacy attributes can be used.

> > Of course an ASLA TLV with the L-bit set is a valid ASLA advertisement. That

> is not the point.

> > This clearly says that when the L-bit is set, the LEGACY ADVERTISEMENTS

> have to be used.

> > However chapter 6.1 is saying that legacy advertisements can only be used

> for RSVP-TE, SR-Policy and LFA.

> > So in my opinion the draft is saying the opposite and legacy advertisements

> MUST NOT be used for flex-algo.

> again, L-bit with legacy advertisement is NOT a legacy advertisement. It is

> ASLA advertisement.

> > Hence, I suggest that we should make it explicit clear that L-bit set for flex-

> algo is MUST NOT be allowed.

> > From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Peter Psenak

> > <[email-masked]<mailto:[email-masked]>>; Peter Psenak

> > <ppsenak=[email-masked]<mailto:ppsenak=[email-masked]>>; Shraddha Hegde

> > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> > Robert Raszuk <[email-masked]<mailto:[email-masked]>>

> > Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>;

> > [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg)

> > <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> > Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>

> >> My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit set

> to 1, cannot be used for Flex-Algo.

> >> This can only be used for RSVP-TE, SR-Policy and LFA as specified in

> chapter 6.1.

> >>      advertisements defined in this document MUST NOT make use of

> legacy

> >> Chapter 4.2. states that ASLA TLV with L-bit set means "using legacy

> advertisements":

> >> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Peter Psenak

> >> To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>;

> [email-masked]<mailto:[email-masked]>;

> >> [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>

> >> Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>;

> >> [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg)

> >> <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>; [email-masked]<mailto:[email-masked]>;

> >> [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>

> >>> the text below to be added to section 11 to make it explicit that setting

> the L-bit is valid for flex-algo for ISIS.

> >>> application MUST support sending and receiving link attributes with ASLA

> TLV having L-bit set.

> >> I can add the above, although, it's clear from the draft-ietf-isis-te-app that

> L-bit with legacy advertisement MAY be used for any app.

> >>> ASLA TLVs and hence may not inter-operate with early implementations

> that use legacy advertisements."

> >>> From: Peter Psenak <[email-masked]<mailto:[email-masked]>>

> >>> To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>;

> >>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk

> >>> <[email-masked]<mailto:[email-masked]>>

> >>> Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>;

> >>> [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg)

> >>> <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>; [email-masked]<mailto:[email-masked]>;

> >>> [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>

> >>> ietf-isis-te-app clearly allows the app specific value of the attribute to be

> advertised in legacy TLV and be pointed to by ASLA with L-bit.

> >>>> version said that only RSVP, SR-TE and LFA can use legacy

> advertisements.

> >>> no, not really. From the version 00, the WG version of the flex-algo draft

> mandated the usage of ASLA. And from day one of the draft-ietf-isis-te-app

> draft we mandated the usage of the ALSA for new applications, including the

> flex-algo. And usage of ASLA with L-bit together with the legacy

> advertisement of the link attribute is valid for any new application.

> >>>> ones implemented a year ago or the ones implemented based on

> published RFC.

> >>> let's be more precise here. The implementation of the pre-WG version

> may not inter-operate with WG version. I don't see a problem there really.

> >>>> Implementations from a year ago may not interoperate with published

> RFC.

> >>> above statement is not correct. The WG document has been consistent

> in terms of ASLA usage from day one.

> >>>> network operators to better understand the history and ensure

> interoperability across vendors before deploying.

> >>>> From: Peter Psenak <[email-masked]<mailto:[email-masked]>>

> >>>> To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>;

> >>>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Raszuk

> >>>> <[email-masked]<mailto:[email-masked]>>

> >>>> Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>;

> >>>> [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg)

> >>>> <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>; [email-masked]<mailto:[email-masked]>;

> >>>> [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>

> >>>> draft-ietf-lsr-flex-algo-00 was published May 15, 2018 (over two years

> ago).

> >>>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf->

> >>>> -flex-algo-00*section-9__;Iw!!NEt6yMaO-

> gk!U69buL_O8Dwro3_ks7FCVPZ2-

> >>>>       of Extended Link TLV as described in [I-D.ietf-ospf-te-link-attr-

> reuse]

> >>>>       MUST be used. The advertisement MUST indicate that it is usable by

> >>>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf->

> >>>> isi

> >>>> s-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-

> jnYKFPl7DWC_fZ

> >>>> CGD

> >>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft->

> >>>> iet

> >>>> f-ospf-te-link-attr-reuse/__;!!NEt6yMaO-

> gk!U69buL_O8Dwro3_ks7FCVPZ2

> >>>> which REQUIRE the use of application specific advertisements by all

> applications other than the legacy applications (RSVP-TE, Segment Routing

> Policy,  Loop Free Alternate).

> >>>> draft-hegdeppsenak-isis-sr-flex-algo had a lifetime of 10 months(V00

> published in July 2017) and draft-ppsenak-ospf-sr-flex-algo only 3 months

> (V00 published in Feb 2018).

> >>>> Juniper may have its own reasons why over the course of the past two

> years it has chosen not to modify its early implementation to be compatible

> with what is defined in the WG adopted draft. We do not question this

> choice. But it seems the most appropriate way to communicate this is for

> Juniper to document in its vendor specific documents that its

> implementation is based on a pre-WG draft and is incompatible with the IETF

> defined standard. IETF documents are not the correct place for such

> proprietary information.

> >>>> It is obvious that the implementation that is not following the final

> specification will not interoperate with other implementations that do so.

> There is no need to mention that in the RFC.

> >>>>> a requirement for using te-app encodings that did not exist in

> >>>>> either

> >>>>> *From:[email-masked] <[email-masked]<mailto:[email-masked]>>

> >>>>> *To:* Peter Psenak <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Robert

> >>>>> Raszuk <[email-masked]<mailto:[email-masked]>>

> >>>>> *Cc:* Christian Hopps <[email-masked]<mailto:[email-masked]>>;

> >>>>> [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg)

> >>>>> <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>; [email-masked]<mailto:[email-masked]>;

> >>>>> [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>

> >>>>>         On 20/08/2020 13:58, [email-masked]<mailto:[email-masked]>

> >>>>>                 advertisement. Doing so would just extend the problem to

> >>>>>         mandating the usage of ALSA encoding for any flex-algo related

> link

> >>>>>             Indeed, RFC 8570 and RFC 7471 also define the way to encode

> TE

> >>>>>         a)  where Min delay and TE metric were defined - RFC 8570 and

> RFC 7471

> >>>>>         please stop trying to make use of legacy RSVP-TE link

> advertisements

> >>>>> different Flex Algo with delay metric, one for App A and another one

> for App B ?

> >>>>>                     Le 18/08/2020 à 19:02, [email-masked]<mailto:[email-masked]>

> >>>>>                             <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

> >>>>>                                  *On Behalf Of [email-masked]<mailto:[email-masked]>

> >>>>>                             <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

> >>>>>                                  *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> >>>>>                             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> >>>>>                             <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

> >>>>>                             <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>

> >>>>>                             [email-masked]<mailto:[email-masked]>

> >>>>> NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-

> jnYKFPl7DWC_fZCGDapvakBVKlZPt

> >>>>> h_0

> >>>>> t6yMaO-

> gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1

> >>>>>                             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> >>>>>                             <mailto:[email-masked]>

> >>>>> <mailto:[email-masked]>

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>

> >>>>> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-

> jnYKFPl7DWC_fZCGDapvakBV

> >>>>> KlZ

> >>>>> _;!!NEt6yMaO-

> gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAu

> >>>>>                         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/>

> >>>>> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-

> jnYKFPl7DWC_fZCGDapvakBV

> >>>>> KlZ

> >>>>> _;!!NEt6yMaO-

> gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAu

> <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk

> >>>>> !U6

> >>>>> 9buL_O8Dwro3_ks7FCVPZ2-

> jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ >

> >>>>>                     [email-masked]<mailto:[email-masked]>

> __________________________________________________________

> ________

> >>>>> ___ _

> <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk

> >>>>> !U6

> >>>>> 9buL_O8Dwro3_ks7FCVPZ2-

> jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ >

> >>>>>             [email-masked]<mailto:[email-masked]>

> __________________________________________________________

> ________

> >>>>> ___ _

> >>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

> __________________________________________________________

> ________

> >>>>> ___ _

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

> >> [email-masked]<mailto:[email-masked]>

> > [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Mon, 7 Sep 2020 15:31:36 +0000

Hi Peter,

> From: Lsr [mailto:[email-masked]] On Behalf Of Peter Psenak
> I can add the above, 

Yes please. (It's not clear to me whether "can add" means "will add" or "could add". So better safe than sorry).

Also in §5.1:

"         1: Min Unidirectional Link Delay as defined in [RFC8570],
         section 4.2, encoded in the Application Specific Link
         Attributes Sub-TLV [I-D.ietf-isis-te-app]."

It could be read as the delay (value) needs to be encoded in the ASLA Attributes Sub-TLV, while when the L-bit is set, the delay (value) is encoded in the RFC8570 sub-TLV.
So in order to avoid interop issues, I'd appreciate if you could clarify.
May be :s/in/as per
Or :s/./or in the RFC8570 Sub-TLV when the ASLA L-Flag is set.
Or whatever change at your preference. 

Then same comment for Metric-Type 2 (TE Metric), in the next sentence.

Thank you,
Regards,
--Bruno

> although, it's clear from the
> [email-masked]; Les Ginsberg (ginsberg)
> [email-masked];
> gk!U69buL_O8Dwro3_ks7FCVPZ2-jnY
> jnYKFPl7DWC_fZCGD
> gk!U69buL_O8Dwro3_ks7FCVPZ2-jn
> jnYKFPl7DWC_fZCGDapvakBVKlZPth_0
> >>> 3pN2Sfl$ >
> >>>
> gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ir2
> >>> Q
> >>> Dxsg$>
> >>>
> >>>
> >>>                                This does not help.
> >>>
> >>>
> >>>
> jnYKFPl7DWC_fZCGDapvakBVKlZ
> >>> Pth_07ffIqQQ$
> >>>
> >>>
> gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXg
> >>> y
> >>> h1ivswJmIk$>
> >>>
> >>>
> >>>
> >>>
> jnYKFPl7DWC_fZCGDapvakBVKlZ
> >>> Pth_07ffIqQQ$
> >>>
> >>>
> gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXg
> >>> y
> >>> h1ivswJmIk$>
> >>>
> >>>
> >>>                   --
> >>>                   Orange logo
> >>>
> >>> L
> ___________
> >>> L
> ___________
> >>> L
> ___________

_________________________________________________________________________________________________________________________

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.

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 8 Sep 2020 03:43:49 +0000

Peter,

Thanks for the conclusion on adding L-bit clarification in the draft-ietf-lsr-flex-algo.

Snip to open comments.

	>https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-	>gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$ , which only supported the >	>include/exclude Admin Groups, clearly stated:

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/

https://mailarchive.ietf.org/arch/browse/lsr/?q=LSR%20Working%20Group%20Adoption%20Poll%20for%20Flex%20Algorithm%20Drafts

The above two drafts were polled for WG adoption. These two drafts did not have any reference to te-app draft.

There was no discussion in the WG about ASLA TLV during the adoption call. When the WG adopted draft was posted, that merged the ISIS and OSPF drafts and the non-backward compatible text mandating ASLA TLV was introduced. The link to this draft, you have copied in the mail above.

I think it is fair to warn the operators on the possible inter-op issues this could cause.
I would like to see the above sentence added to the draft.

Rgds
Shraddha

-----Original Message-----
From: Peter Psenak <[email-masked]> 
Sent: Thursday, September 3, 2020 1:25 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Shraddha,

https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00__;!!NEt6yMaO-gk!RUa9k_d9lRrtd0sWrxv0etOr8GgsX8OFkI2_dSn0NHSFhML69iDpCNENxE2fpgF3$ , which only supported the include/exclude Admin Groups, clearly stated:

thanks,
Peter

>> -flex-algo-00*section-9__;Iw!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jn
>> Y KFPl7DWC_fZCGDapvakBVKlZPth_03Sd1J7b$
>>
>> f-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-j
>> n YKFPl7DWC_fZCGDapvakBVKlZPth_08_P1Wmy$
>>> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__;!!
>>> N
>>> E
>>> t6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ir
>>> 2
>>> Q
>>> Dxsg$>
>>>
>>>
>>>                                This does not help.
>>>
>>>
>>>
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ls
>>> r
>>> _
>>> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufX
>>> g
>>> y
>>> h1ivswJmIk$>
>>>
>>>
>>>
>>>
>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ls
>>> r
>>> _
>>> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufX
>>> g
>>> y
>>> h1ivswJmIk$>
>>>
>>>
>>>                   --
>>>                   Orange logo
>>> <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk!U
>>> 6 9buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ >
>>>
>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WK
>>> u L WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
>>>
>>>
>>>                   Olivier Dugeon
>>> ____________________________________________________________________
>>> _ _ ___________________________________________________
>>>
>>>
>>> <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk!U
>>> 6 9buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ >
>>>
>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WK
>>> u L WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
>>>
>>>
>>>           Olivier Dugeon
>>> ____________________________________________________________________
>>> _ _ ___________________________________________________
>>>
>>>
>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WK
>>> u L WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
>>>
>>> *Olivier Dugeon
>>> ____________________________________________________________________
>>> _ _ ___________________________________________________
>>>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 8 Sep 2020 10:53:21 +0200

Hi Shraddha,

when documents get adopted by the WG when they are still subject to 
changes. Based on WG feedback and implementation experience the drafts 
evolve to the point where they are considered mature and stable. Then 
they are ready to become RFCs and be used as the standard definition to 
be followed by interoperable implementations. Earlier versions are 
simply steps on the way.

For whatever reason, you and your company have apparently chosen NOT to 
have your flex-algo implementation adhere to the draft as it has been 
defined in the latest WG document. That is your choice. But I do not 
think you have the right to ask the IETF to document this proprietary 
choice and by doing so imply that this is a supported variation endorsed 
by the IETF.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Tue, 8 Sep 2020 10:55:22 +0200

Hi Bruno,

please see inline:

> Or whatever change at your preference.

what about:

"Min Unidirectional Link Delay as defined in [RFC8570],
  section 4.2, encoded as specified in [I-D.ietf-isis-te-app]."

That covers the L-bit with delay in legacy TLV.

> Then same comment for Metric-Type 2 (TE Metric), in the next sentence.

sure.

thanks,
Peter

---

From: <[email-masked]>
Date: Tue, 8 Sep 2020 09:02:46 +0000

Hi Peter,

> From: Peter Psenak [mailto:[email-masked]]
> 
> Hi Bruno,
> 
> please see inline:
> 
> text
> >> below to be added
> >>> to section 11 to make it explicit that setting the L-bit is valid for flex-algo
> for
> >> ISIS.
> >>>
> >>> =============
> >>> Section 11.
> >>>
> > It could be read as the delay (value) needs to be encoded in the ASLA
> Attributes Sub-TLV, while when the L-bit is set, the delay (value) is encoded
> in the RFC8570 sub-TLV.

Looks good.

Thank you.

--Bruno

> of
> >> L-bit.
> ones
> may
> RFC
> >> 7471
> _____
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 8 Sep 2020 10:59:58 +0000

Flex-algo application MUST be able to encode flex-algo link attributes using valid ASLA for flex-algo.
Flex-algo application MUST be able to decode flex-algo link attributes using valid ASLA for flex-algo.

A valid IS-IS ASLA may be encoded with L-bit SET or UNSET. The setting of L-bit is a choice from the flex-algo application implementation and/or encoding capabilities.
A flex-algo node MUST NOT make assumption on the L-bit encoding capabilities of any other flex-algo, and SHOULD expect to receive valid ASLA encodings from other flex-algo nodes.

I agree with Peter to adhere flex-algo implementations as documented in latest WG document. 

G/

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Peter Psenak
Sent: Tuesday, September 8, 2020 10:53
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Hi Shraddha,

when documents get adopted by the WG when they are still subject to changes. Based on WG feedback and implementation experience the drafts evolve to the point where they are considered mature and stable. Then they are ready to become RFCs and be used as the standard definition to be followed by interoperable implementations. Earlier versions are simply steps on the way.

For whatever reason, you and your company have apparently chosen NOT to have your flex-algo implementation adhere to the draft as it has been defined in the latest WG document. That is your choice. But I do not think you have the right to ask the IETF to document this proprietary choice and by doing so imply that this is a supported variation endorsed by the IETF.

thanks,
Peter

On 08/09/2020 05:43, Shraddha Hegde wrote:
> https://mailarchive.ietf.org/arch/browse/lsr/?q=LSR%20Working%20Group%
> 20Adoption%20Poll%20for%20Flex%20Algorithm%20Drafts
> 
>>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-l
>>> s
>>> r
>>> -flex-algo-00*section-9__;Iw!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-j
>>> n Y KFPl7DWC_fZCGDapvakBVKlZPth_03Sd1J7b$
>>>
>>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-i
>>> s
>>> i
>>> s-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZC
>>> G
>>> D
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i
>>> e
>>> t
>>> f-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-
>>> j n YKFPl7DWC_fZCGDapvakBVKlZPth_08_P1Wmy$
>>>> path for a given Flex-Algorithm, the metric-type that is part of 
>>>> the Flex-Algorithm definition (Section 5) MUST be used."
>>>>
>>>>
>>>>        thanks,
>>>>        Peter
>>>>
>>>>
>>>>            Regards
>>>>
>>>>            Olivier
>>>>
>>>> NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth
>>>> _
>>>> 0
>>>> 3pN2Sfl$ >
>>>>
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>>>> s
>>>> r
>>>> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVK
>>>> l
>>>> Z
>>>> Pth_07ffIqQQ$
>>>>
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>>>> s
>>>> r
>>>> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVK
>>>> l
>>>> Z
>>>> Pth_07ffIqQQ$
>>>>
>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!W
>>>> K u L 
>>>> ___________________________________________________________________
>>>> _ _ _ ___________________________________________________
>>>>
>>>>
>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!W
>>>> K u L 
>>>> ___________________________________________________________________
>>>> _ _ _ ___________________________________________________
>>>>
>>>>
>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!W
>>>> K u L 
>>>> ___________________________________________________________________
>>>> _ _ _ ___________________________________________________
>>>>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 8 Sep 2020 09:02:00 -0400

> On Sep 7, 2020, at 11:43 PM, Shraddha Hegde <shraddha=[email-masked]> wrote:
> 
> Peter,
> 
> 

Hi Shraddha,

I believe that early code-point allocations were made in June 2018 after the publication of the -00 WG document. If behavioral changes had been made after the early allocation I think you might have a case to make about adding warnings; however, it does not appear to be the case here, unless I've missed something.

Thanks,
Chris.
[chair hat]

---

From: <[email-masked]>
Date: Fri, 11 Sep 2020 16:18:54 +0200

Hi all,

Well, re-reading again the draft, I'm finally a bit confused about this thread around the metric. If I correctly summarise, the goal of this draft is to standardised flex algo, and consequently, new opcode allocated by IANA that are convey in IS-IS and OSPF. Looking to IANA section, let me think that the major point is to be agree on code point to specify algo and for SID, reference to a particular algo.

So, IETF is standardized protocol, not architecture, nor algorithm. So, the way a router compute nexthop route for flex algo X is normally out of scope of the draft. Thus, for delay or TE flex algo, an implementer would be free to pick delay or TE metric to compute the nexthop route. What must be standardized for interoperability purpose if the code point to convey flex algo value. Indeed, the metrics value used by the router are completely orthogonal from the flex algo code point and the algorithm that compute the route. For example, a flex algo could used legacy metric or new ALSA announce by the IGP itself or a static value configured locally or through a management system.

In fact, I'm referring to PCE and PCEP protocol which more or less do the same thing i.e. compute a route based on topology and metrics. In any RFCs related to  PCE you will find a mention about how PCE must acquire the topology and a specific metric. it is up to the implementer. This is the same for the various algorithm. Only objective functions are standardized and only code point to convey metrics in PCEP Request and Response are standardized.

So, I'm a bit surprised that this draft *impose* the origin of the metric for the flex algo route computation and not be more flexible letting the implementer free to select metrics from which it would. And don't argue that it is for interoperability (the draft will not define how to convey metric used by flex algo) nor to achieve a global coherent route as each router take a local decision to compute nexthop router which absolutely doesn't guarantee that the route follow by a packet from A to Z is the shortest from a TE metric or a delay metric. Only a central path computation e.g. with a PCE could guarantee that.

Regards

Olivier

-- 
Orange logo <http://www.orange.com>

Olivier Dugeon

fixe : +33 2 96 07 28 80

---

From: Peter Psenak <[email-masked]>
Date: Fri, 11 Sep 2020 16:45:22 +0200

Olivier,

On 11/09/2020 16:18, [email-masked] wrote:
> Hi all,
> 
> Well, re-reading again the draft, I'm finally a bit confused about this 
> thread around the metric. If I correctly summarise, the goal of this 
> draft is to standardised flex algo, and consequently, new opcode 
> allocated by IANA that are convey in IS-IS and OSPF. Looking to IANA 
> section, let me think that the major point is to be agree on code point 
> to specify algo and for SID, reference to a particular algo.

Felx-algo draft does not specify algorithm, algorithm is defined by the 
user. Nor does it define a algo specific SID, that has been defined in 
the existing RFCs.

> 
> So, IETF is standardized protocol, not architecture, nor algorithm. So, 
> the way a router compute nexthop route for flex algo X is normally out 
> of scope of the draft. 

The role of IGPs is to compute paths and IGP base specifications clearly 
specify how a path is computed for default algorithm. Flex-algo draft 
specifies how Flex-algo path is computed in IGPs. This is absolutely 
critical, because if there is an inconsistency on how the path is 
computed between different nodes in the network permanent loops could be 
formed.

> Thus, for delay or TE flex algo, an implementer 
> would be free to pick delay or TE metric to compute the nexthop route. 
> What must be standardized for interoperability purpose if the code point 
> to convey flex algo value. Indeed, the metrics value used by the router 
> are completely orthogonal from the flex algo code point and the 
> algorithm that compute the route. For example, a flex algo could used 
> legacy metric or new ALSA announce by the IGP itself or a static value 
> configured locally or through a management system.
> 
> In fact, I'm referring to PCE and PCEP protocol which more or less do 
> the same thing i.e. compute a route based on topology and metrics. In 
> any RFCs related to  PCE you will find a mention about how PCE must 
> acquire the topology and a specific metric. it is up to the implementer. 
> This is the same for the various algorithm. Only objective functions are 
> standardized and only code point to convey metrics in PCEP Request and 
> Response are standardized.

there is a fundamental difference between PCE and IGPs. PCE is a 
centralized entity, which computes the path and enforces such path on 
the network. Indeed, it can compute the path the way it likes it, 
because it's only the PCE that does the computation for the path. IGPs 
are doing distributed computation and it is absolutely critical to make 
sure that all nodes compute the path the same way and use the same inputs.

> 
> So, I'm a bit surprised that this draft *impose* the origin of the 
> metric for the flex algo route computation and not be more flexible 
> letting the implementer free to select metrics from which it would. 

it is not possible to let the choice for implementation, because if 
nodes from different implementations pick different values during the 
computation, in distributed calculation this will result in loops.

> And 
> don't argue that it is for interoperability (the draft will not define 
> how to convey metric used by flex algo) nor to achieve a global coherent 
> route as each router take a local decision to compute nexthop router 
> which absolutely doesn't guarantee that the route follow by a packet 
> from A to Z is the shortest from a TE metric or a delay metric. 

I'm afraid your understanding of distributed path computation is wrong.
IGP calculation does guarantee a coherent path selection over the 
network, it is a fundamental property of the IGP computed paths. And 
Flex-algo allows you to use different metrics to compute such paths.

> Only a 
> central path computation e.g. with a PCE could guarantee that.

obviously not.

regards,
Peter

>> From: Peter Psenak<[email-masked]>  
>> To: Van De Velde, Gunter (Nokia - BE/Antwerp)<[email-masked]>; Selderslaghs, Rudy (Nokia - BE/Antwerp)<[email-masked]>; Shraddha Hegde<[email-masked]>;[email-masked];[email-masked]; Robert Raszuk<[email-masked]>
>> Cc: Christian Hopps<[email-masked]>;[email-masked]; Les Ginsberg (ginsberg)<[email-masked]>;[email-masked];[email-masked]; Acee Lindem (acee)<[email-masked]>
>>> From: Lsr<[email-masked]>  On Behalf Of Peter Psenak
>>> <[email-masked]>;[email-masked];[email-masked];
>>> Robert Raszuk<[email-masked]>
>>> Cc: Christian Hopps<[email-masked]>;
>>> <ginsberg=[email-masked]>;[email-masked];[email-masked];
>>> Acee Lindem (acee)<[email-masked]>
>>>> From: Lsr<[email-masked]>  On Behalf Of Peter Psenak
>>>> To: Shraddha Hegde<[email-masked]>;[email-masked];
>>>> [email-masked]; Robert Raszuk<[email-masked]>
>>>> Cc: Christian Hopps<[email-masked]>;
>>>> <ginsberg=[email-masked]>;[email-masked];
>>>> [email-masked]; Acee Lindem (acee)<[email-masked]>
>>>>> From: Peter Psenak<[email-masked]>
>>>>> To: Shraddha Hegde<[email-masked]>;
>>>>> [email-masked];[email-masked]; Robert Raszuk
>>>>> <[email-masked]>
>>>>> Cc: Christian Hopps<[email-masked]>;
>>>>> <ginsberg=[email-masked]>;[email-masked];
>>>>> [email-masked]; Acee Lindem (acee)<[email-masked]>
>>>>>> From: Peter Psenak<[email-masked]>
>>>>>> To: Shraddha Hegde<[email-masked]>;
>>>>>> [email-masked];[email-masked]; Robert Raszuk
>>>>>> <[email-masked]>
>>>>>> Cc: Christian Hopps<[email-masked]>;
>>>>>> <ginsberg=[email-masked]>;[email-masked];
>>>>>> [email-masked]; Acee Lindem (acee)<[email-masked]>
>>>>>>> *From:[email-masked]<[email-masked]>
>>>>>>> *To:* Peter Psenak<[email-masked]>;[email-masked]; Robert
>>>>>>> Raszuk<[email-masked]>
>>>>>>> *Cc:* Christian Hopps<[email-masked]>;
>>>>>>> <ginsberg=[email-masked]>;[email-masked];
>>>>>>> [email-masked]; Acee Lindem (acee)<[email-masked]>
>>>>>>>          On 20/08/2020 13:58,[email-masked]
>>>>>>>                      Le 18/08/2020 à 19:02,[email-masked]
>>>>>>>                                   *Cc:[email-masked]  <mailto:[email-masked]>
>>>>>>> NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPt h_0 
>>>>>>> 3pN2Sfl$ >
>>>>>>>
>>>>>>> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__; !!N 
>>>>>>> E 
>>>>>>> t6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1 ir2 
>>>>>>> Q Dxsg$>
>>>>>>>
>>>>>>>
>>>>>>>                                   This does not help.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ lsr 
>>>>>>> _ 
>>>>>>> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAu fXg 
>>>>>>> y h1ivswJmIk$>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ lsr 
>>>>>>> _ 
>>>>>>> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAu fXg 
>>>>>>> y h1ivswJmIk$>
>>>>>>>
>>>>>>>
>>>>>>>                      --
>>>>>>>                      Orange logo
>>>>>>> <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk !U6 
>>>>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk! WKu 
>>>>>>> <https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk !U6 
>>>>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk! WKu 
>>>>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk! WKu