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

[Peter Psenak <[e-mail]>]

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 <[e-mail] 
> <mailto:[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]>
>      > <mailto:[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
>      >
>