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

Wed, 02 Sep 2020 02:13:03 -0700 

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-jnYKFPl7DWC_fZCGDapvakBVKlZPth_03Sd1J7b$

"To advertise a link affinity in a form of the AG or EAG that is used
   during Flex-Algorithm calculation, an Application Specific Link
   Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
   of Extended Link TLV as described in [I-D.ietf-ospf-te-link-attr-reuse]
   MUST be used. The advertisement MUST indicate that it is usable by the
   Flex-Algorithm application."

This is consistent with normative statements in both 
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-isis-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_09_HTtuT$
  and 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_08_P1Wmy$
which REQUIRE the use of application specific advertisements by all 
applications other than the legacy applications (RSVP-TE, Segment Routing 
Policy,  Loop Free Alternate).

draft-hegdeppsenak-isis-sr-flex-algo had a lifetime of 10 months(V00 published 
in July 2017) and draft-ppsenak-ospf-sr-flex-algo only 3 months (V00 published 
in Feb 2018).

Juniper may have its own reasons why over the course of the past two years it 
has chosen not to modify its early implementation to be compatible with what is 
defined in the WG adopted draft. We do not question this choice. But it seems 
the most appropriate way to communicate this is for Juniper to document in its 
vendor specific documents that its implementation is based on a pre-WG draft 
and is incompatible with the IETF defined standard. IETF documents are not the 
correct place for such proprietary information.

It is obvious that the implementation that is not following the final 
specification will not interoperate with other implementations that do so. 
There is no need to mention that in the RFC.

thanks,
Peter and Les



On 25/08/2020 17:27, Shraddha Hegde wrote:

Hi All,

draft-lsr-flex-algo-00 was created by combining

draft-hegdeppsenak-isis-sr-flex-algo-02 and
draft-ppsenak-ospf-sr-flex-algo-00.

When draft-lsr-flex-algo-00 was published as a WG document, it
included

a requirement for using te-app encodings that did not exist in either

draft-hegdeppsenak-isis-sr-flex-algo-02 and
draft-ppsenak-ospf-sr-flex-algo-00.

Juniper's currently released implementation of flex-algo uses legacy
encodings,

as opposed to te-app encodings.  I would like the following text added
to

draft-lsr-flex-algo in order to record the history of these changes
and to make

operators aware of possible inter-op problems that may arise due to
the

non-backward compatible nature of mandating ASLA encodings.

=====

11.  Advertisement of Link Attributes for Flex-Algorithm

" Earlier versions of this draft did not mandate the use of ASLA TLVs
for encoding the

link attributes. There may be implementations that depend on legacy
encodings as defined in

RFC 5305, RFC 7810 , RC 3630 and RFC 7471. Implementations that look
at only ASLA encodings

for flex-algo based on this version of the document will not
interoperate with versions

that use legacy advertisements. "

========

Rgds

Shraddha

Juniper Business Use Only

*From:*[email protected] <[email protected]>
*Sent:* Thursday, August 20, 2020 7:56 PM
*To:* Peter Psenak <[email protected]>; [email protected]; Robert Raszuk
<[email protected]>
*Cc:* Christian Hopps <[email protected]>;
[email protected]; Les Ginsberg (ginsberg)
<[email protected]>; [email protected]; [email protected];
Acee Lindem (acee) <[email protected]>
*Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

*[External Email. Be cautious of content]*

Peter,

Le 20/08/2020 à 14:12, Peter Psenak a écrit :

     Hi Olivier,

     On 20/08/2020 13:58, [email protected]
     <mailto:[email protected]> wrote:

         Hi Peter,

         Thank for the new version.

         Le 19/08/2020 à 14:00, Peter Psenak a écrit :

             Olivier,

         [ ... ]

                 So, to speed up the deployment, I would prefer a
                 reference to a delay value that could be advertise by
                 means of RFC7471, RFC8570 and/or TE-App draft. It is
                 then up to the operator to ensure the coherency of what
                 it is announced in its network by the different routers.


             I know you don't like the app specific link advertisement,
             but I'm afraid what you ask for is absolutely wrong.

             We defined the ASLA encoding to address a real problems for
             advertising the link attributes. We allow the link
             attributes to be advertised in both legacy and ASLA
             advertisement for legacy application (RSVP-TE, SRTE) to
             address the backward compatibility. Flex-algo is a new
             application, there is absolutely no need to use the legacy
             advertisement. Doing so would just extend the problem to the
             flex-algo application.


         Regarding the new version you provided, new section 5.1 (for
         IS-IS) and section 5.2 (for OSPF) mention respectively RFC 8570
         and RFC 7471 for the definition of Min delay and TE metric which
         is fine for me. But, they also made reference to draft
         isis-te-app, respectively ospf-te-link-attr-reuse to encode
         these value.


     that's what people were asking for. And it is right because we are
     mandating the usage of ALSA encoding for any flex-algo related link
     attributes.

         Here, it is confusing.


     I don't see how much more clear we can make it.

         Indeed, RFC 8570 and RFC 7471 also define the way to encode TE
         metric and Min delay.


     you have to distinguish between two things:

     a)  where Min delay and TE metric were defined - RFC 8570 and RFC 7471
     b)  how we encode it for flex-algo - isis-te-app,
     ospf-te-link-attr-reuse


         What I'm suggesting, is a clear reference to the RFC for TE
         metric and Min delay definition as well as the encoding
         (especially for the delay) while leaving open the door to how
         the router acquire these values: legacy a.k.a. RFC 8570 & 7471
         or new draft a.k.a draft-isis-te-app & draft-ospf-link-attr-reuse.


     no. This will not be done. We only allow ASLA advertisement for
     these metrics and other link attributes that are used for flex-algo.
     It is done for a reason and I have already explained that.

OK. Reading section 11 which clarify how metrics are convey, let me
suggest to make a reference to section 11 in section 5.1 and 5.2
instead of reference to drafts.


         In fact, in section 17.1.2, you mention only reference to RFC
         8570 & RFC7471 for the IANA definition which is fine for me.


     because in registry, we are defining a metric type, not how we are
     going to advertise it for the link.

OK.

         I would suggest the same wording for section 5.1. and 5.2
         leaving operator free about how it collect the values from the
         neighbour routers: legacy or new method.


     please stop trying to make use of legacy RSVP-TE link advertisements
     for flex-algo - it will not be allowed.

This raise to me a simple question: Is it possible to use 2 different
Flex Algo with delay metric, one for App A and another one for App B ?
if yes, how can we link metrics advertise in ALSA A from metrics
advertise in ALSA B ? The draft mention only one bit for Flex-Algo.

Regards,

Olivier

PS. I note a duplicate paragraph in section 12: "When computing the
path for a given Flex-Algorithm, the metric-type that is part of the
Flex-Algorithm definition (Section 5) MUST be used."


     thanks,
     Peter


         Regards

         Olivier

         PS. We have a pre-alpha implementation of flex algo using the
         legacy metrics and I know that recent IOS-XR provided similar
         implementation of flex algo based on legacy metrics.


             regards,
             Peter


                 Regards

                 Olivier

                 Le 18/08/2020 à 19:02, [email protected]
                 <mailto:[email protected]> a écrit :


                     Robert,

                     Thank you, exactly.

                     We just need a clarification of the document.  I
                     don’t understand why this is such a big deal.

                     Tony


                         On Aug 18, 2020, at 9:22 AM, Robert Raszuk
                         <[email protected] <mailto:[email protected]>
                         <mailto:[email protected]>
                         <mailto:[email protected]>> wrote:

                         Les,

                         I think this is not very obvious as Tony is
                         pointing out.

                         See RFC 8570 says:

                                 Type    Description
---------------------------------------------------- 

                                  33     Unidirectional Link Delay

                                  34     Min/Max Unidirectional Link Delay

                         That means that is someone implementing it reads
                         text in this draft literally (meaning Minimum
                         value of Unidirectional Link Delay) it may pick
                         minimum value from ULD type 33 :)

                         If you want to be precise this draft may say
                         minimum value of Min/Max Unidirectional Link
                         Delay (34) and be done.

                         That's all.

                         Cheers,
                         R.



                         On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg
                         (ginsberg) <[email protected]
                         <mailto:[email protected]>
                         <mailto:[email protected]>
                         <mailto:[email protected]>> wrote:

                              Tony –

                              As an author of both RFC 8570 and
                         I-D.ietf-isis-te-app, I am not
                              sure why you are confused – nor why you got
                         misdirected to code
                              point 33.

                              RFC 8570 (and its predecessor RFC 7810)
                         define:

                              34           Min/Max Unidirectional Link Delay

                              This sub-TLV contains two values:

                              “Min Delay:  This 24-bit field carries the
                         minimum measured link
                              delay

                                    value (in microseconds) over a
                         configurable interval,
                              encoded as

                                    an integer value.

                                 Max Delay:  This 24-bit field carries
                         the maximum measured
                              link delay

                                    value (in microseconds) over a
                         configurable interval,
                              encoded as

                                    an integer value.”

                              It seems clear to me that the flex-draft is
                         referring to Min
                              Unidirectional Link Delay in codepoint 34.

                              I agree it is important to be unambiguous
                         in specifications, but
                              I think Peter has been very clear.

                              Please explain how you managed to end up at
                         code point 33??

                                 Les

                              *From:* Lsr <[email protected]
                         <mailto:[email protected]>
                         <mailto:[email protected]>
                         <mailto:[email protected]>>
                              *On Behalf Of *[email protected]
                         <mailto:*[email protected]>
                         <mailto:[email protected]> <mailto:[email protected]>
                              *Sent:* Tuesday, August 18, 2020 7:44 AM
                              *To:* Peter Psenak (ppsenak)
                         <[email protected] <mailto:[email protected]>
                         <mailto:[email protected]>
                         <mailto:[email protected]>>
                              *Cc:* [email protected] <mailto:[email protected]>
                         <mailto:[email protected]> <mailto:[email protected]>;
                         [email protected] <mailto:[email protected]>
                         <mailto:[email protected]>
                         <mailto:[email protected]>; Christian Hopps
                         <[email protected] <mailto:[email protected]>
                         <mailto:[email protected]>
                         <mailto:[email protected]>>; Acee Lindem (acee)
                         <[email protected] <mailto:[email protected]>
                         <mailto:[email protected]>
                         <mailto:[email protected]>>;
                         [email protected]
                         <mailto:[email protected]>
                         <mailto:[email protected]>
                         <mailto:[email protected]>
                              *Subject:* Re: [Lsr] WG Last Call for
                         draft-ietf-lsr-flex-algo

                              Hi Peter,



                                  section 5.1 of the
                         draft-ietf-lsr-flex-algo says:


                                  Min Unidirectional Link Delay as
                         defined in
                                  [I-D.ietf-isis-te-app].

                                  We explicitly say "Min Unidirectional
                         Link Delay", so this
                                  cannot be mixed with other delay values
                         (max, average).

                              The problem is that that does not exactly
                         match “Unidirectional
                              Link Delay” or “Min/Max Unidirectional Link
                         Delay”, leading to
                              the ambiguity. Without a clear match, you
                         leave things open to
                              people guessing. Now, it’s a metriic, so of
                         course, you always
                              want to take the min.  So type 33 seems
                         like a better match.





                                  section 7.3. of ietf-isis-te-app says:

                                  Type   Description
                                                   Encoding
Reference
--------------------------------------------------------- 

                                  34      Min/Max Unidirectional Link
                         Delay    RFC8570

                              And it also says:

                              33      Unidirectional Link Delay RFC8570
                         
<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8570__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_03pN2Sfl$
 >
<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__;!!NE 
t6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ir2Q
Dxsg$>


                              This does not help.



                                  So, IMHO what we have now is correct
                         and sufficient, but I
                                  have no issue adding the text you
                         proposed below.

                              What you have now is ambiguous. We have a
                         responsibility, as
                              writers of specifications, to be precise
                         and clear.  We are not
                              there yet.



                                  BTW, before I posted 09 version of
                         flex-algo draft, I asked
                                  if you were fine with just referencing
                         ietf-isis-te-app in
                                  5.1. I thought you were, as you did not
                         indicate otherwise.

                              My bad, I should have pressed the issue.



                                  Anyway, I consider this as a pure
                         editorial issue and
                                  hopefully not something that would
                         cause you to object the WG
                                  LC of the flex-algo draft.

                              I’m sorry, I think that this is trivially
                         resolved, but important
                              clarification.

                              You also have an author’s email that is
                         bouncing, so at least one
                              more spin is required.

                              Sorry,

                              Tony


                         _______________________________________________
                              Lsr mailing list
                         [email protected] <mailto:[email protected]>
                         <mailto:[email protected]> <mailto:[email protected]>
                         
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_07ffIqQQ$
<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_ 
_;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgy
h1ivswJmIk$>




                     _______________________________________________
                     Lsr mailing list
                     [email protected] <mailto:[email protected]>
                     
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_07ffIqQQ$
<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_ 
_;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgy
h1ivswJmIk$>


                 --
                 Orange logo 
<https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$
 >
<https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuL 
WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>


                 Olivier Dugeon
                 Orange Expert, Future Networks
                 Open Source Referent
                 Orange/IMT/OLN/WTC/IEE/iTeQ

                 fixe : +33 2 96 07 28 80
                 mobile : +33 6 82 90 37 85
                 [email protected]
                 <mailto:[email protected]>
                 <mailto:[email protected]>
                 <mailto:[email protected]>
______________________________________________________________________ 
___________________________________________________


                 Ce message et ses pieces jointes peuvent contenir des
                 informations confidentielles ou privilegiees et ne
                 doivent donc
                 pas etre diffuses, exploites ou copies sans
                 autorisation. Si vous avez recu ce message par erreur,
                 veuillez le signaler
                 a l'expediteur et le detruire ainsi que les pieces
                 jointes. Les messages electroniques etant susceptibles
                 d'alteration,
                 Orange decline toute responsabilite si ce message a ete
                 altere, deforme ou falsifie. Merci.

                 This message and its attachments may contain
                 confidential or privileged information that may be
                 protected by law;
                 they should not be distributed, used or copied without
                 authorisation.
                 If you have received this email in error, please notify
                 the sender and delete this message and its attachments.
                 As emails may be altered, Orange is not liable for
                 messages that have been modified, changed or falsified.
                 Thank you.

         --
         Orange logo 
<https://urldefense.com/v3/__http://www.orange.com__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_0350df6q$
 >
<https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuL 
WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>


         Olivier Dugeon
         Orange Expert, Future Networks
         Open Source Referent
         Orange/IMT/OLN/WTC/IEE/iTeQ

         fixe : +33 2 96 07 28 80
         mobile : +33 6 82 90 37 85
         [email protected] <mailto:[email protected]>
         <mailto:[email protected]>
         <mailto:[email protected]>
______________________________________________________________________ 
___________________________________________________


         Ce message et ses pieces jointes peuvent contenir des
         informations confidentielles ou privilegiees et ne doivent donc
         pas etre diffuses, exploites ou copies sans autorisation. Si
         vous avez recu ce message par erreur, veuillez le signaler
         a l'expediteur et le detruire ainsi que les pieces jointes. Les
         messages electroniques etant susceptibles d'alteration,
         Orange decline toute responsabilite si ce message a ete altere,
         deforme ou falsifie. Merci.

         This message and its attachments may contain confidential or
         privileged information that may be protected by law;
         they should not be distributed, used or copied without
         authorisation.
         If you have received this email in error, please notify the
         sender and delete this message and its attachments.
         As emails may be altered, Orange is not liable for messages that
         have been modified, changed or falsified.
         Thank you.

--
Orange logo
<https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuL
WanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>

*Olivier Dugeon
*Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
[email protected] <mailto:[email protected]>

______________________________________________________________________
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or
privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.






_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to