Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[Ketan Talaulikar <[e-mail]>]

Hi Peter,

I would still reiterate the need to clarify the usage of "application"
terminology in the base FlexAlgo spec. We don't need to call it
"data-plane", I was suggesting "forwarding mechanism" or it can be
something else as well.

Just my 2c

Thanks,
Ketan


On Wed, Apr 13, 2022 at 2:35 PM Peter Psenak <[e-mail]> wrote:

> Hi Ketan,
>
> please see inline (##PP4):
>
>
> On 13/04/2022 10:52, Ketan Talaulikar wrote:
> > Hi Peter,
> >
> > I will not press this point further if I am the only one that finds this
> > complexity without any benefit. :-)
> >
> > Please check inline below for some clarifications with KT3.
> >
> >
> > On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi Ketan,
> >
> >
> >     please see inline (##PP3):
> >
> >     On 13/04/2022 06:00, Ketan Talaulikar wrote:
> >      > Hi Peter,
> >      >
> >      > Please check inline below with KT2. I am trimming everything
> >     other than
> >      > the one point of continuing debate.
> >      >
> >      >      >      >
> >      >      >      > 2) The relationship between the algo usage for IP
> >     FlexAlgo
> >      >     and other
> >      >      >      > data planes (e.g. FlexAlgo with SR) is not very
> clear.
> >      >     There arise
> >      >      >      > complications when the algo usage for IP FlexAlgo
> >     overlap
> >      >     with other
> >      >      >      > (say SR) data planes since the FAD is shared but
> >     the node
> >      >      >     participation
> >      >      >      > is not shared. While Sec 9 suggests that we can work
> >      >     through these
> >      >      >      > complications, I question the need for such
> complexity.
> >      >     The FlexAlgo
> >      >      >      > space is large enough to allow it to be shared
> between
> >      >     various data
> >      >      >      > planes without overlap. My suggestion would be to
> >     neither
> >      >     carve out
> >      >      >      > parallel algo spaces within IGPs for various types
> of
> >      >     FlexAlgo data
> >      >      >      > planes nor allow the same algo to be used by both
> >     IP and
> >      >     SR data
> >      >      >     planes.
> >      >      >      > So that we have a single topology computation in
> >     the IGP
> >      >     for a given
> >      >      >      > algo based on its FAD and data plane participation
> and
> >      >     then when it
> >      >      >      > comes to prefix calculation, the results could
> involve
> >      >      >     programming of
> >      >      >      > entries in respective forwarding planes based on the
> >      >     signaling of
> >      >      >     the
> >      >      >      > respective prefix reachabilities. The coverage of
> these
> >      >     aspects in a
> >      >      >      > dedicated section upfront will help.
> >      >      >
> >      >      >     ##PP
> >      >      >     I strongly disagree.
> >      >      >
> >      >      >     FAD is data-pane/app independent. Participation is
> >     data-plane/app
> >      >      >     dependent. Base flex-algo specification is very clear
> >     about
> >      >     that. That
> >      >      >     has advantages and we do not want to modify that part.
> >      >      >
> >      >      >
> >      >      > KT> No issue with this part.
> >      >      >
> >      >      >
> >      >      >     Topology calculation for algo/data-plane needs to take
> >     both
> >      >     FAD and
> >      >      >     participation into account. You need independent
> >     calculation
> >      >     for each
> >      >      >     data-plane/app in the same algo.
> >      >      >
> >      >      >
> >      >      > KT> So, an implementation now needs to potentially support
> >      >     performing
> >      >      > multiple topology computations for each algo. This is a
> >      >     complication for
> >      >      > which I do not see the justification. Why not just pick
> >     different
> >      >      > algorithms for different data planes for those (rare?)
> >      >     deployments where
> >      >      > someone wants multiple data planes?
> >      >
> >      >     ##PP2
> >      >     flex-algo architecture supports multiple apps/data-planes per
> >     algo,
> >      >     with
> >      >     unique participation per app/data-plane. That requires
> >     per-algo/per
> >      >     app/data-plane calculation. What is complicated on it?
> >      >
> >      >
> >      > KT2> This specific and precise statement that you have provided
> >     is not
> >      > covered in either draft-ietf-lsr-flex-algo or this document. For
> >      > starters, this needs to be clarified and covered so that it gets
> the
> >      > attention of any reader during the review. This has implications
> for
> >      > implementations.
> >
> >     ##PP3
> >     sure we can add it explicitly there, but if you read the base
> flex-algo
> >     draft carefully, it is quite clear. I will add that exact statement
> in
> >     the next re-spin of the base spec.
> >
> >
> > KT3> Thanks. I think we may also need to carefully scrub the use of the
> > term "application" since it seems to bring out different interpretations
> > thanks to the "application" in ASLA. It is better if we use the term
> > "application" only in the same semantics as ASLA  - this means that
> > FlexAlgo is a single "application". We can perhaps use the term "traffic
> > flows" or "service flows" as an alternate for "application flows" that
> > are steered over or use a FlexAlgo.  And then when it comes to Node
> > Participation in a FlexAlgo, we could use the term "FlexAlgo Forwarding
> > Mechanism" instead of "Applications' Forwarding for FlexAlgo". Thoughts?
>
> ##PP4
> the term application is used in the base flex-algo spec from day one. It
> was chosen because it was generic enough to describe whatever the
> flex-algo may be used for down the road. We could have used 'data-plane'
> instead, but it could be quite restrictive IMHO.
>
>
> >
> >      >
> >      >
> >      >     If your implementation does not want to support it, fine, but
> the
> >      >     architecture allows it and there is/are implementation(s)
> >     that already
> >      >     support it. This is not defined in this draft, it's defined
> >     in base
> >      >     flex-algo spec.
> >      >
> >      >
> >      > KT2> I am not sure if it is really an option for implementation
> >     once it
> >      > is in the specification. And this is not about "my"
> >     implementation :-).
> >      > So it is not that because some implementations can do (or does)
> >     it that
> >      > it should be in the specification. The determination on whether it
> >      > should be in a specification needs to be based on the tradeoff
> >     between
> >      > requiring multiple computations per algo with the potential
> >     benefit or
> >      > use case that is enabled by it.
> >
> >     ##PP3
> >     again, this is how things have been defined from day one, and for a
> >     good
> >     reason. Requiring per app flex-algo even though I want to use the
> same
> >     metric and constraints for both app would be inefficient.
> >
> >
> > KT3> For my understanding, the only inefficiency that you are referring
> > to with the "separate algo per FlexAlgo forwarding mechanism" is a
> > duplicate FAD advertisement. Am I missing anything else?
>
> ##PP4
> right. But the point is there is nothing that prevents multiple apps
> using the same algo in the architecture itself. And I see no good reason
> for such restriction.
> >
> >
> >      >
> >      >
> >      >
> >      >      >
> >      >      >
> >      >      >     The fact that the same FAD is shareable between all
> >     apps has it
> >      >      >     advantages and use cases - e.g. if the participation
> >     for algo
> >      >     X is the
> >      >      >     same in SR and IP data-planes, one can use SR to
> >     protect IP
> >      >     in that
> >      >      >     algo.
> >      >      >
> >      >      >
> >      >      > KT> Would this protection use case not violate the base
> >     FlexAlgo
> >      >     rule
> >      >      > that the protection has to remain within the specific
> >     topology.
> >      >     If there
> >      >      > is an SR data plane, then why would one want an IP data
> >     plane as
> >      >     well?
> >      >
> >      >     ##PP2
> >      >     if the participation in two app/data-planes is the same for
> >     the algo,
> >      >     the resulting topology is the same. If your implementation is
> >     smart, it
> >      >     can only run a single computation for that case. There is no
> >     violation
> >      >     here whatsoever.
> >      >
> >      >
> >      > KT2> If the resulting topology is the same between SR data plane
> >     and IP
> >      > data plane, what is the need to enable the IP data plane? Why not
> >     just
> >      > steer the IP traffic over the FlexAlgo data plane? And when it is
> >     not
> >      > the same topology, then we cannot really do the protection for IP
> >      > FlexAlgo using SR FlexAlgo. So what is really the use case or
> >     benefit
> >      > for enabling this?
> >
> >     ##PP3
> >     I just gave you an example where this might be useful. You may not
> like
> >     it, but it will have no impact on the defined architecture.
> >
> >
> > KT3> Ack - we can agree to disagree on this.
> >
> >
> >      >
> >      >
> >      >
> >      >
> >      >      > IP forwarding can be steered over the SR-based FlexAlgo
> >     topology
> >      >     along
> >      >      > with the protection provided by it. Am I missing something?
> >      >
> >      >     ##PP2
> >      >     topology for both primary and backup computation must be the
> >     same.
> >      >
> >      >
> >      > KT2> I see the primary use case for IP FlexAlgo (or another data
> >     plane)
> >      > to be that the data plane is used by itself. In the (rare?) case
> >     where
> >      > multiple data planes are required to coexist, it is simpler both
> >     from
> >      > implementation and deployment POV to use different algos. It
> >     would be
> >      > good to have operator inputs here. The only cost that I see for
> >     this is
> >      > that the same FAD may get advertised twice only in the case where
> >     it is
> >      > identical for multiple data planes. So I am still not seeing the
> >     benefit
> >      > of enabling multiple (i.e. per data plane) computations for a
> single
> >      > algo rather than just keeping it a single computation per algo
> >     where a
> >      > single data plane is associated with a specific algo.
> >
> >     ##PP3
> >     I really do not see the problem. As you stated above repeating the
> same
> >     FAD for multiple algos would be inefficient. The beauty of FAD is
> that
> >     it is app independent and can be used by many of them.
> >
> >     If you like to repeat it, fine it will still work. But we do not
> >     want to
> >     mandate that in the spec.
> >
> >
> > KT3> There is currently no normative text in the draft-lsr-flex-algo
> > that specifies that an implementation needs to support a "per flexalgo
> > forwarding mechanism" computation for each algo. So when this
> > clarification is added, can this be a MAY or perhaps a SHOULD so that an
> > implementation has the choice to perhaps not do this and still remain
> > compliant to the spec?
>
> ##PP4
> I'm fine to make that optional.
>
> thanks,
> Peter
> >
> > Thanks,
> > Ketan
> >
> >
> >
> >     thanks,
> >     Peter
> >
> >      >
> >      > Thanks,
> >      > Ketan
> >
>
>