Hi Ketan,
On 13/04/2022 15:56, Ketan Talaulikar wrote:
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.
I will replace with data-plane. That's the best from what we have.
thanks,
Peter
Just my 2c
Thanks,
Ketan
On Wed, Apr 13, 2022 at 2:35 PM Peter Psenak <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
