Subject: [Lsr] [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 6 Aug 2020 16:31:24 +0000

Hi Authors, All,

My understanding is that for new LSR applications we should select either "ASLA encoding" or select "legacy encoding" for all Link attributes.
Not a mixture of both. There is a clear long term technology benefit of using all ASLA encoding.

In draft-ietf-lsr-flex-algo-08 "Section 11: Advertisement of Link Attributes for Flex-Algorithm" we find that use of ASLA is mandated

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

This is a 'normative' instruction that link attributes MUST use ASLA encoding.
Hence link attributes like (e)ag, te-metric and delay MUST be ASLA encoded.

Is that correct understanding?

If yes, it is odd that some attributes are new ASLA and some other are non-future proof 'LEGACY' encodings

  *   Example#1: section 5.1 "ISIS Flexible Algorithm Definition Sub-TLV" and section 5.2 "OSPF Flexible Algorithm Definition TLV" point towards legacy encodings RFC7810 and RFC5305 (idnit RFC7810 is obsoleted by RFC8570).
  *   Example#2: section 5.2 "OSPF Flexible Algorithm Definition TLV" the normative references are missing

Sections 5.1 and 5.2 should update the link attribute encoding references to reflect ASLA encoding as specified in section 11.
The text referencing legacy encodings should be removed

G/

---

From: Peter Psenak <[email-masked]>
Date: Thu, 6 Aug 2020 18:37:42 +0200

Hi Gunter,

On 06/08/2020 18:31, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Authors, All,
> 
> My understanding is that for new LSR applications we should select 
> either “ASLA encoding” or select “legacy encoding” for all Link attributes.
> 
> In draft-ietf-lsr-flex-algo-08 “Section 11: Advertisement of Link 
> Attributes for Flex-Algorithm” we find that use of ASLA is mandated
> 
> “
> 
> “
> This is a ‘normative’ instruction that link attributes MUST use ASLA 
> encoding.
> 

yes, for any link attributes used for flex-algo.

> 
> If yes, it is odd that some attributes are new ASLA and some other are 
> non-future proof ‘LEGACY’ encodings
> 
>   * Example#1: section 5.1 “ISIS Flexible Algorithm Definition Sub-TLV”
>     and section 5.2 “OSPF Flexible Algorithm Definition TLV” point
>     towards legacy encodings RFC7810 and RFC5305 (idnit RFC7810 is
>     obsoleted by RFC8570).
>   * Example#2: section 5.2 “OSPF Flexible Algorithm Definition TLV” the
>     normative references are missing

ASLA is link-attributes related (Application Specific Link Attributes).

ASLA can only be used to encode link attributes. FAD is not a link 
attribute, so it can not use ASLA.

thanks,
Peter

> 
> Sections 5.1 and 5.2 should update the link attribute encoding 
> references to reflect ASLA encoding as specified in section 11.
>

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 6 Aug 2020 17:11:09 +0000

Thanks for the clarification and fast answer.

Indeed FAD does not encode any attributes. 
That was not the point I was trying to make.

. The existing description in section 5.1 indicate that legacy encoding (RFC7810 and RFC5305) is used for link attributes. That is not correct based upon section 11. To avoid ambiguity can an explicit reference be added for [I-D.ietf-isis-te-app]?
. Similar for section 5.2 where a reference to RFC7471 and RFC3630 should be added together with explicit reference to [I-D.ietf-ospf-te-link-attr-reuse].

Explicit reference to ASLA encodings in section 5.1 and 5.2 will avoid confusion and avoid legacy link attribute encodings (rfc7810/5305/7471/3630) for flex-algo.

Could in section 11 be explicit reference to (e)ag, te-metric and delay link attributes MUST be encoded using ASLA..

G/

________________________________________
From: Peter Psenak <[email-masked]>
Sent: Thursday, August 6, 2020 6:37:42 PM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [draft-ietf-lsr-flex-algo-08] Clarification on ASLA usage for flex-algo 
 
Hi Gunter,

On 06/08/2020 18:31, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> either "ASLA encoding" or select "legacy encoding" for all Link attributes.
> 
> In draft-ietf-lsr-flex-algo-08 "Section 11: Advertisement of Link 
> Attributes for Flex-Algorithm" we find that use of ASLA is mandated
> 
> "
> 

> non-future proof 'LEGACY' encodings
> 
>   * Example#1: section 5.1 "ISIS Flexible Algorithm Definition Sub-TLV"
>     and section 5.2 "OSPF Flexible Algorithm Definition TLV" point

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Fri, 7 Aug 2020 11:15:52 +0200

Hi Gunter,

> . The existing description in section 5.1 indicate that legacy encoding (RFC7810 and RFC5305) is used for link attributes. That is not correct based upon section 11. To avoid ambiguity can an expli…

well, section 5.1. is correct. The Min Unidirectional Link Delay and TE 
Default metric respectively were defined in RFC7810 and RFC5305. The 
fact that we advertise them in ASLA does not change their origin.

> . Similar for section 5.2 where a reference to RFC7471 and RFC3630 should be added together with explicit reference to [I-D.ietf-ospf-te-link-attr-reuse].

I'm not seeing RFC7471 and RFC3630 being reference anywhere in the draft.

> Explicit reference to ASLA encodings in section 5.1 and 5.2 will avoid confusion and avoid legacy link attribute encodings (rfc7810/5305/7471/3630) for flex-algo.

I really do not see any relevance of FAD and ASLA. Linking these 
together will be wrong.

> Could in section 11 be explicit reference to (e)ag, te-metric and delay link attributes MUST be encoded using ASLA..

Section 11 already says:

I'm not sure what else can we say. Listing the ones we use today wold be 
dangerous, because we may define additional ones later and we want the 
ASLA to be mandatory for all of them.

thanks,
Peter

---

From: [email-masked]
Date: Fri, 7 Aug 2020 08:30:08 -0700

Peter,

> well, section 5.1. is correct. The Min Unidirectional Link Delay and TE Default metric respectively were defined in RFC7810 and RFC5305. The fact that we advertise them in ASLA does not change their origin.

Could we please get a clarification in section 5.1 then?  The references there to 7810 and 5305 without any qualification strongly suggest that the encoding from those RFCs should be used.

> I'm not sure what else can we say. Listing the ones we use today wold be dangerous, because we may define additional ones later and we want the ASLA to be mandatory for all of them.

You could add a sentence that says:

	In particular, the Min Unidirectional Link Delay, TE Default Metric, Administrative Group, Extended Administrative Group, Shared Risk Link Group Value TLVs are all to be encoded iin the ASLA advertisements for use with FlexAlgo.

Please add any I missed.

Regards,
Tony

---

From: Sarah Chen <[email-masked]>
Date: Fri, 7 Aug 2020 16:33:04 -0700

Hi, Peter,

The flex-algo draft mentions "Min Unidirectional Link Delay as defined in [
RFC7810 <https://tools.ietf.org/html/rfc7810>]". When reading RFC7810, I
found two Sub-TLVs:

4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max Unidirectional Link
Delay Sub-TLV

Could you please clarify which one should be used? If "Min/Max
Unidirectional Link Delay Sub-TLV" is used, will the max delay carried in
the subTLV be ignored?

Thanks,
Sarah

On Fri, Aug 7, 2020 at 8:30 AM <[email-masked]> wrote:

>
> Peter,
>
>
> >> . The existing description in section 5.1 indicate that legacy encoding
> (RFC7810 and RFC5305) is used for link attributes. That is not correct
> based upon section 11. To avoid ambiguity can an explicit reference be
> added for [I-D.ietf-isis-te-app]?
> >
> >
> Default metric respectively were defined in RFC7810 and RFC5305. The fact
> that we advertise them in ASLA does not change their origin.
>
>
> Could we please get a clarification in section 5.1 then?  The references
> there to 7810 and 5305 without any qualification strongly suggest that the
> encoding from those RFCs should be used.
>
>
> >> Could in section 11 be explicit reference to (e)ag, te-metric and delay
> link attributes MUST be encoded using ASLA..
> >
> > Section 11 already says:
> >
> dangerous, because we may define additional ones later and we want the ASLA
> to be mandatory for all of them.
>
>
>         In particular, the Min Unidirectional Link Delay, TE Default
> Metric, Administrative Group, Extended Administrative Group, Shared Risk
> Link Group Value TLVs are all to be encoded iin the ASLA advertisements for
> use with FlexAlgo.
>
> Please add any I missed.
>
> Regards,
> Tony
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 10 Aug 2020 10:27:43 +0200

Hi Sarah,

On 08/08/2020 01:33, Sarah Chen wrote:
> Hi, Peter,
> 
> The flex-algo draft mentions "Min Unidirectional Link Delay as defined 
> in [RFC7810 <https://tools.ietf.org/html/rfc7810>]". When reading 
> RFC7810, I found two Sub-TLVs:
> 
> Unidirectional Link Delay Sub-TLV" is used, will the max delay carried 
> in the subTLV be ignored?

flex-algo as defined in the draft uses "Min Unidirectional Link Delay", 
which is advertised in the "Min/Max Unidirectional Link Delay Sub-TLV".

The fact that the "Min/Max Unidirectional Link Delay Sub-TLV" carries 
some other data (e.g. Max delay) is orthogonal to the flex-algo usage.

thanks,
Peter

> 
> Thanks,
> Sarah
> 
> On Fri, Aug 7, 2020 at 8:30 AM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     Peter,
> 
> 
>      >> . The existing description in section 5.1 indicate that legacy
>     encoding (RFC7810 and RFC5305) is used for link attributes. That is
>     not correct based upon section 11. To avoid ambiguity can an
>     explicit reference be added for [I-D.ietf-isis-te-app]?
>      >
>      >
>      > well, section 5.1. is correct. The Min Unidirectional Link Delay
>     and TE Default metric respectively were defined in RFC7810 and
>     RFC5305. The fact that we advertise them in ASLA does not change
>     their origin.
> 
> 
>     Could we please get a clarification in section 5.1 then?  The
>     references there to 7810 and 5305 without any qualification strongly
>     suggest that the encoding from those RFCs should be used.
> 
> 
>      >> Could in section 11 be explicit reference to (e)ag, te-metric
>     and delay link attributes MUST be encoded using ASLA..
>      >
>      > Section 11 already says:
>      >
>      > I'm not sure what else can we say. Listing the ones we use today
>     wold be dangerous, because we may define additional ones later and
>     we want the ASLA to be mandatory for all of them.
> 
> 
>              In particular, the Min Unidirectional Link Delay, TE
>     Default Metric, Administrative Group, Extended Administrative Group,
>     Shared Risk Link Group Value TLVs are all to be encoded iin the ASLA
>     advertisements for use with FlexAlgo.
> 
>     Please add any I missed.
> 
>     Regards,
>     Tony
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 10 Aug 2020 10:52:13 +0200

Tony,

ok, seems like Gunter and you share the same concerns. Will clarify the 
two points discussed.

thanks,
Peter

---

From: [email-masked]
Date: Mon, 10 Aug 2020 07:21:34 -0700

Hi Peter,

>> The flex-algo draft mentions "Min Unidirectional Link Delay as defined in [RFC7810 <https://tools.ietf.org/html/rfc7810 <https://tools.ietf.org/html/rfc7810>>]". When reading RFC7810, I found two Sub-TLVs:
>> 4.1. Unidirectional Link Delay Sub-TLV 4.2. Min/Max Unidirectional Link Delay Sub-TLV
>> Could you please clarify which one should be used? If "Min/Max Unidirectional Link Delay Sub-TLV" is used, will the max delay carried in the subTLV be ignored?
> 
> flex-algo as defined in the draft uses "Min Unidirectional Link Delay", which is advertised in the "Min/Max Unidirectional Link Delay Sub-TLV".
> 
> The fact that the "Min/Max Unidirectional Link Delay Sub-TLV" carries some other data (e.g. Max delay) is orthogonal to the flex-algo usage.

Could we please clarify this by adding a reference to the specific section?

Thanks,
Tony

---

From: Peter Psenak <[email-masked]>
Date: Mon, 10 Aug 2020 17:56:15 +0200

Hi Tony,

On 10/08/2020 16:21, [email-masked] wrote:
> 
> Hi Peter,
> 
> 
>>> The flex-algo draft mentions "Min Unidirectional Link Delay as 
>>> defined in [RFC7810 <https://tools.ietf.org/html/rfc7810>]". When 
>>> reading RFC7810, I found two Sub-TLVs:
>>> Unidirectional Link Delay Sub-TLV" is used, will the max delay 
>>> carried in the subTLV be ignored?
>>
>> flex-algo as defined in the draft uses "Min Unidirectional Link 
>> Delay", which is advertised in the "Min/Max Unidirectional Link Delay 
>> Sub-TLV".
>>

which specific section do you have in mind?

thanks,
Peter

---

From: Sarah Chen <[email-masked]>
Date: Mon, 10 Aug 2020 09:51:25 -0700

Thank you, Peter, for the clarification.

It would be nice to add a reference to the section number Section 4.2
<https://tools.ietf.org/html/rfc7810#section-4.2>.

Thanks,
Sarah

---

From: [email-masked]
Date: Mon, 10 Aug 2020 09:00:06 -0700

Hi Peter,

>>>> The flex-algo draft mentions "Min Unidirectional Link Delay as defined in [RFC7810 <https://tools.ietf.org/html/rfc7810>]". When reading RFC7810, I found two Sub-TLVs:

In the flex algo draft, in section 5.1, you current have the text:

	1: Min Unidirectional Link Delay as defined in [RFC7810 <https://tools.ietf.org/html/rfc7810>].

Could you please change that to:

	1: Min Unidirectional Link Delay as defined in [RFC7810 <https://tools.ietf.org/html/rfc7810>] Section 4.2.

Thanks,
Tony

---

From: Peter Psenak <[email-masked]>
Date: Wed, 12 Aug 2020 16:39:20 +0200

Hi Tony, Sarah,

On 10/08/2020 18:00, [email-masked] wrote:
>>>> Delay", which is advertised in the "Min/Max Unidirectional Link 
>>>> Delay Sub-TLV".
>>>>
>>>> The fact that the "Min/Max Unidirectional Link Delay Sub-TLV" 
>>>> carries some other data (e.g. Max delay) is orthogonal to the 
>>>> flex-algo usage.

I'm going to change the reference in section 5.1 to I-D.ietf-isis-te-app 
to address the other concern that Gunter and you expressed.

I-D.draft-ietf-isis-te-app references RFC8570 for Min/Max Unidirectional 
Link Delay Sub-TLV format, so we do not need to reference the RFC8570 
here directly.

thanks,
Peter