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

[Peter Psenak <[e-mail]>]

Hi Shraddha,

On 19/07/2021 20:04, Shraddha Hegde wrote:
> Hi All,
> 
> Generic metric was allowed to be advertised in TLV 22/ ELO LSA
> as well as ASLA TLV before the draft was called for adoption.
> During the recent WG adoption review, it was pointed out that
> ASLA architecture does not allow an attribute to be advertised
> in both application-specific and application-independent manner.
> 
> As a result of this Generic metric has been made an
> application-independent attribute in the latest version.
> The reasons are below
> 
> 1.Generic metric is required to be advertised in an application-independent manner
> that is metric-type 128 is advertised for a link and any application
> like flex-algo, SR-TE, RSVP LFA can make use of it.
> Metric has scope outside of an IGP domain. It gets advertised
> in BGP-LU and gets accumulated across domains.
> There are many usecases that will benefit from advertising generic-metric
> in an application-independent manner.
> 
> 2.The recent case of te-metric usecase that I came across
> where ASLA was being used, really wanted to
> use a different metric-type for flex-algo and not really
> different values for same metric type.
> (Peter, coincidently we may be talking of the same recent
> usecase which you claimed to be using ASLA)
> 
> 3.Advertising generic metric in an application independent manner in legacy TLV 22 and ELO LSA
> does not violate RFC 8919/8920. Application-independent attributes are not expected to use RFC 8919/8920
> mechanisms. Generic metric is like igp cost. IGP-cost is never advertised in ASLA but it gets used in flex-algo
> and generic-metric is being modeled based on igp-cost.

IGP cost is part of the fixed portion of the link advertisement in ISIS, 
it's not a link attribute as such. I have no problem if you have a valid 
use case for which you want to advertise the new generic metric in an 
app independent way. But for flex-algo, or any new application, you MUST 
advertise it in ASLA.

Also having the app specific advertisement for metric 128 adds value 
IMHO. So instead of advertising new metric types, you advertise 
different values of the same type per app. Provides more flexibility.

> As currently written, this document is compliant to every RFC and draft that has
> been out there and not violating any of them.
> 
> 4.Generic metric is very flexible. It allows for finest granularity of
> metric advertisement.
> Usecase:
> Lets say flex-algo 128 wants to use metric-type 128 and flex-algo 129
> wants to use metric-type 129. An year later operator decides to deploy
> SR-TE with red LSPs using metric-type 128 and Blue LSPs using metric-type 129.
>   
> Using generic metric in application-independent manner:
> 1.configure metric-type 128 and 129 and value pair on each link
> 2. set flex-algo 128 FAD to use metric-type 128 and flex-algo FAD 129 to use metric-type 129
> 3. An year later configure Red LSPs to use metric-type 128 and Blue LSPs to use metric-type 129
> 
> Using generic metric with ASLA:
> 1. Define user defined bit-masks for flex-algo 128 and flex-algo 129 and configure on every router

there is no need to do any per algo bit mask assignments. You simply 
advertise metric 128 and metric 129 in ASLA with felx-algo bit set.


> 2. configure metric-type 128 and 129 on every link
> 3. An year later, define user defined bit masks  for SR-TE Red LSPs and SR-TE blue LSPs
> 4. Configure the bit masks on all head-end routers

again no need to do (3) and (4). All you need to do is to add the SR-TE 
bit to the ASLA advertisement that you are already doing for flex-algo.

> 5. Associate the new bit masks with the metric-types on every router on every link.

no need to do that.

thanks,
Peter


> 
> The most common cases look operationally very complex with ASLA while they look very
> simple operationally with generic-metric being advertised in an application-independent
> manner. It looks reasonable approach to allow the option of application-independent
> advertisements for operators who are looking to simplify operations.
> 
>   
> In order to decide  how the generic-metric should be advertised, it would
> be good to get input from the WG on below point.
>   Do you have usecases in mind that you would like to deploy that cannot be solved
> with advertising generic-metric in an application-independent manner?
> 
> 
> Looking forward to more discussions during LSR WG meeting.
> 
> 
> Rgds
> Shraddha
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Sunday, July 18, 2021 2:11 AM
> To: ppsenak=[e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re:[Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Dear All,
> I concur with the arguments presented by Les and Peter. Perhaps the Editors of the WG draft will update the document accordingly.
> 
> Regards,
> Greg Mirsky
> Sr. Standardization Expert
> 预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
> E: [e-mail]
> www.zte.com.cn
> ------------------Original Mail------------------
> Sender: PeterPsenak
> To: Les Ginsberg (ginsberg);[e-mail];[e-mail];
> Date: 2021/07/14 01:40
> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
> Hi,
> I'm the co-author of this draft and I have tried to convince the rest of the co-authors that encoding the new Generic Metric sub-TLV only as a application independent value is wrong. Unfortunately, my efforts have failed. As a result, although unwillingly, I have to express my opinions here and let the WG decide.
> 1) The usage of the Generic Metric sub-TLV is likely going to be associated with the applications, Flex-algo being the first one. Generic Metric sub-TLV can not be used by IGP's native calculation. So having Generic Metric being encoded only in legacy TLV does not make much sense.
> 2) TE-metric is defined as application specific attribute by RFC 8919/8920 and can be advertised in ASLA. The application specific value advertisement of TE-metric has been already proved in the field.
> Generic Metric is semantically very similar to TE-metric, so I see no reason why application specific encoding should not be supported.
> 3) Flex-algo specification mandates the usage of the ASLA attributes and all of the attributes that we are using for flex-algo so far are encoded in ALSA. Encoding the Generic Metric outside of ALSA violates that principle.
> 4) RFC 8919/8920 violation brought by Les below.
> thanks,
> Peter
> On 13/07/2021 17:39, Les Ginsberg (ginsberg) wrote:
>> Draft authors -
>>
>> I note that the new version has altered the advertisement of the Generic Metric sub-TLV so that it is no longer supported in the ASLA sub-TLV.
>> This is in direct violation of RFC 8919/8920.
>>
>> For example, https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8919.html*section-6.1__;Iw!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx4pA8WB0$  states:
>>
>> "New applications that future documents define to make use of the advertisements defined in this document MUST NOT make use of legacy advertisements."
>>
>> Flex-algo is a "new application" in the scope of these RFCs.
>>
>> Please correct this error.
>>
>> Thanx.
>>
>>      Les
>>
>>
>>> -----Original Message-----
>>> From: Lsr  On Behalf Of [e-mail]
>>> Sent: Monday, July 12, 2021 9:12 AM
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>>>
>>>
>>> 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-01.txt
>>>      Pages           : 27
>>>      Date            : 2021-07-12
>>>
>>> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
>>> tf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2Ku
>>> E9gbrUscAHAlbWXMsiRouKOFbEWkxyFWi9bo$
>>>
>>> There is also an htmlized version available at:
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
>>> ft-ietf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd
>>> 2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkxwbtJYtY$
>>>
>>> A diff from the previous version is available at:
>>> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-i
>>> etf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo
>>> 2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_rX175v$
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!N
>>> Et6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx6
>>> GQqw0z$
>>>
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> [e-mail]
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>>> __;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOF
>>> bEWkx_ne0I9C$
>>
>>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_ne0I9C$
> 
>