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