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