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

[Peter Psenak <[e-mail]>]

Hi Bruno,

please see inline:

On 07/09/2020 17:31, [e-mail] wrote:
> Hi Peter,
> 
>> From: Lsr [mailto:[e-mail]] On Behalf Of Peter Psenak
>> Sent: Thursday, September 3, 2020 9:55 AM
>>
>> 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,
> 
> 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.


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

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