> On Sep 7, 2020, at 11:43 PM, Shraddha Hegde > <[email protected]> wrote: > > Peter, > > > Thanks for the conclusion on adding L-bit clarification in the > draft-ietf-lsr-flex-algo. > > Snip to open comments. > >> 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://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.
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] > > > Rgds > Shraddha > > > Juniper Business Use Only > > -----Original Message----- > From: Peter Psenak <[email protected]> > Sent: Thursday, September 3, 2020 1:25 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, > > On 03/09/2020 05:39, Shraddha Hegde wrote: >> 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. > > > 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://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: > > > 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 > > > >> ============ >> >> >> Rgds >> Shraddha >> >> >> Juniper Business Use Only >> >> -----Original Message----- >> From: Peter Psenak <[email protected]> >> Sent: Wednesday, September 2, 2020 2:43 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, >> >> please see inline: >> >> >> On 02/09/2020 06:45, Shraddha Hegde wrote: >>> 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. >> >> 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. >> >> >> 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. >> >>> >>> 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. >> >>> Implementations from a year ago may not interoperate with published RFC. >> >> 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 >> >> >>> 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-ls >>> r >>> -flex-algo-00*section-9__;Iw!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jn >>> Y KFPl7DWC_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-is >>> i >>> s-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCG >>> D >>> apvakBVKlZPth_09_HTtuT$ and >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie >>> t >>> f-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-j >>> n YKFPl7DWC_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_ >>>> 0 >>>> 3pN2Sfl$ > >>>> >>>> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__;!! >>>> N >>>> E >>>> t6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ir >>>> 2 >>>> Q >>>> 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/ls >>>> r >>>> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKl >>>> Z >>>> Pth_07ffIqQQ$ >>>> >>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ls >>>> r >>>> _ >>>> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufX >>>> g >>>> y >>>> h1ivswJmIk$> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> [email protected] <mailto:[email protected]> >>>> >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls >>>> r >>>> __;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKl >>>> Z >>>> Pth_07ffIqQQ$ >>>> >>>> <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 >>>> 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!U >>>> 6 9buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ > >>>> >>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WK >>>> u L 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!WK >>>> u L 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
