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 protected]> Sent: Thursday, August 27, 2020 3:34 PM To: Shraddha Hegde <[email protected]>; [email protected]; [email protected]; Robert Raszuk <[email protected]> Cc: Christian Hopps <[email protected]>; [email protected]; Les Ginsberg (ginsberg) <[email protected]>; [email protected]; [email protected]; Acee Lindem (acee) <[email protected]> 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 protected] <[email protected]> > *Sent:* Thursday, August 20, 2020 7:56 PM > *To:* Peter Psenak <[email protected]>; [email protected]; Robert Raszuk > <[email protected]> > *Cc:* Christian Hopps <[email protected]>; > [email protected]; Les Ginsberg (ginsberg) > <[email protected]>; [email protected]; [email protected]; > Acee Lindem (acee) <[email protected]> > *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 protected] > <mailto:[email protected]> 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 protected] > <mailto:[email protected]> 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 protected] <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]>> 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) <[email protected] > <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]>> 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 protected] > <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]>> > *On Behalf Of *[email protected] > <mailto:*[email protected]> > <mailto:[email protected]> <mailto:[email protected]> > *Sent:* Tuesday, August 18, 2020 7:44 AM > *To:* Peter Psenak (ppsenak) > <[email protected] <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]>> > *Cc:* [email protected] <mailto:[email protected]> > <mailto:[email protected]> <mailto:[email protected]>; > [email protected] <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]>; Christian Hopps > <[email protected] <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]>>; Acee Lindem (acee) > <[email protected] <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]>>; > [email protected] > <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]> > *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 protected] <mailto:[email protected]> > <mailto:[email protected]> <mailto:[email protected]> > > 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 protected] <mailto:[email protected]> > > 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 protected] > <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]> > > > ______________________________________________________________________ > ___________________________________________________ > > > 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 protected] <mailto:[email protected]> > <mailto:[email protected]> > <mailto:[email protected]> > > > ______________________________________________________________________ > ___________________________________________________ > > > 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 protected] <mailto:[email protected]> > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
