Robert,
On 18/08/2021 11:39, Robert Raszuk wrote:
Peter,
Is there a definition of IGP "application" in any of the specs ?
To me application in the context of an IGP is defined by method used to
compute a topology as well as links and their metrics which are used to
consistently select the shortest path in the domain. So even if you
happen to use the exact same algorithm (which may already not be the
case) it seems that it is hard to artificially squeeze two orthogonal
topologies serving completely different purposes under a single
flex-algo app umbrella.
you can have up to 128 flex-algo topologies, each using different
constraint. What else do you need?
thanks,
Peter
If you go by the notion of let's push everything to FAD then sorry but
ASLA is not making sense anymore as even without it FAD could
enumerate what link attributes and what links (using affinities) can be
considered for topology computation.
Honestly I am not sure where is the resistance to define more bits for
flex algo in SABM is coming from ....
Thx,
R.
On Wed, Aug 18, 2021 at 9:51 AM Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>> wrote:
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 <ppse...@cisco.com <mailto:ppse...@cisco.com>>
> Sent: Saturday, July 31, 2021 1:07 AM
> To: Shraddha Hegde <shrad...@juniper.net
<mailto:shrad...@juniper.net>>; Robert Raszuk <rob...@raszuk.net
<mailto:rob...@raszuk.net>>; Van De Velde, Gunter (Nokia -
BE/Antwerp) <gunter.van_de_ve...@nokia.com
<mailto:gunter.van_de_ve...@nokia.com>>
> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>; Tony Li <tony...@tony.li
<mailto:tony...@tony.li>>; lsr@ietf.org <mailto:lsr@ietf.org>
> 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 <ppse...@cisco.com <mailto:ppse...@cisco.com>>
>> Sent: Friday, July 30, 2021 7:09 PM
>> To: Shraddha Hegde <shrad...@juniper.net
<mailto:shrad...@juniper.net>>; Robert Raszuk
>> <rob...@raszuk.net <mailto:rob...@raszuk.net>>; Van De Velde,
Gunter (Nokia - BE/Antwerp)
>> <gunter.van_de_ve...@nokia.com
<mailto:gunter.van_de_ve...@nokia.com>>
>> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>; Tony Li
>> <tony...@tony.li <mailto:tony...@tony.li>>; lsr@ietf.org
<mailto:lsr@ietf.org>
>> 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 <rob...@raszuk.net
<mailto:rob...@raszuk.net>>
>>> *Sent:* Friday, July 30, 2021 6:20 PM
>>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp)
>>> <gunter.van_de_ve...@nokia.com
<mailto:gunter.van_de_ve...@nokia.com>>
>>> *Cc:* Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>>; Shraddha Hegde
>>> <shrad...@juniper.net <mailto:shrad...@juniper.net>>; Les
Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com>>;
>>> Tony Li <tony...@tony.li <mailto:tony...@tony.li>>;
lsr@ietf.org <mailto:lsr@ietf.org>
>>> *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) <gunter.van_de_ve...@nokia.com
<mailto:gunter.van_de_ve...@nokia.com>
>>> <mailto:gunter.van_de_ve...@nokia.com
<mailto:gunter.van_de_ve...@nokia.com>>> 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/
>>>
>>
>>
>
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
