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

[Peter Psenak <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>
>      > Sent: Saturday, July 31, 2021 1:07 AM
>      > To: Shraddha Hegde <[e-mail]
>     <mailto:[e-mail]>>; Robert Raszuk <[e-mail]
>     <mailto:[e-mail]>>; Van De Velde, Gunter (Nokia -
>     BE/Antwerp) <[e-mail]
>     <mailto:[e-mail]>>
>      > Cc: Les Ginsberg (ginsberg) <[e-mail]
>     <mailto:[e-mail]>>; Tony Li <[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:[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] <mailto:[e-mail]>>
>      >> Sent: Friday, July 30, 2021 7:09 PM
>      >> To: Shraddha Hegde <[e-mail]
>     <mailto:[e-mail]>>; Robert Raszuk
>      >> <[e-mail] <mailto:[e-mail]>>; Van De Velde,
>     Gunter (Nokia - BE/Antwerp)
>      >> <[e-mail]
>     <mailto:[e-mail]>>
>      >> Cc: Les Ginsberg (ginsberg) <[e-mail]
>     <mailto:[e-mail]>>; Tony Li
>      >> <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[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]
>     <mailto:[e-mail]>>
>      >>> *Sent:* Friday, July 30, 2021 6:20 PM
>      >>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp)
>      >>> <[e-mail]
>     <mailto:[e-mail]>>
>      >>> *Cc:* Peter Psenak <[e-mail]
>     <mailto:[e-mail]>>; Shraddha Hegde
>      >>> <[e-mail] <mailto:[e-mail]>>; Les
>     Ginsberg (ginsberg) <[e-mail] <mailto:[e-mail]>>;
>      >>> Tony Li <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[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]>
>      >>> <mailto:[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/
>      >>>
>      >>
>      >>
>      >
>      >
>