Re: [Lsr] Generic metric: application-specific vs application-independent

[Peter Psenak <[e-mail]>]

Shraddha,

On 17/08/2021 20:04, Shraddha Hegde wrote:
> Peter,
> 
>> no, I don't want to use affinities to do that. That's the whole point.
>> ASLA gives you per link per application signaling. No need to use affinities.
> 
> The usecase you are describing to exclude links from an application topology is very straight
> forward and how this is done is defined by applications.
> TE applications have defined a topology filter data model that uses
> link-affinities to Include/exclude links from topology
>   https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-topology-filter-00.
>   In your example if application B is any TE application it would be natural to use link-affinities.
> 
> If application B is LFA, RFC 7916 defines link-coloring and include exclude policies to be used (Refer sec 6.2.3).
> so it cannot use application bits on metric to exclude links.
> 
> If we assume application A and B are both Flex-algos, ASLA

flex-algo is a single application, so A and B does not make sense.

You can define flex-algo X and flex-algo Y and use different FAD to 
exclude/include links as needed, using single set of affinities that are 
advertised for flex-algo application as such.

I still do not see a problem

thanks,
Peter


> natively doesn't support Per flex-algo attribute advertisement
> and it is extremely complex to define user-defined bit masks for Each
> flex-algo and assign the bit masks on the metric on every router.
> Operator could use link-affinities to Exclude links
> from flex-algo topology which is much simpler.
> 
> Rgds
> Shraddha
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Peter Psenak <[e-mail]>
> Sent: Saturday, July 31, 2021 1:07 AM
> To: Shraddha Hegde <[e-mail]>; Robert Raszuk <[e-mail]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <[e-mail]>
> Cc: Les Ginsberg (ginsberg) <[e-mail]>; Tony Li <[e-mail]>; [e-mail]
> Subject: Re: [Lsr] Generic metric: application-specific vs application-independent
> 
> [External Email. Be cautious of content]
> 
> 
> Shraddha,
> 
> On 30/07/2021 18:45, Shraddha Hegde wrote:
>> Peter,
>>
>>> imagine you have an application A and B and a link X. You advertise application independent metric M on that link X >because you want application A to use it.
>>
>>> Application B is also enabled to use the metric M, but you do not want application B to use metric M on the link X >(because you do not want application B to include the link X in its topology). How do you do that without ASLA? The >answer is you can't.
>>
>> This is very straight forward to do without ASLA.
>>    I would define an admin-group and assign that admin group on link X and
>>    exclude that admin-group from Application B.
>>    This is much common way how
>>    operators exclude links from the topology.
> 
> no, I don't want to use affinities to do that. That's the whole point.
> ASLA gives you per link per application signaling. No need to use affinities.
> 
>>
>>    The alternative being proposed with ASLA is much more fragile.
>>    An operator would have to set the bits for application A and Application B
>>    for metric M on every link that he wants to include and reset the
>>    application bit B on links that he wants to exclude for application B.
> 
> sorry, but setting affinities is not any easier, so the above argument is not valid.
> 
> 
> Peter
> 
> 
> 
>>    Imagine what would happen if he missed setting the bit or resetting
>>    the bit on some of the links and how difficult it would be to debug.
>>
>> Rgds
>> Shraddha
>>
>>
>> Juniper Business Use Only
>>
>> -----Original Message-----
>> From: Peter Psenak <[e-mail]>
>> Sent: Friday, July 30, 2021 7:09 PM
>> To: Shraddha Hegde <[e-mail]>; Robert Raszuk
>> <[e-mail]>; Van De Velde, Gunter (Nokia - BE/Antwerp)
>> <[e-mail]>
>> Cc: Les Ginsberg (ginsberg) <[e-mail]>; Tony Li
>> <[e-mail]>; [e-mail]
>> Subject: Re: [Lsr] Generic metric: application-specific vs
>> application-independent
>>
>> [External Email. Be cautious of content]
>>
>>
>> Shraddha,
>>
>>
>> On 30/07/2021 15:22, Shraddha Hegde wrote:
>>> Robert,
>>>
>>>    > Can anyone explain how do I map generic metric to selected
>>> network applications I am to run in the network ?
>>>
>>> Which application uses which metric type is defined by the application.
>>
>> imagine you have an application A and B and a link X. You advertise application independent metric M on that link X because you want application A to use it.
>>
>> Application B is also enabled to use the metric M, but you do not want application B to use metric M on the link X (because you do not want application B to include the link X in its topology). How do you do that without ASLA? The answer is you can't.
>>
>> thanks,
>> Peter
>>
>>>
>>> For example in flex-algo FAD defines which metric-type its going to use.
>>>
>>> In SR-TE, the constraint list specifies which metric-type it is going
>>> to use.
>>>
>>> Rgds
>>>
>>> Shraddha
>>>
>>> Juniper Business Use Only
>>>
>>> *From:* Robert Raszuk <[e-mail]>
>>> *Sent:* Friday, July 30, 2021 6:20 PM
>>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp)
>>> <[e-mail]>
>>> *Cc:* Peter Psenak <[e-mail]>; Shraddha Hegde
>>> <[e-mail]>; Les Ginsberg (ginsberg) <[e-mail]>;
>>> Tony Li <[e-mail]>; [e-mail]
>>> *Subject:* Re: [Lsr] Generic metric: application-specific vs
>>> application-independent
>>>
>>> *[External Email. Be cautious of content]*
>>>
>>> Hey Gunter,
>>>
>>>    > It doesn’t make sense to have Application specific values if a
>>> particular metric is obtained only dynamically,
>>>
>>> It sure does.
>>>
>>> Please notice what ASLA RFCs say up front in the abstract. ASLA is
>>> useful for:
>>>
>>> A) application- specific values for a given attribute
>>>
>>> AND
>>>
>>> B) indication of which applications are using the advertised value
>>> for a given link.
>>>
>>> It does not matter if the value is same or different ... what matters
>>> is automated and consistent indication which of my applications given
>>> new metric applies to.
>>>
>>> I already mentioned this to Ron here:
>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr
>>> /
>>> OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!VVLJCpIMrWixS17PeaBbfOpe
>>> b NPO4JUW4jparIn36jHmhv4_-W2_q_Smwo7oIYgk$
>>> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr
>>> /
>>> OgGLI8yezUDWU-EZePoIj6y6ENk/__;!!NEt6yMaO-gk!Tny8sU7cmjqLAbDVnliN7lck
>>> 7 J4tCBAHr10i3CW2G9oviUWo8b2RTJxCXc0gvWOz$>
>>>
>>> Can anyone explain how do I map generic metric to selected network
>>> applications I am to run in the network ?
>>>
>>> Thx,
>>> Robert.
>>>
>>> On Fri, Jul 30, 2021 at 11:05 AM Van De Velde, Gunter (Nokia -
>>> BE/Antwerp) <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>       A little late in the discussion... (PTO events do happen)
>>>
>>>       a quick opinion on the below discussion on whether Generic metric
>>>       sub-tlv should be encoded on a ASLA or not.
>>>       For me, it depends on how the metric for the corresponding
>>>       metric-type is obtained and if it can be configured (static).
>>>       It doesn’t make sense to have Application specific values if a
>>>       particular metric is obtained only dynamically, for eg, dynamically
>>>       measured delay is going to be same for all applications.
>>>       On the contrary, te-metric can be configured, and we can in
>>>       principle configure different values for different applications.
>>>
>>>       My opinion is that if any of the metric-types in the Generic metric
>>>       sub-tlv can be configured, it should be inside the ASLA.
>>>
>>>       G/
>>>
>>
>>
> 
>