[Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Flexible Algorithms: Bandwidth, Delay, Metrics and 
Constraints
Authors : Shraddha Hegde
  William Britto A J
  Rajesh Shetty
  Bruno Decraene
  Peter Psenak
  Tony Li
Filename: draft-ietf-lsr-flex-algo-bw-con-00.txt
Pages   : 27
Date: 2021-05-30

Abstract:
   Many networks configure the link metric relative to the link
   capacity.  High bandwidth traffic gets routed as per the link
   capacity.  Flexible algorithms provides mechanisms to create
   constraint based paths in IGP.  This draft documents a generic metric
   type and set of bandwidth related constraints to be used in Flexible
   Algorithms.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[peng.shaofu]

Hi Jie,

Please see inline [PSF]


--原始邮件--
发件人：Dongjie(Jimmy)
收件人：彭少富10053815;
抄送人：lsr@ietf.org;cho...@chopps.org;
日 期 ：2021年05月31日 17:35
主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID 
Advertisement"
Hi PSF,
Please see inline:
> -Original Message-
> From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> Sent: Monday, May 31, 2021 9:41 AM
> To: Dongjie (Jimmy) 
> Cc: cho...@chopps.org; lsr@ietf.org
> Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
>
> Hi Jie,
>
> Thanks.
> Again, in this document we describe local behavior per algorithm thanks to
> adj-sid per algo, but not describe any resource reservatoin extensions to
> flex-algo. the later can be discussed in another thread.
Then it is reasonable to remove the text about use case 1, 2 and the operations 
in section 5 which are related to per flex-algo resource reservation or traffic 
treatment over the same link, as you said they are local behaviors thus do not 
require  interoperability.

[PSF] I'm afraid we can't come to the conclusion that some description of local 
behavior that is  beneficial to understand the integrity of the whole scheme 
must not be contained in the document. It does not violate any iron law. The 
significance of their existence is to show that the local behavior related to 
the algorithm is possible, so the use of flex algo alone can be competent for 
some scenarios (e.g, network slicing).  I think the section of use case is 
open, and ajdacency backup use case is not the only case.
> IMO the local behavior can be any local policies, such as local repair path, 
> local
> queue, local priority for entry installation, etc. Adj-sid per algo provides 
> the
> basis for these local behavior. It is useful to describe how adj-sid per algo 
> can
> satisfy these usecases, also to facilitate readers to understand its use.
Local repair is different from the other cases you mentioned. Local repair 
results in the change of the path and the SID list, which is visible to the 
network.

[PSF] I don't believe local repair path is visible to other nodes of the 
network. If you means that show the state of local repair path, you can also 
show the state of local queue. 

 In addition, the computation of local repair path is based on the Flex-Algo 
constraints defined by the FAD. In contrast, the local queue or priority 
information is not reflected in the FAD.

[PSF] Agree, you can also find that local queue is different with local 
priority. This difference is not our focus, we focus on the possibility of 
local policy per algo on nodes.
Before introducing the local queue and priority use cases to this draft, it is 
necessary to understand whether such local information need to be included in 
the FAD or not, and propose relevant Flex-Algo extensions for it, otherwise IMO 
they are local information and behaviors which are NOT related to Flex-Algo.

[PSF] See the first untenable conclusion.
Best regards,
Jie
> You are very concerned about the extension of resource reservation. Although
> it is not related to this document and should be discussed in another thread, 
> I
> will try to answer it in your previous email.
>
> Regards,
> PSF
>
>
>
>
> --原始邮件--
> 发件人：Dongjie(Jimmy)
> 收件人：彭少富10053815;
> 抄送人：cho...@chopps.org;lsr@ietf.org;
> 日 期 ：2021年05月28日 14:24
> 主 题 ：RE: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related
> IGP-Adjacency SID Advertisement"
> Hi PSF,
> Thanks for your pointer to another document which defines the encodings of
> per-Algo TE link attributes.
> But my comments are related to the text in section 3 and 5 of this document,
> which describes new use cases and operation of Flex-Algo with per Flex-Algo
> resource reservation or per Flex-Algo QoS policy on the same link. These 
> require
> extensions to the function of Flex-Algo, which IMO needs to be discussed and
> compared with other alternative mechanisms. And as you indicated, there are
> related encoding extensions proposed in other document, thus it may not be
> just a local behavior.
> So could you reply to the comments in my previous mail?
> Best regards,
> Jie
> > -Original Message-
> > From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> > Sent: Friday, May 28, 2021 12:00 PM
> > To: Dongjie (Jimmy) 
> > Cc: cho...@chopps.org; lsr@ietf.org
> > Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> >
> > Hi Jie,
> >
> > Thanks for your comments.
> >
> > In this document, there are not any extensions to describe resource
> > reservation per algo. Are you aiming at another draft
> > (https://datatracker.ietf.org/doc/draft-cp-lsr-fa-aware-te/) ?  Please
> > find out what you are talking about first.
> > Adj-SID per algo can distinguish traffic behavior in local. You are
> > welcome to add more usecases based on section 3.
> >
> > Regards,
> > PSF
> 

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Hi Shraddha,

My point is that Generic Metric is not a legacy advertisement and it is 
application specific. Therefore, the place to advertise it is within the ASLA 
Sub-TLV - this applies to both ISIS and OSPF.

The references in RFC8919 and RFC8920 are about legacy advertisements and do 
not apply in this discussion.

Thanks,
Ketan

From: Shraddha Hegde 
Sent: 31 May 2021 14:20
To: Ketan Talaulikar (ketant) ; Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Ketan,

Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Monday, May 31, 2021 1:14 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

When you refer to "a single TE application", it is not clear which one you are 
referring to : RSVP-TE or SR Policy?
 It could be either of them

I believe, for ISIS, you are referring to this specific section of RFC8919 : 
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1

There is no ambiguity here. This section is about use of "legacy" 
advertisement. The Generic Metric is a new TLV and hence cannot be considered 
as "legacy" by any interpretation of the word.
 For ISIS, I hope you agree that generic metric sub-TLV is allowed to 
get advertised under TLV 22.

Coming to OSPF, the considerations are similar. Additionally we also have to 
deal with different LSA types here.

Please refer to 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.1
 for the equivalent discussion for OSPF. This section is about "legacy" 
advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you 
were referring to was RSVP-TE, then there is also additional guidance provided 
here : 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4


Please clarify where RFC8920 describes advertisement of application-specific 
attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.
 From what I understand, you agree that the generic metric sub-TLV 
should be allowed in TE Opaque LSA.
You have concerns only on it being allowed in Extended Link opaque LSA top 
level Extended Link TLV right?



Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi 

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Dongjie (Jimmy)]

Hi PSF, 

Please see inline:

> -Original Message-
> From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> Sent: Monday, May 31, 2021 9:41 AM
> To: Dongjie (Jimmy) 
> Cc: cho...@chopps.org; lsr@ietf.org
> Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> Hi Jie,
> 
> Thanks.
> Again, in this document we describe local behavior per algorithm thanks to
> adj-sid per algo, but not describe any resource reservatoin extensions to
> flex-algo. the later can be discussed in another thread.

Then it is reasonable to remove the text about use case 1, 2 and the operations 
in section 5 which are related to per flex-algo resource reservation or traffic 
treatment over the same link, as you said they are local behaviors thus do not 
require  interoperability.

> IMO the local behavior can be any local policies, such as local repair path, 
> local
> queue, local priority for entry installation, etc. Adj-sid per algo provides 
> the
> basis for these local behavior. It is useful to describe how adj-sid per algo 
> can
> satisfy these usecases, also to facilitate readers to understand its use.

Local repair is different from the other cases you mentioned. Local repair 
results in the change of the path and the SID list, which is visible to the 
network. In addition, the computation of local repair path is based on the 
Flex-Algo constraints defined by the FAD. In contrast, the local queue or 
priority information is not reflected in the FAD. 

Before introducing the local queue and priority use cases to this draft, it is 
necessary to understand whether such local information need to be included in 
the FAD or not, and propose relevant Flex-Algo extensions for it, otherwise IMO 
they are local information and behaviors which are NOT related to Flex-Algo.

Best regards,
Jie

> You are very concerned about the extension of resource reservation. Although
> it is not related to this document and should be discussed in another thread, 
> I
> will try to answer it in your previous email.
> 
> Regards,
> PSF
> 
> 
> 
> 
> --原始邮件--
> 发件人：Dongjie(Jimmy)
> 收件人：彭少富10053815;
> 抄送人：cho...@chopps.org;lsr@ietf.org;
> 日 期 ：2021年05月28日 14:24
> 主 题 ：RE: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related
> IGP-Adjacency SID Advertisement"
> Hi PSF,
> Thanks for your pointer to another document which defines the encodings of
> per-Algo TE link attributes.
> But my comments are related to the text in section 3 and 5 of this document,
> which describes new use cases and operation of Flex-Algo with per Flex-Algo
> resource reservation or per Flex-Algo QoS policy on the same link. These 
> require
> extensions to the function of Flex-Algo, which IMO needs to be discussed and
> compared with other alternative mechanisms. And as you indicated, there are
> related encoding extensions proposed in other document, thus it may not be
> just a local behavior.
> So could you reply to the comments in my previous mail?
> Best regards,
> Jie
> > -Original Message-
> > From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> > Sent: Friday, May 28, 2021 12:00 PM
> > To: Dongjie (Jimmy) 
> > Cc: cho...@chopps.org; lsr@ietf.org
> > Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> >
> > Hi Jie,
> >
> > Thanks for your comments.
> >
> > In this document, there are not any extensions to describe resource
> > reservation per algo. Are you aiming at another draft
> > (https://datatracker.ietf.org/doc/draft-cp-lsr-fa-aware-te/) ?  Please
> > find out what you are talking about first.
> > Adj-SID per algo can distinguish traffic behavior in local. You are
> > welcome to add more usecases based on section 3.
> >
> > Regards,
> > PSF
> >
> >
> > --原始邮件--
> > 发件人：Dongjie(Jimmy)
> > 收件人：Christian Hopps;lsr@ietf.org;
> > 日 期 ：2021年05月28日 11:40
> > 主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> > Hi,
> > I don't support the adoption of this document.
> > It seems this document aims to introduce per Flex-Algo Adj-SID to
> > SR-MPLS, its typical use case is to provide protection path with
> > Flex-Algo constraints for Adj-SID of a particular Flex-Algo, which is 
> > described
> in the case 3 of section 3.
> > However, section 3 and section 5 shows that it also aims to introduce
> > further changes to the usage and operation of Flex-Algo, which is to
> > provide resource reservation based on Flex-Algo. IMO these changes to
> > Flex-Algo deserves further discussion and is not only related to the per
> Flex-Algo Adj-SID extension.
> > Here are some comments about this change to Flex-Algo:
> > 1. Flex-Algo defines the constraints for path computation in a
> > distributed manner, it is not for resource reservation.
> > 2. Reserving resources for each Flex-Algo on a link does not make
> > sense. The correlation between Flex-Algo 

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde]

Hi Ketan,

Pls see inline..



Juniper Business Use Only
From: Ketan Talaulikar (ketant) 
Sent: Monday, May 31, 2021 1:14 PM
To: Shraddha Hegde ; Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

When you refer to "a single TE application", it is not clear which one you are 
referring to : RSVP-TE or SR Policy?
 It could be either of them

I believe, for ISIS, you are referring to this specific section of RFC8919 : 
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1

There is no ambiguity here. This section is about use of "legacy" 
advertisement. The Generic Metric is a new TLV and hence cannot be considered 
as "legacy" by any interpretation of the word.
 For ISIS, I hope you agree that generic metric sub-TLV is allowed to 
get advertised under TLV 22.

Coming to OSPF, the considerations are similar. Additionally we also have to 
deal with different LSA types here.

Please refer to 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.1
 for the equivalent discussion for OSPF. This section is about "legacy" 
advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you 
were referring to was RSVP-TE, then there is also additional guidance provided 
here : 
https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4


Please clarify where RFC8920 describes advertisement of application-specific 
attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.
 From what I understand, you agree that the generic metric sub-TLV 
should be allowed in TE Opaque LSA.
You have concerns only on it being allowed in Extended Link opaque LSA top 
level Extended Link TLV right?



Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for 

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Ketan Talaulikar (ketant)]

Hi Shraddha,

When you refer to "a single TE application", it is not clear which one you are 
referring to : RSVP-TE or SR Policy?

I believe, for ISIS, you are referring to this specific section of RFC8919 : 
https://datatracker.ietf.org/doc/html/rfc8919#section-6.1

There is no ambiguity here. This section is about use of "legacy" 
advertisement. The Generic Metric is a new TLV and hence cannot be considered 
as "legacy" by any interpretation of the word.

Coming to OSPF, the considerations are similar. Additionally we also have to 
deal with different LSA types here.

Please refer to https://datatracker.ietf.org/doc/html/rfc8920#section-12.1 for 
the equivalent discussion for OSPF. This section is about "legacy" 
advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you 
were referring to was RSVP-TE, then there is also additional guidance provided 
here : https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4

Please clarify where RFC8920 describes advertisement of application-specific 
attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.

Thanks,
Ketan

From: Shraddha Hegde 
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) ; Tony Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Ketan,


Networks that deploy a single TE application and already advertising and using 
attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There 
is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the 
protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the 
receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific 
cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Tony Li 
mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

This is a new attribute that we are introducing and we are saying that it has 
application specific semantics. We now have the ASLA mechanics defined in both 
OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA 
introduces ambiguity for which applications can use it - we get into 
complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde mailto:shrad...@juniper.net>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Tony 
Li mailto:tony...@tony.li>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic 
Metric is carried only in the ASLA and this document specifies usage only for 
the FA application. Later this can be also used/extended for other applications 
but still within ASLA. Keeping an option of advertising both outside and within 
the ASLA is problematic - we will need precedence rules and such. I prefer we 
avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA 
(quite correctly) for FlexAlgo application. Peter has confirmed the same. I am 
simply asking to avoid the complications of using Generic Metric in both ASLA 
and outside it. Whatever new "application" we invent to use this generic metric 
type, can use ASLA so that the Generic Metric can be very cleanly shared 
between applications. The encoding allows for using the same value - sharing 
single advertisement across applications or doing a different one 
per-application.
 Generic metric is allowed in ASLA, it is also allowed in all 
traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of 
generic metric.



Juniper Business Use Only
From: Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony