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

Hey Peter,

It seems that we have double layer of confusion here.

First layer is what you are referring as applications in context of ASLA:

RSVP-TE
FRR (ex: LFA)
Flex-Algo

My suggestion about custom/logical topology/dataplane was in reference to
the above.

Then apparently we have more nested confusion which I am afraid is being
also called application like the list you mentioned

SR-MPLS
SR-v6
IPv4
IPv6
BIER
etc ..

Those to me those are forwarding behaviours/paradigms.

Even further confusion is caused by the fact that from network packet
forwarding RSVP-TE is comparable to SR-MPLS or SRv6.

And irrespective how you/we choose to call all of the above please just not
use term application as application is well understood as user applications
which can be http traffic, financial tickers, voip, iptv etc ...

Cheers,
R.



On Thu, Apr 14, 2022 at 11:29 AM Peter Psenak <[e-mail]> wrote:

> Hi Robert,
>
> On 14/04/2022 11:21, Robert Raszuk wrote:
> > 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
>
> flex-algo has been defined so far for:
>
> - SR-MPLS
> - SRv6
> - IP
> - BIER
>
> Would you call them "custom/logical topology" or "logical-data-plane"?
> I would not.
>
> thanks,
> Peter
>
>
> >
> > Thx,
> > Robert.
> >
> >
> >
> >
> >
> >
> > On Thu, Apr 14, 2022 at 9:27 AM Peter Psenak
> > <ppsenak=[e-mail] <mailto:[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]>
> >      > <mailto:[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]>>
> >      >      > <mailto:[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] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/lsr
> >     <https://www.ietf.org/mailman/listinfo/lsr>
> >
>
>