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

[Robert Raszuk <[e-mail]>]

Hi Peter,

Term "data-plane" usually means physical resources links, switch fabric,
ASIC etc ... so I am afraid it will also generate confusion with default
data plane.

How about two alternatives:

- custom/logical topology
- logical-data-plane

Thx,
Robert.






On Thu, Apr 14, 2022 at 9:27 AM Peter Psenak <ppsenak=
[e-mail]> wrote:

> 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
> >      >
> >
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>