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

[Peter Psenak]

Gunter,

On 03/09/2020 14:49, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
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.

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


* 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

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

thanks,
Peter

(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 <ppse...@cisco.com>
Sent: Thursday, September 3, 2020 12:02
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_ve...@nokia.com>; Selderslaghs, Rudy 
(Nokia - BE/Antwerp) <rudy.seldersla...@nokia.com>; Shraddha Hegde <shrad...@juniper.net>; 
olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk <rob...@raszuk.net>
Cc: Christian Hopps <cho...@chopps.org>; draft-ietf-lsr-flex-algo....@ietf.org; Les 
Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org; lsr-...@ietf.org; Acee Lindem 
(acee) <a...@cisco.com>
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 <lsr-boun...@ietf.org> On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 11:19
To: Selderslaghs, Rudy (Nokia - BE/Antwerp)
<rudy.seldersla...@nokia.com>; Peter Psenak
<ppsenak=40cisco....@dmarc.ietf.org>; Shraddha Hegde
<shrad...@juniper.net>; olivier.dug...@orange.com; tony...@tony.li;
Robert Raszuk <rob...@raszuk.net>
Cc: Christian Hopps <cho...@chopps.org>;
draft-ietf-lsr-flex-algo....@ietf.org; Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org>; lsr@ietf.org; lsr-...@ietf.org;
Acee Lindem (acee) <a...@cisco.com>
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 <lsr-boun...@ietf.org> On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 9:55 AM
To: Shraddha Hegde <shrad...@juniper.net>; olivier.dug...@orange.com;
tony...@tony.li; Robert Raszuk <rob...@raszuk.net>
Cc: Christian Hopps <cho...@chopps.org>;
draft-ietf-lsr-flex-algo....@ietf.org; Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org>; lsr@ietf.org;
lsr-...@ietf.org; Acee Lindem (acee) <a...@cisco.com>
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 <ppse...@cisco.com>
Sent: Wednesday, September 2, 2020 2:43 PM
To: Shraddha Hegde <shrad...@juniper.net>;
olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk
<rob...@raszuk.net>
Cc: Christian Hopps <cho...@chopps.org>;
draft-ietf-lsr-flex-algo....@ietf.org; Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org>; lsr@ietf.org;
lsr-...@ietf.org; Acee Lindem (acee) <a...@cisco.com>
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 <ppse...@cisco.com>
Sent: Thursday, August 27, 2020 3:34 PM
To: Shraddha Hegde <shrad...@juniper.net>;
olivier.dug...@orange.com; tony...@tony.li; Robert Raszuk
<rob...@raszuk.net>
Cc: Christian Hopps <cho...@chopps.org>;
draft-ietf-lsr-flex-algo....@ietf.org; Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org>; lsr@ietf.org;
lsr-...@ietf.org; Acee Lindem (acee) <a...@cisco.com>
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:*olivier.dug...@orange.com <olivier.dug...@orange.com>
*Sent:* Thursday, August 20, 2020 7:56 PM
*To:* Peter Psenak <ppse...@cisco.com>; tony...@tony.li; Robert
Raszuk <rob...@raszuk.net>
*Cc:* Christian Hopps <cho...@chopps.org>;
draft-ietf-lsr-flex-algo....@ietf.org; Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org>; lsr@ietf.org;
lsr-...@ietf.org; Acee Lindem (acee) <a...@cisco.com>
*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, olivier.dug...@orange.com
         <mailto:olivier.dug...@orange.com> 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, tony...@tony.li
                     <mailto:tony...@tony.li> 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
                             <rob...@raszuk.net <mailto:rob...@raszuk.net>
                             <mailto:rob...@raszuk.net>
                             <mailto:rob...@raszuk.net>> 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=40cisco....@dmarc.ietf.org
                             <mailto:ginsberg=40cisco....@dmarc.ietf.org>
                             <mailto:40cisco....@dmarc.ietf.org>
                             <mailto:40cisco....@dmarc.ietf.org>> 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 <lsr-boun...@ietf.org
                             <mailto:lsr-boun...@ietf.org>
                             <mailto:lsr-boun...@ietf.org>
                             <mailto:lsr-boun...@ietf.org>>
                                  *On Behalf Of *tony...@tony.li
                             <mailto:*tony...@tony.li>
                             <mailto:tony...@tony.li> <mailto:tony...@tony.li>
                                  *Sent:* Tuesday, August 18, 2020 7:44 AM
                                  *To:* Peter Psenak (ppsenak)
                             <ppse...@cisco.com <mailto:ppse...@cisco.com>
                             <mailto:ppse...@cisco.com>
                             <mailto:ppse...@cisco.com>>
                                  *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>
                             <mailto:lsr@ietf.org> <mailto:lsr@ietf.org>;
                             lsr-...@ietf.org <mailto:lsr-...@ietf.org>
                             <mailto:lsr-...@ietf.org>
                             <mailto:lsr-...@ietf.org>; Christian Hopps
                             <cho...@chopps.org <mailto:cho...@chopps.org>
                             <mailto:cho...@chopps.org>
                             <mailto:cho...@chopps.org>>; Acee Lindem (acee)
                             <a...@cisco.com <mailto:a...@cisco.com>
                             <mailto:a...@cisco.com>
                             <mailto:a...@cisco.com>>;
                             draft-ietf-lsr-flex-algo....@ietf.org
                             <mailto:draft-ietf-lsr-flex-algo....@ietf.org>
                             <mailto:draft-ietf-lsr-flex-algo....@ietf.org>
                             <mailto:draft-ietf-lsr-flex-algo....@ietf.org>
                                  *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
                             Lsr@ietf.org <mailto:Lsr@ietf.org>
                             <mailto:Lsr@ietf.org>
<mailto:Lsr@ietf.org>
                             
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
                         Lsr@ietf.org <mailto:Lsr@ietf.org>
                         
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
                     olivier.dug...@orange.com
                     <mailto:olivier.dug...@orange.com>
                     <mailto:olivier.dug...@orange.com>
                     <mailto:olivier.dug...@orange.com>


__________________________________________________________________
___ _ ___________________________________________________


                     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
             olivier.dug...@orange.com <mailto:olivier.dug...@orange.com>
             <mailto:olivier.dug...@orange.com>
             <mailto:olivier.dug...@orange.com>


__________________________________________________________________
___ _ ___________________________________________________


             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
olivier.dug...@orange.com <mailto:olivier.dug...@orange.com>

__________________________________________________________________
___ _ ___________________________________________________

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr







_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr