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 protected]> Sent: Thursday, September 3, 2020 12:02 To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email protected]>; Selderslaghs, Rudy (Nokia - BE/Antwerp) <[email protected]>; 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 Gunter, On 03/09/2020 11:53, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > 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. > > Read the text in chapter 4.2: > >> 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. > > 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. 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 > > G/ > > > > > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of Peter Psenak > Sent: Thursday, September 3, 2020 11:19 > To: Selderslaghs, Rudy (Nokia - BE/Antwerp) > <[email protected]>; Peter Psenak > <[email protected]>; 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 > > 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 >> >> -----Original Message----- >> From: Lsr <[email protected]> On Behalf Of Peter Psenak >> Sent: Thursday, September 3, 2020 9:55 AM >> 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 >> >> 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://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 >> >> >> >>> ============ >>> >>> >>> 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- >>>> lsr >>>> -flex-algo-00*section-9__;Iw!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2- >>>> jnY 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- >>>> isi >>>> s-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZ >>>> CGD >>>> 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$ >>>> 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_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. >>>>> >>>>> >>>>> >>>>> 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_fZCGDapvakBV >>>>> KlZ >>>>> Pth_07ffIqQQ$ >>>>> >>>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ >>>>> lsr >>>>> _ >>>>> _;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAu >>>>> fXg >>>>> y >>>>> 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_fZCGDapvakBV >>>>> KlZ >>>>> Pth_07ffIqQQ$ >>>>> >>>>> <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 >>>>> 9buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ > >>>>> >>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk! >>>>> WKu 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 >>>>> !U6 >>>>> 9buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$ > >>>>> >>>>> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk! >>>>> WKu 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! >>>>> WKu 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 >> >> > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
