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

From: Christian Hopps <[email-masked]>
Date: Mon, 17 Aug 2020 19:30:04 -0400

This begins a 2 week WG Last Call, ending after September 1st, 2020, for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you aware of any other IPR beyond what is already posted:

  [From https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.

---

From: [email-masked]
Date: Mon, 17 Aug 2020 16:47:46 -0700

>  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

Hi,

I’d like to raise an objection.

Recently, I requested (and I thought that Peter agreed to) a clarification of the Min Unidirectional Link Delay.

As of version -08, the draft references RFC 7810 for the Metric-type in Section 5.1.  

That RFC defines both a “Unidirectional Link Delay” (section 4.1) and “Min/Max Unidirectional Link Delay” (section 4.2).

I requested that the reference be extended to specify the section.

Instead, as of -09, the reference has been changed to refer to ietf-isis-te-app.  This is somewhat helpful becuase it makes it clear that this should be found
in the Application Specific Link Attributes Sub-TLV, but it still does not resolve the ambiguity of which sub-sub-TLV should be used.

I would again request that this be clarified.  Proposed text:

	1: Min Unidirectional Link Delay as defined in [RFC 7810], section 4.2, encoded in the Application Specific Link Attributes Sub-TLV [I-D.ietf-isis-te-app].

Thank you.

Regards,
Tony

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 18 Aug 2020 04:24:42 +0000

As a co-author, I am not aware of IPR beyond what has been already disclosed on this document.

Thanks,
Ketan

-----Original Message-----
From: Christian Hopps <[email-masked]> 
Sent: 18 August 2020 05:00
To: [email-masked]
Cc: Christian Hopps <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: WG Last Call for draft-ietf-lsr-flex-algo

Thanks,
Chris & Acee.

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 18 Aug 2020 05:33:10 +0000

I am not aware of any undisclosed IPR.

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: Christian Hopps <[email-masked]> 
Sent: Tuesday, August 18, 2020 5:00 AM
To: [email-masked]
Cc: Christian Hopps <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: WG Last Call for draft-ietf-lsr-flex-algo

Thanks,
Chris & Acee.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 18 Aug 2020 11:01:25 +0200

Hi Tony,

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).

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

Type   Description                          Encoding
                                             Reference
---------------------------------------------------------
34      Min/Max Unidirectional Link Delay    RFC8570

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

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.

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.

thanks,
Peter

---

From: [email-masked]
Date: Tue, 18 Aug 2020 07:44:28 -0700

Hi Peter,

> 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.

> Type   Description                          Encoding

And it also says:

33      Unidirectional Link Delay            RFC8570 <https://tools.ietf.org/html/rfc8570>

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

---

From: Peter Psenak <[email-masked]>
Date: Tue, 18 Aug 2020 17:29:08 +0200

Hi Tony,

On 18/08/2020 16:44, [email-masked] wrote:
> 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.

I'm not sure what do you mean by 33. "Min/Max Unidirectional Link Delay" 
is Type 34.

thanks,
Peter

> 33      Unidirectional Link DelayRFC8570  <https://tools.ietf.org/html/rfc8570>
> 
> 
> 
> 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.
> 
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 18 Aug 2020 16:04:22 +0000

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

Hi Peter,

And it also says:

33      Unidirectional Link Delay            RFC8570<https://tools.ietf.org/html/rfc8570>

This does not help.

Sorry,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Aug 2020 18:22:21 +0200

Les,

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

See RFC 8570 says:

      Type    Description
      ----------------------------------------------------
       33     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=
[email-masked]> 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.
>
>
>
> It seems clear to me that the flex-draft is referring to Min
> Unidirectional Link Delay in codepoint 34.
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of * [email-masked]
> *Sent:* Tuesday, August 18, 2020 7:44 AM
> *To:* Peter Psenak (ppsenak) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Christian Hopps <[email-masked]>;
> Acee Lindem (acee) <[email-masked]>; [email-masked]
> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
>
>
>
>
> Hi Peter,
>
>
>
>
>
> 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.
>
>
>
>
>
> fine with just referencing ietf-isis-te-app in 5.1. I thought you were, as
> you did not indicate otherwise.
>
>
>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: [email-masked]
Date: Tue, 18 Aug 2020 10:02:47 -0700

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-masked]> wrote:
> 
> Les,
> 
> 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=[email-masked] <mailto:[email-masked]>> wrote:
> Tony –
> 
>  
> 
> From: Lsr <[email-masked] <mailto:[email-masked]>> On Behalf Of [email-masked] <mailto:[email-masked]>
> To: Peter Psenak (ppsenak) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Christian Hopps <[email-masked] <mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Aug 2020 19:10:24 +0200

Hi Tony,

I am not sure what the deal is :)

But fact is that we never defined a type which this draft is referring to

"Min Unidirectional Link Delay" just does not exist in any IANA registry so
even any search for that will fail.

Perhaps authors assumed that:

Min/Max Unidirectional Link Delay means both "Min Unidirectional Link
Delay" & "Max Unidirectional Link Delay" but this is just asking
for ambiguity.

Cheers,
R.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 18 Aug 2020 19:33:03 +0200

Hi Robert,

On 18/08/2020 19:10, Robert Raszuk wrote:
> "Min Unidirectional Link Delay" just does not exist in any IANA registry 
> so even any search for that will fail.
> 

yes, Min/Max Unidirectional Link Delay advertise both Min and Max and we 
use Min out of that.

I'll make the clarification in the draft, so we can close this discussion.

thanks,
Peter

> 
> Cheers,
> R.
> 
> On Tue, Aug 18, 2020 at 7:02 PM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     Robert,
> 
>     Thank you, exactly.
> 
>>     On Aug 18, 2020, at 9:22 AM, Robert Raszuk <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     Les,
>>
>>     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=[email-masked]
>>     <mailto:[email-masked]>> 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.”____
>>
>>         __ __
>>
>>         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-masked]
>>         <mailto:[email-masked]>> *On Behalf Of [email-masked]
>>         <mailto:[email-masked]>
>>         *To:* Peter Psenak (ppsenak) <[email-masked]
>>         <mailto:[email-masked]>>
>>         *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>>         <mailto:[email-masked]>; Christian Hopps <[email-masked]
>>         <mailto:[email-masked]>>; Acee Lindem (acee)
>>         <[email-masked] <mailto:[email-masked]>>;
>>         [email-masked]
>>         <mailto:[email-masked]>
>>         *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:____
>>
>>
>>             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.____
>>
>>
>>
>>         ____
>>
>>
>>
>>             34      Min/Max Unidirectional Link Delay    RFC8570____
>>
>>         __ __
>>
>>         __ __
>>
>>         And it also says:____
>>
>>         __ __
>>
>>         33      Unidirectional Link Delay RFC8570
>>         <https://tools.ietf.org/html/rfc8570>____
>>
>>         __ __
>>
>>         __ __
>>
>>         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____
>>
>>         __ __
>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 18 Aug 2020 19:18:03 +0000

Tony/Robert –

Whatever clarification Peter may choose to make would be fine – but I do question your casual ignoring of adjectives. 😊

There are three values being advertised:

33 - Unidirectional Link Delay
34 – Min/Max Unidirectional Link Delay
         Meaning two values are advertised in this codepoint:
         Min Unidirectional Link Delay
         Max Unidirectional Link Delay

Now, the flex algo draft states: Min Unidirectional Link Delay

If you want to argue that “Min Unidirectional Link Delay” != “Min/Max Unidirectional Link Delay” – I think you are pedantically correct.

But how that leads you to simply truncate “Min” and conclude that this is really “Unidirectional Link Delay” is a leap that I cannot follow.

Perhaps you don’t really like the fact that RFC 8570 encoding combined Min/Max in a single codepoint – but that ship sailed years ago.

Given that RFC 8570 is very clear in showing that the encoding includes:

<snip>
   0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A| RESERVED    |                   Min Delay                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   RESERVED    |                   Max Delay                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<end snip>

my ability to see your POV is somewhat limited.

Perhaps you could own that a more careful reading is possible?

   Les

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, August 18, 2020 10:03 AM
To: Robert Raszuk <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Robert,

Thank you, exactly.

Tony

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

Les,

See RFC 8570 says:

      Type    Description

That's all.

Cheers,
R.

On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
Tony –

   Les

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

Hi Peter,

And it also says:

This does not help.

Sorry,
Tony

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Aug 2020 21:20:29 +0200

Les,

> and conclude that this is really “Unidirectional Link Delay” is a leap
that I cannot follow.

I would never suggest to do that.

My suggestion was to rename "Min Unidirectional Link Delay" to "minimum
value of Min/Max Unidirectional Link Delay" and move on.

Cheers,
R.

On Tue, Aug 18, 2020 at 9:18 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Tony/Robert –
>
>
>
> Whatever clarification Peter may choose to make would be fine – but I do
> question your casual ignoring of adjectives. 😊
>
>
>
> If you want to argue that “Min Unidirectional Link Delay” != “Min/Max
> Unidirectional Link Delay” – I think you are pedantically correct.
>
>
>
> But how that leads you to simply truncate “Min” and conclude that this is
> really “Unidirectional Link Delay” is a leap that I cannot follow.
>
>
>
> Perhaps you don’t really like the fact that RFC 8570 encoding combined
> Min/Max in a single codepoint – but that ship sailed years ago.
>
>
>
> *Sent:* Tuesday, August 18, 2020 10:03 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* Christian Hopps <[email-masked]>;
> [email-masked]; Les Ginsberg (ginsberg) <ginsberg=
> [email-masked]>; [email-masked]; [email-masked]; Acee Lindem
> (acee) <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
> *From:* Lsr <[email-masked]> *On Behalf Of [email-masked]

---

From: [email-masked]
Date: Tue, 18 Aug 2020 12:32:39 -0700

Les,

There is no TLV called the Min Unidirectional Link Delay.   

If the document had said “The min delay of the Min/Max Unidirectional Link Delay” then there would be no confusion.

Instead, it is the sloppy writing of ignoring the full name of the TLV that has created ambiguity.

Now, Peter has agreed to make a clarification, so:

	Why are we still fighting?

Tony

> On Aug 18, 2020, at 12:18 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Tony/Robert –
>  
> On Aug 18, 2020, at 9:22 AM, Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Les,
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 18 Aug 2020 20:15:06 +0000

Tony –

I am not “fighting”.
I just found your interpretation very hard to follow.

Moving on…

   Les

From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, August 18, 2020 12:33 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; [email-masked]; Acee Lindem (acee) <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Les,

Tony

On Aug 18, 2020, at 12:18 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Tony/Robert –

<snip>
   0                   1                   2                   3

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, August 18, 2020 10:03 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Robert,

Thank you, exactly.

Tony

Les,

See RFC 8570 says:

      Type    Description

That's all.

Cheers,
R.

   Les

Hi Peter,

And it also says:

This does not help.

Sorry,
Tony

---

From: <[email-masked]>
Date: Wed, 19 Aug 2020 13:42:23 +0200

Hi all

I think the clarification is mandatory and not only in section 5.1 and not only for the delay.

Indeed, section 5.1 makes reference to [I-D.ietf-isis-te-app] while section 17.1.2 makes reference to RFC8570 with the same error. And what about reference to RFC7471 for OSPF ? And, I also notice the same problem with the TE metric (ref to draft te app in section 5.1 and reference to RFC 5305 in section 17.1.2).

So, we need a clear reference to the same document/section/TLVs in both section 5.1 and section 17.1.2 for both delay and TE metric.

But, the question behind, it is which documents ? Future RFC about TE app ? RFC 8570 ? RFC 7471 ?

As an operator, as of today, I have not the possibility to advertise min/max delay in our network as requested in the draft just because it is not available in all commercial routers. So, referring to a future RFC which take months/years before it becomes available/deploy/operational, leave flex algo with delay not ready before a while.

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.

Regards

Olivier

Le 18/08/2020 à 19:02, [email-masked] a écrit :
>>     *From:* Lsr <[email-masked] <mailto:[email-masked]>> *On Behalf Of * [email-masked] <mailto:[email-masked]>
>>     *To:* Peter Psenak (ppsenak) <[email-masked] <mailto:[email-masked]>>
>>     *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Christian Hopps <[email-masked] <mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
-- 
Orange logo <http://www.orange.com>

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-masked] <mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Aug 2020 14:00:43 +0200

Olivier,

On 19/08/2020 13:42, [email-masked] wrote:
> Indeed, section 5.1 makes reference to [I-D.ietf-isis-te-app] while 
> section 17.1.2 makes reference to RFC8570 with the same error. And what 

ok, I will make the same clarification there.

> about reference to RFC7471 for OSPF ? 

will add that.

> And, I also notice the same 
> problem with the TE metric (ref to draft te app in section 5.1 and 
> reference to RFC 5305 in section 17.1.2).

will fix that.

> 
> So, we need a clear reference to the same document/section/TLVs in both 
> section 5.1 and section 17.1.2 for both delay and TE metric.
> 

I don't understand. Min/Max Unidirectional Link Delay is clearly defined 
in RFC 8570 RFC 7471. For flex-algo it is advertised using ASLA 
advertisement. I don't see a problem.

> 
> As an operator, as of today, I have not the possibility to advertise 
> min/max delay in our network as requested in the draft just because it 
> is not available in all commercial routers. So, referring to a future 
> RFC which take months/years before it becomes 
> available/deploy/operational, leave flex algo with delay not ready 
> before a while.

sorry, but we are defining a new extension. This require new encodings 
for flex-algo, so anyone implementing flex-algo needs to implement this 
new encodings.

> 
> 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.

regards,
Peter

>>> literally (meaning Minimum value of Unidirectional Link Delay) it may 
>>> pick minimum value from ULD type 33 :)
>>>
>>>     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.
>>>
>>>     encoded as
>>>     link delay
>>>     encoded as
>>>     *From:* Lsr <[email-masked] <mailto:[email-masked]>>
>>>     *On Behalf Of [email-masked] <mailto:[email-masked]>
>>>     <mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]
>>>     <mailto:[email-masked]>>; [email-masked]
>>>         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.
>>>
>>>
>>>
>>>
>>>
>>>     <https://tools.ietf.org/html/rfc8570>
>>>
>>>     This does not help.
>>>
>>>
>>>
>>>         have no issue adding the text you proposed below.
>>>
>>>     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.
>>>
>>>         hopefully not something that would cause you to object the WG
>>>         LC of the flex-algo draft.
>>>

---

From: <[email-masked]>
Date: Thu, 20 Aug 2020 13:58:48 +0200

Hi Peter,

Thank for the new version.

> Olivier, 
[ ... ]
> 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. Here, it is confusing. Indeed, RFC 8570 and RFC 7471 also define the way to encode TE metric and Min delay.

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.

In fact, in section 17.1.2, you mention only reference to RFC 8570 & RFC7471 for the IANA definition which is fine for me. 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.

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.

Olivier Dugeon

fixe : +33 2 96 07 28 80

---

From: Peter Psenak <[email-masked]>
Date: Thu, 20 Aug 2020 14:12:44 +0200

Hi Olivier,

On 20/08/2020 13:58, [email-masked] wrote:
>>> 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.
>>
>> 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.

> 
> 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.

> 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.

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
>>>
>>>>> literally (meaning Minimum value of Unidirectional Link Delay) it 
>>>>> may pick minimum value from ULD type 33 :)
>>>>>
>>> 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,
>>> This message and its attachments may contain confidential or 
>>> privileged information that may be protected by law;
>>> If you have received this email in error, please notify the sender 
>>> and delete this message and its attachments.

---

From: <[email-masked]>
Date: Thu, 20 Aug 2020 16:25:47 +0200

Peter,

Le 20/08/2020 à 14:12, Peter Psenak a écrit :
>> 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. 
>
>> Indeed, RFC 8570 and RFC 7471 also define the way to encode TE metric and Min delay.
>
> 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."

Olivier Dugeon

fixe : +33 2 96 07 28 80

---

From: Peter Psenak <[email-masked]>
Date: Thu, 20 Aug 2020 17:17:56 +0200

Olivier,

On 20/08/2020 16:25, [email-masked] wrote:
>>>>> 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.
>>>>
>>>> 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 
>>> 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.
>>
> 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.

what is the problem with using the reference to isis-te-app,
ospf-te-link-attr-reuse in 5.1 and 5.2?

>>> 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.
>>
> 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 ? 

sure

> 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.

there is only single ASLA flex-algo delay metric advertisement per link, 
similar to only single RSVP-TE delay metric per link.

Advertisement is done per application type, flex-algo being one of them, 
not per each instance of the application (e.g. flex-algo number).

> 
> 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."

I don't see it. I see one talking about metric, the other one about the 
calculation type.

thanks,
Peter

>>> metrics and I know that recent IOS-XR provided similar implementation 
>>> of flex algo based on legacy metrics.
>>>
>>>>
>>>> regards,
>>>> Peter
>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Olivier
>>>>>
>>>>>>> important
>>>>>>>     clarification.
>>>>>>> one
>>>>>>>     more spin is required.
>>>>> As emails may be altered, Orange is not liable for messages that 
>>>>> have been modified, changed or falsified.
>>>>> Thank you.
>>>>>
>>>>
>>>>
>>> --

---

From: [email-masked]
Date: Thu, 20 Aug 2020 09:26:45 -0700

I have reviewed the change in -10 and it seems fine to me.  Objection withdrawn. I support publication.

Tony

> On Aug 17, 2020, at 4:47 PM, [email-masked] wrote:
> 
> 
>

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 25 Aug 2020 15:27:38 +0000

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

[External Email. Be cautious of content]

Peter,

On 20/08/2020 13:58, [email-masked]<mailto:[email-masked]> wrote:
Hi Peter,

Here, it is confusing.

Regards,

Olivier

thanks,
Peter

Regards

Olivier

regards,
Peter

Regards

Olivier

Le 18/08/2020 à 19:02, [email-masked]<mailto:[email-masked]> 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-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>> wrote:

Les,

See RFC 8570 says:

       Type    Description

That's all.

Cheers,
R.

On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>> 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.

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

          an integer value.

          an integer value."

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

       Les

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

    Hi Peter,

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

    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.

    And it also says:

    33      Unidirectional Link Delay RFC8570
<https://tools.ietf.org/html/rfc8570><https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ir2QDxsg$>

    This does not help.

    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-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ivswJmIk$>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ivswJmIk$>
--
Orange logo <http://www.orange.com><https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>

Olivier Dugeon

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

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

Olivier Dugeon

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

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

Olivier Dugeon

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

Thank you.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 27 Aug 2020 12:03:54 +0200

Hi Shraddha,

draft-ietf-lsr-flex-algo-00 was published May 15, 2018 (over two years 
ago). 

It clearly stated:

https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00#section-9

"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://tools.ietf.org/html/draft-ietf-isis-te-app-19 and 
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/ 
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:
> *From:[email-masked] <[email-masked]>
> *Sent:* Thursday, August 20, 2020 7:56 PM
> *To:* Peter Psenak <[email-masked]>; [email-masked]; Robert Raszuk 
> <[email-masked]>
> [email-masked]; Les Ginsberg (ginsberg) 
> <ginsberg=[email-masked]>; [email-masked]; [email-masked]; 
> Acee Lindem (acee) <[email-masked]>
> *[External Email. Be cautious of content]*
> 
> Peter,
> 
>     On 20/08/2020 13:58, [email-masked]
>     <mailto:[email-masked]> wrote:
> 
>         Hi Peter,
> 
>                 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.
> 
>             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
>             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.
> 
> 
>         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.
> 
>         In fact, in section 17.1.2, you mention only reference to RFC
>         8570 & RFC7471 for the IANA definition which is fine for me.
> 
> 
>         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.
> 
> 
>         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
> 
>                     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-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         That means that is someone implementing it reads
>                         text in this draft literally (meaning Minimum
>                         value of Unidirectional Link Delay) it may pick
>                         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=[email-masked]
>                         <mailto:ginsberg=[email-masked]>
>                         <mailto:[email-masked]>
>                              “Min Delay:  This 24-bit field carries the
>                         minimum measured link
>                              delay
> 
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]> <mailto:[email-masked]>
>                              *To:* Peter Psenak (ppsenak)
>                         <[email-masked] <mailto:[email-masked]>
>                              *Cc:* [email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]> <mailto:[email-masked]>;
>                         [email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]>; Christian Hopps
>                         <[email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                         <[email-masked] <mailto:[email-masked]>
>                         <mailto:[email-masked]>
>                                                   Encoding
>                         <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8570__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ir2QDxsg$>
> 
> 
>                              This does not help.
> 
> 
> 
>                              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
> 
>                             
>                         <mailto:[email-masked]> <mailto:[email-masked]>
>                         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ivswJmIk$>
> 
> 
> 
> 
>                     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ivswJmIk$>
> 
> 
>                 -- 
>                 <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
> 
> 
>                 Olivier Dugeon
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked]>
> 
>                 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,
>                 This message and its attachments may contain
>                 confidential or privileged information that may be
>                 protected by law;
>                 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.
> 
>         -- 
>         <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
> 
> 
>         Olivier Dugeon
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>
> 
>         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
>         If you have received this email in error, please notify the
>         sender and delete this message and its attachments.
> Orange logo 
> <https://urldefense.com/v3/__http:/www.orange.com__;!!NEt6yMaO-gk!WKuLWanfqtEwcGfdMcPi6zO93gLNz6GLtiLn6c7mmIPhPYuTAufXgyh1ipzYP8Zr$>
> 
> *Olivier Dugeon
> *Orange Expert, Future Networks
> Open Source Referent