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,

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