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]>> 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
