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,

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.


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


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


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

Thanks,
Ketan