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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Apr 2022 19:07:09 +0000

This begins a WG last call for draft-ietf-lsr-ip-flexalgo-04.  The draft had a lot of support and discussion initially and has been stable for some time. Please review and send your comments, support, or objection to this list before 12 AM UTC on April 22nd, 2022.

Thanks,
Acee

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 11 Apr 2022 11:55:46 +0530

Hello All,

Following are some comments on this draft:

1) Is this draft about opening the use of all IGP Algorithms for IP (Algo)
Routing or intended to be specific to Flexible Algorithms (i.e. algo
128-255) alone. I think it is important to specify the scope unambiguously.
Perhaps it makes sense to restrict the usage in this particular document to
FlexAlgorithms alone. If not, the draft probably needs an update and we
need to also cover algo 1 (Strict SPF) applicability and update the text to
refer more generically to algo-specific IP routing.

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.

3) This draft makes assertions that IGP FlexAlgo cannot be deployed without
SR. This is not true since the base IGP FlexAlgo spec explicitly opens it
up for usage outside of the SR forwarding plane. We already have BIER and
MLDP forwarding planes as users of the IGP FlexAlgo. My suggestion is to
remove such assertions from the document. It is sufficient to just say that
the document enables the use of IGP FlexAlgo for IP prefixes with native IP
forwarding.

4) The draft is mixing up "address" and "prefix" in some places. IGP path
computation is for prefixes and not addresses. There are a few instances
where "address" should be replaced by "prefix". References to RFC791 and
RFC8200 seem unnecessary.

5) The draft does not cover the actual deployment use-case or applicability
of IP FlexAlgo. The text in Sec 3 is not clear and insufficient. What is
the point/use of sending traffic to a loopback of the egress router?
Perhaps it makes sense in a deployment where IP-in-IP encapsulation is used
for delivering an overlay service? If so, would be better to clarify this.
The other deployment scenario is where "external" or "host/leaf prefixes"
are associated with a FlexAlgo to provide them a different/appropriate
routing path through the network. Yet another is the use of IP FlexAlgo
along with LDP. Sec 9 does not address the topic well enough. I would
suggest expanding and clarifying this and perhaps other such deployment use
cases (or applicability) in the document in one of the earlier sections to
provide a better context to the reader.

6) It would be better to move the common (i.e. not protocol specific) text
from 5.1 and 5.2 under 5. This might also apply to some extent to the
contents of sec 6.

7) Most of the text with MUSTs in sec 5 doesn't really make sense in
repeating - this is covered in the base FlexAlgo spec already. The only
key/important MUST is the one related to using separate algo for IP
FlexAlgo over SR data planes. See my previous comment (2) above.

8) Sec 5.1, the SHOULD needs to be MUST in the text below.

   A router receiving multiple IP Algorithm
   sub-TLVs from the same originator SHOULD select the first
   advertisement in the lowest-numbered LSP and subsequent instances of
   the IP Algorithm Sub-TLV MUST be ignored.

9) Sec 5.1, I would suggest changing the following text as indicated. Also,
perhaps add that the algo 0 MUST NOT be advertised and a receiver MUST
ignore if it receives algo 0.
OLD

   The IP Algorithm Sub-TLV could be used to advertise
   support for non-zero standard algorithms, but that is outside the
   scope of this document.

NEW

   The use of IP Algorithm Sub-TLV to advertise support for algorithms

   outside the flex-algorithm range is outside the
   scope of this document.

10) Sec 5.1, the SHOULD needs to be MUST in the text below

   The IP Algorithm TLV is optional.  It SHOULD only be advertised once
   in the Router Information Opaque LSA.

11) Sec 6. The following text is better moved into the respective
protocol sub-sections. OSPFv3 is not covered anyway by it.

   Two new top-level TLVs are defined in ISIS [ISO10589
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589>]
to advertise
   prefix reachability associated with a Flex-Algorithm.

   *  The IPv4 Algorithm Prefix Reachability TLV

   *  The IPv6 Algorithm Prefix Reachability TLV

   New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684
<https://datatracker.ietf.org/doc/html/rfc7684>] is
   defined to advertise prefix reachability associated with a Flex-
   Algorithm in OSPFv2.

12) Sec 6.1 & 6.2. There is no discussion regd the use of the Prefix
Attribute Flags sub-TLV with the new top-level TLVs.

 I think their usage MUST (or at least SHOULD) be included as it helps
determine the route type and prefix attributes that

have proven to be quite useful for various use cases and deployments.

13) Sec 6.2 what happens when the same prefix is advertised as SRv6
Locator as well as IPv6 Algo Prefix (same or conflicting algos).
Perhaps both must be ignored?

The same applies for OSPFv3 as well.

14) Sec 6.3, OSPFv2 MT-ID reference should be RFC4915. Perhaps the
range of MT should be mentioned since it is a 8 bit field here.

15) Sec 6.4, the metric field in the sub-TLV has to be 32-bit. While
24-bit is ok when the FAD uses IGP metric, it will not suffice for
other IGP metric types.

16) Sec 6.3 & 6.4, the conflict checking with base algo 0 prefix
reachability cannot be limited only to the OSPFv2/3 Extended LSAs but
should also cover the base fixed form

OSPFv2/v3 LSAs. We could use a more generic term like "normal prefix
reachability" advertisements perhaps to cover the different LSAs?

17) Sec 7 and 8, suggest to not use the term "application" to avoid
confusion with ASLA. My understanding is that there is a single
FlexAlgo application when it comes to ASLA.

Perhaps the intention here is "data plane" ?

18) The relationship between the BIER IPA and this draft needs some
clarifications - should the BIER WG be notified if they want to update
draft-ietf-bier-bar-ipa?

This (in some way) goes back to my comment (2) above.

19) Sec 8, what prevents the use of IP FlexAlgo paths programmed by
LDP as well. Or if the intention is to use them strictly for IP
forwarding only

then this needs to be clarified.

20)  The following text in Sec 9 is about using the same FlexAlgo
(with a common definition) for multiple data-planes at the same time.
The key is that we only are able to use

prefix in one algo/data-plane? I am wondering if we can improve this
text to bring this out in a better way. Or altogether remove this if
we agree to not allow sharing of algo

between different data planes to keep things simple.

   Multiple application can use the same Flex-Algorithm value at the

   same time and and as such share the FAD for it.  For example SR-MPLS
   and IP can both use such common Flex-Algorithm.  Traffic for SR-MPLS
   will be forwarded based on Flex-algorithm specific SR SIDs.  Traffic
   for IP Flex-Algorithm will be forwarded based on Flex-Algorithm
   specific prefix reachability announcements.

Thanks,

Ketan

On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> This begins a WG last call for draft-ietf-lsr-ip-flexalgo-04.  The draft
> had a lot of support and discussion initially and has been stable for some
> time. Please review and send your comments, support, or objection to this
> list before 12 AM UTC on April 22nd, 2022.
>
>
>
> Thanks,
> Acee
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 11 Apr 2022 09:36:32 +0200

Hi Ketan,

please responses to some of your comments inline (##PP):

On 11/04/2022 08:25, Ketan Talaulikar wrote:
> 1) Is this draft about opening the use of all IGP Algorithms for IP 
> (Algo) Routing or intended to be specific to Flexible Algorithms (i.e. 
> algo 128-255) alone. I think it is important to specify the scope 
> unambiguously. Perhaps it makes sense to restrict the usage in this 
> particular document to FlexAlgorithms alone. If not, the draft probably 
> needs an update and we need to also cover algo 1 (Strict SPF) 
> applicability and update the text to refer more generically to 
> algo-specific IP routing.

##PP
the intent is to use FlexAlgorithms  only.

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

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

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.

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.

> 
> 3) This draft makes assertions that IGP FlexAlgo cannot be deployed 
> without SR. This is not true since the base IGP FlexAlgo spec explicitly 
> opens it up for usage outside of the SR forwarding plane. We already 
> have BIER and MLDP forwarding planes as users of the IGP FlexAlgo. My 
> suggestion is to remove such assertions from the document. It is 
> sufficient to just say that the document enables the use of IGP FlexAlgo 
> for IP prefixes with native IP forwarding.

##PP
where do you see such assertion? Each flex-algo data-plane/app can be 
deployed independently.

> 
> 4) The draft is mixing up "address" and "prefix" in some places. IGP 
> path computation is for prefixes and not addresses. There are a few 
> instances where "address" should be replaced by "prefix". References to 
> RFC791 and RFC8200 seem unnecessary.
> 
> 5) The draft does not cover the actual deployment use-case or 
> applicability of IP FlexAlgo. The text in Sec 3 is not clear and 
> insufficient. What is the point/use of sending traffic to a loopback of 
> the egress router? Perhaps it makes sense in a deployment where IP-in-IP 
> encapsulation is used for delivering an overlay service? If so, would be 
> better to clarify this. The other deployment scenario is where 
> "external" or "host/leaf prefixes" are associated with a FlexAlgo to 
> provide them a different/appropriate routing path through the network. 
> Yet another is the use of IP FlexAlgo along with LDP. Sec 9 does not 
> address the topic well enough. I would suggest expanding and clarifying 
> this and perhaps other such deployment use cases (or applicability) in 
> the document in one of the earlier sections to provide a better context 
> to the reader.
> 
> 6) It would be better to move the common (i.e. not protocol specific) 
> text from 5.1 and 5.2 under 5. This might also apply to some extent to 
> the contents of sec 6.
> 
> 9) Sec 5.1, I would suggest changing the following text as indicated. 
> Also, perhaps add that the algo 0 MUST NOT be advertised and a receiver 
> MUST ignore if it receives algo 0.
> OLD
> 
>     Two new top-level TLVs are defined in ISIS [ISO10589  <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589>] to advertise
>     New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684  <https://datatracker.ietf.org/doc/html/rfc7684>] is
> Locator as well as IPv6 Algo Prefix (same or conflicting algos). Perhaps 
> both must be ignored?
> 
> 14) Sec 6.3, OSPFv2 MT-ID reference should be RFC4915. Perhaps the range 
> of MT should be mentioned since it is a 8 bit field here.
> 
> 
> 24-bit is ok when the FAD uses IGP metric, it will not suffice for other 
> IGP metric types.
> 
> 
> confusion with ASLA. My understanding is that there is a single FlexAlgo 
> application when it comes to ASLA.
> 

##PP
what is the relationship? I see none.

> 19) Sec 8, what prevents the use of IP FlexAlgo paths programmed by LDP 
> as well. Or if the intention is to use them strictly for IP forwarding only
> 
> 20) The following text in Sec 9 is about using the same FlexAlgo (with a 
> common definition) for multiple data-planes at the same time. The key is 
> that we only are able to use
> 
> text to bring this out in a better way. Or altogether remove this if we 
> agree to not allow sharing of algo
> 

##PP
above text does not talk about the same prefix. It talks in general how 
forwarding works in presence of multiple data-planes/apps using the same 
algo.

thanks,
Peter

> 
> 
> Thanks,
> 
> Ketan
> 
> 
> 
> On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee) 
> <acee=[email-masked] <mailto:[email-masked]>> wrote:
> 
>     This begins a WG last call for draft-ietf-lsr-ip-flexalgo-04.  The
>     draft had a lot of support and discussion initially and has been
>     stable for some time. Please review and send your comments, support,
>     or objection to this list before 12 AM UTC on April 22^nd , 2022.____
> 
>     __ __
> 
>     Thanks,
>     Acee____
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/lsr>
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 11 Apr 2022 19:32:23 +0530

Hi Peter,

Please check inline below.

> the intent is to use FlexAlgorithms  only.

KT> Can the authors clarify this in the text? Perhaps something in one of
the earlier sections of the document that says something like - "these
extensions apply to FlexAlgorithms (128-255) only and the use for other
algorithms is beyond the scope of the document." Also perhaps, indicate
that advertisements for algos outside the FlexAlgorithm ranges SHOULD be
ignored.

> has advantages and we do not want to modify that part.

KT> No issue with this part.

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

> 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? IP
forwarding can be steered over the SR-based FlexAlgo topology along with
the protection provided by it. Am I missing something?

> where do you see such assertion? Each flex-algo data-plane/app can be

KT> Let me clarify what I meant by taking the example of the abstract.

OLD

   An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
   constraint-based paths.  As currently defined, IGP Flex-Algorithm is
   used with Segment Routing (SR) data planes - SR MPLS and SRv6.
   Therefore, Flex-Algorithm cannot be deployed in the absence of SR.

   This document extends IGP Flex-Algorithm, so that it can be used for
   regular IPv4 and IPv6 prefixes.  This allows Flex-Algorithm to be
   deployed in any IP network, even in the absence of SR.

NEW

   An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
   constraint-based paths. The base IGP Flex-Algorithm document
   specified use with Segment Routing (SR) data planes - SR MPLS and

   SRv6.

   This document extends IGP Flex-Algorithm, so that it can be used with
   regular IPv4 and IPv6 forwarding.

> >     Two new top-level TLVs are defined in ISIS [ISO10589  <
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589>]
> to advertise
> >     New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684  <
> https://datatracker.ietf.org/doc/html/rfc7684>] is

KT> Can BIER use FlexAlgo with IP Forwarding as the IPA?
Perhaps draft-ietf-bier-bar-ipa needs to discuss/cover flex algo? This
comment is not so much about the IP FlexAlgo draft and maybe someone here
also working on BIER can point to a document that covers the applicability
of FlexAlgo as IPA for BIER.

> forwarding works in presence of multiple data-planes/apps using the same

KT> I am suggesting that clarifying that we are talking about different
prefixes here would be helpful.

Thanks,
Ketan

---

From: Peter Psenak <[email-masked]>
Date: Tue, 12 Apr 2022 09:14:06 +0200

Hi Ketan,

please see inline (##PP2):

On 11/04/2022 16:02, Ketan Talaulikar wrote:
> On Mon, Apr 11, 2022 at 1:06 PM Peter Psenak <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Ketan,
> 
> KT> Can the authors clarify this in the text? Perhaps something in one 
> of the earlier sections of the document that says something like - 
> "these extensions apply to FlexAlgorithms (128-255) only and the use for 
> other algorithms is beyond the scope of the document." Also perhaps, 
> indicate that advertisements for algos outside the FlexAlgorithm ranges 
> SHOULD be ignored.

##PP2
sure

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

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.

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

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

>     regular IPv4 and IPv6 forwarding.

##PP2
ok

>     <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589
>     <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589>>]
>     to advertise
>      >     New top-level TLV of OSPFv2 Extended Prefix Opaque LSA
>     [RFC7684  <https://datatracker.ietf.org/doc/html/rfc7684
>     <https://datatracker.ietf.org/doc/html/rfc7684>>] is
> comment is not so much about the IP FlexAlgo draft and maybe someone 
> here also working on BIER can point to a document that covers the 
> applicability of FlexAlgo as IPA for BIER.

##PP2
I let some BIER knowledgeable folks to respond to that.
>     (with a

##PP2
absolutely.

thanks,
Peter

>      > <acee=[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>>
>      >
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 13 Apr 2022 09:30:56 +0530

Hi Peter,

Please check inline below with KT2. I am trimming everything other than the
one point of continuing debate.

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

> support it. This is not defined in this draft, it's defined in base

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.

> can only run a single computation for that case. There is no violation

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?

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

Thanks,
Ketan

---

From: Peter Psenak <[email-masked]>
Date: Wed, 13 Apr 2022 09:17:34 +0200

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

>      >     same in SR and IP data-planes, one can use SR to protect IP
>     in that
>      >     algo.
>      >
>      >
> 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.

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

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Apr 2022 10:02:46 +0200

Hi Ketan,

> it is app independent and can be used by many of them.

As I had very same doubts as you I think the advantage here is that even
for the same FAD you can have different links attribute/metric values
advertised on a per "app" basis. Hence you may effectively get different
topologies on a per "application" basis while still using same algorithm.

Again as I and others said it few times the name "app" is badly chosen to
describe forwarding behaviour in data plane but I guess no one is going to
listen and change that name now :)

Practically if folks will use different algorithms to construct different
topologies or use the same algorithm with different metrics all depends on
what real user _applications_ the network is to carry modulo what
flexibility network elements used to construct such network provide.

Thx,
R.

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 13 Apr 2022 14:22:42 +0530

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-masked]> wrote:

> >      >      > planes nor allow the same algo to be used by both IP and
> >     SR data
> >      >     planes.
> >      >      > entries in respective forwarding planes based on the
> >     signaling of
> >      >     the

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?

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

> it, but it will have no impact on the defined architecture.

KT3> Ack - we can agree to disagree on this.

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

Thanks,
Ketan

---

From: Peter Psenak <[email-masked]>
Date: Wed, 13 Apr 2022 11:05:32 +0200

Hi Ketan,

please see inline (##PP4):

On 13/04/2022 10:52, Ketan Talaulikar wrote:
> On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak <[email-masked] 
>      >      >      >
>      >      >      > 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
> 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 

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

> 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
>      >      > IP forwarding can be steered over the SR-based FlexAlgo
>     topology
>      >     along
>      >      > with the protection provided by it. Am I missing something?
>      >
>      >     ##PP2
> 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

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 13 Apr 2022 14:36:53 +0530

Hi Robert,

Please check inline below with KT4.

On Wed, Apr 13, 2022 at 1:31 PM Robert Raszuk <[email-masked]> wrote:

> advertised on a per "app" basis.
>

KT4> This is not possible. Please check my response (KT3) to Peter. All of
FlexAlgo is a single "app" when it comes to link attributes using ASLA. So
one cannot advertise different link attributes for different FlexAlgo
forwarding mechanisms (i.e. SR or IP) when they are using the same algo and
sharing the FAD.

> Hence you may effectively get different topologies on a per "application"
> basis while still using same algorithm.
>

KT4> We get different topologies only via separate signaling of Node
Participation in a given "FlexAlgo forwarding mechanism" (I don't use the
term "application" here) - i.e. SR Algo TLV and IP Algo TLV.

> listen and change that name now :)

KT4> I've suggested a proposal to clarify in my response to Peter.
Unfortunately, the "application" in ASLA may be too late to change, but we
have the opportunity to clarify in the base FlexAlgo as well as this spec.

> flexibility network elements used to construct such network provide.

KT4> So the questions are really as follows:
Q1) Why would an operator want to enable FlexAlgo with IP forwarding in a
network where they can as well do SR forwarding based FlexAlgo?
Q2) When both IP and SR Forwarding based FlexAlgo are sharing the same algo
value, an implementation would need to perform separate computations when
the node participation is different for the two forwarding mechanisms. In
this case, is it still better to use the same algo or ok to use different
algo values from an operational perspective (monitoring, troubleshooting,
management, etc.)?

Thanks,
Ketan

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 13 Apr 2022 19:26:26 +0530

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.

Just my 2c

Thanks,
Ketan

On Wed, Apr 13, 2022 at 2:35 PM Peter Psenak <[email-masked]> wrote:

> >      >      >      > 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
> >      >      >      > 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
> >      >      >      > 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
> >      >      >      > respective prefix reachabilities. The coverage of
> these
> >      >     aspects in a
> >      >      >     dependent. Base flex-algo specification is very clear
> >     about
> >      >     that. That
> >      >      >     Topology calculation for algo/data-plane needs to take
> >     both
> >      >     FAD and
> >      >      >     participation into account. You need independent
> >     calculation
> >      >     for each
> >      >      >     advantages and use cases - e.g. if the participation
> >     for algo
> >      >     X is the
> >      >      > 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
> >      >      > IP forwarding can be steered over the SR-based FlexAlgo
> >     topology
> >      >     along

---

From: Peter Psenak <[email-masked]>
Date: Thu, 14 Apr 2022 09:27:37 +0200

Hi Ketan,

> "data-plane", I was suggesting "forwarding mechanism" or it can be 

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-masked] 
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Ketan,
>      >
>      >
>      >      > 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
>      >      >     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
>      >      >      >     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
>      >      >      > 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
>      >      > Thanks,
>      >      > Ketan

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Apr 2022 11:21:08 +0200

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=
[email-masked]> wrote:

> >      >      > Please check inline below with KT2. I am trimming
> everything
> >      >     other than
> >      >      >      >      > data planes (e.g. FlexAlgo with SR) is not
> >     very clear.
> >      >      >     There arise
> >      >      >      >      > is not shared. While Sec 9 suggests that we
> >     can work
> >      >      >     through these
> >      >      >      >      > space is large enough to allow it to be
> >     shared between
> >      >      >     various data
> >      >      >      >      > 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.
> >      >      >      >      > algo based on its FAD and data plane
> >     participation and
> >      >      >     then when it
> >      >      >      >      > comes to prefix calculation, the results
> >     could involve
> >      >      >      >     programming of
> >      >      >      >      > respective prefix reachabilities. The
> >     coverage of these
> >      >      >     aspects in a
> >      >      >      >     FAD is data-pane/app independent. Participation
> is
> >      >     data-plane/app
> >      >      >      > 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
> >      >      > KT2> This specific and precise statement that you have
> >     provided
> >      >     is not
> >      >      >     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
> >      >      > So it is not that because some implementations can do (or
> >     does)
> >      >     it that
> >      >      > should be in a specification needs to be based on the
> tradeoff
> >      >     between
> >      >      >      >     The fact that the same FAD is shareable between
> all
> >      >     apps has it
> >      >      >     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
> >      >      > FlexAlgo using SR FlexAlgo. So what is really the use case
> or
> >      >     benefit
> >      >      > for enabling this?
> >      >
> >      >     ##PP3
> >      >      >     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
> >      >      > algo rather than just keeping it a single computation per
> algo
> >      >     where a
> >      >     If you like to repeat it, fine it will still work. But we do
> not
> >      >     want to

---

From: Peter Psenak <[email-masked]>
Date: Thu, 14 Apr 2022 11:29:00 +0200

Hi Robert,

> - custom/logical topology

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=[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Hi Ketan,
> 
>      >      > 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-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> 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
>      >      >      >     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
>      >      >      >      >     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
>      >      >     thanks,
>      >      >     Peter
>      >      >      > Thanks,
>      >      >      > Ketan

---

From: Huzhibo <[email-masked]>
Date: Thu, 14 Apr 2022 09:51:07 +0000

Hi Ketan:
I agree with you.
IGP MT is a good precedent. If IPv4 and IPv6 use the same MT, the IPv4 and IPv6 topologies must be the same. The same MT does not define separate topologies or path computation for different data planes. If IPv4 and IPv6 data plane has different topologies, different MTs are used. I suggest Flexalgo uses the same logic as MT.

Thanks

Zhibo

From: Lsr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar
Sent: Wednesday, April 13, 2022 12:01 PM
To: Peter Psenak <[email-masked]>
Cc: [email-masked]; [email-masked]; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Peter,

Please check inline below with KT2. I am trimming everything other than the one point of continuing debate.

##PP2

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.

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.

##PP2

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?

##PP2

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.

Thanks,
Ketan

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Apr 2022 14:29:23 +0200

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 <[email-masked]> wrote:

> >      >      > I will not press this point further if I am the only one
> that
> >      >     finds this
> >      >      > On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak
> >      >      > <mailto:[email-masked] <mailto:[email-masked]>
> >      >      >      >      >      > 2) The relationship between the algo
> >     usage
> >      >     for IP
> >      >      >     FlexAlgo
> >      >      >      >     and other
> >      >      >      >      >      > complications when the algo usage for
> IP
> >      >     FlexAlgo
> >      >      >     overlap
> >      >      >      >     with other
> >      >      >      >      >      > planes without overlap. My suggestion
> >     would
> >      >     be to
> >      >      >     neither
> >      >      >      >     carve out
> >      >      >      >      >      > entries in respective forwarding
> planes
> >      >     based on the
> >      >      >      >     signaling of
> >      >      >      >      >     the
> >      >      >      >      >     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.
> >      >      >      >      >
> >      >      >      >      >
> >      >      >      >      >     Topology calculation for algo/data-plane
> >     needs
> >      >     to take
> >      >      >     both
> >      >      >      >     FAD and
> >      >      >      >      > 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
> >      >      >      >     unique participation per app/data-plane. That
> >     requires
> >      >      >     per-algo/per
> >      >      >      > starters, this needs to be clarified and covered so
> >     that
> >      >     it gets the
> >      >      >     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
> >      >      > KT3> Thanks. I think we may also need to carefully scrub
> >     the use
> >      >     of the
> >      >      > FlexAlgo is a single "application". We can perhaps use the
> >     term
> >      >     "traffic
> >      >      > flows" or "service flows" as an alternate for "application
> >     flows"
> >      >     that
> >      >      > 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
> >      >      >      >     If your implementation does not want to support
> it,
> >      >     fine, but the
> >      >      >      > 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
> >      >      >     reason. Requiring per app flex-algo even though I want
> >     to use
> >      >     the same
> >      >      > KT3> For my understanding, the only inefficiency that you
> are
> >      >     referring
> >      >     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
> >      >      >      >      >     same in SR and IP data-planes, one can
> >     use SR to
> >      >      >     protect IP
> >      >      >      >     in that
> >      >      >      >      >     algo.
> >      >      >      >      >
> >      >      >      >      >
> >      >      >      > 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
> >      >      >      >      > with the protection provided by it. Am I
> missing
> >      >     something?
> >      >      >      >
> >      >      >      >     ##PP2
> >      >      >      > implementation and deployment POV to use different
> >     algos. It
> >      >      >     would be
> >      >      >      > 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
> >      >      >     FAD for multiple algos would be inefficient. The
> beauty of
> >      >     FAD is that
> >      >      >     If you like to repeat it, fine it will still work. But
> >     we do not
> >      >      >     want to
> >      >      > that specifies that an implementation needs to support a
> "per
> >      >     flexalgo
> >      >      > 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

---

From: John E Drake <[email-masked]>
Date: Thu, 14 Apr 2022 13:22:35 +0000

Hi,

In the IETF context I have always associated 'data plane' with packet forwarding, so I think Peter's suggestion is fine.

Yours Irrespectively,

John

Juniper Business Use Only
From: Lsr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, April 14, 2022 5:21 AM
To: Peter Psenak <ppsenak=[email-masked]>
Cc: Ketan Talaulikar <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[External Email. Be cautious of content]

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.

Thx,
Robert.

On Thu, Apr 14, 2022 at 9:27 AM Peter Psenak <ppsenak=[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

thanks,
Peter

>
> Just my 2c
>
> Thanks,
> Ketan
>
>
> On Wed, Apr 13, 2022 at 2:35 PM Peter Psenak <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hi Ketan,
>
>      > On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>      > <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>      >
>      >     Hi Ketan,
>      >
>      >

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!TzTdj43IFN6fAOGdIoLWLPVget9auoAEB4GEhK3-KKwX2ecau0S1IyKViY2p4BA$>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Apr 2022 15:50:44 +0200

Hi John,

In the IETF context I have always associated ‘data plane’ with packet
> forwarding,

No one disputes that.

But the fact that various sub-data-planes are built on top of base physical
data planes needs to be clearly distinguished.

Kind regards,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 14 Apr 2022 14:54:52 +0000

Speaking as document shepherd and WG member:

I don’t have a problem with “MPLS SR and SRv6 data planes” but wouldn’t be opposed to “MPLS SR and SRv6 logical data planes”.

Thanks,
Acee

From: Robert Raszuk <[email-masked]>
Date: Thursday, April 14, 2022 at 9:51 AM
To: John E Drake <[email-masked]>
Cc: "Peter Psenak (ppsenak)" <[email-masked]>, Ketan Talaulikar <[email-masked]>, Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi John,

In the IETF context I have always associated ‘data plane’ with packet forwarding,

No one disputes that.

But the fact that various sub-data-planes are built on top of base physical data planes needs to be clearly distinguished.

Kind regards,
R.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 14 Apr 2022 18:49:04 +0000

Me too.

Juniper Business Use Only
From: Acee Lindem (acee) <[email-masked]>
Sent: Thursday, April 14, 2022 10:55 AM
To: Robert Raszuk <[email-masked]>; John E Drake <[email-masked]>
Cc: Peter Psenak (ppsenak) <[email-masked]>; Ketan Talaulikar <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

I don't have a problem with "MPLS SR and SRv6 data planes" but wouldn't be opposed to "MPLS SR and SRv6 logical data planes".

Thanks,
Acee

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 14, 2022 at 9:51 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>, Ketan Talaulikar <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi John,

In the IETF context I have always associated 'data plane' with packet forwarding,

No one disputes that.

Kind regards,
R.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 15 Apr 2022 05:08:30 +0000

Hi Robert,

How about call them different “data plane encapsulations”?

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, April 14, 2022 9:51 PM
To: John E Drake <[email-masked]>
Cc: [email-masked]; Ketan Talaulikar <[email-masked]>; [email-masked]; Peter Psenak <ppsenak=[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi John,

No one disputes that.

Kind regards,
R.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 15 Apr 2022 16:00:57 +0000

Hi Ketan, Peter,

I’ve just finished reading this thread, and think Ketan’s concerns make sense. Although the current Flex-Algo Definition is independent of the data plane encapsulation, I’m not sure if there is real benefit to use the same FAD with different data plane participation to cut out different topologies for path computation.

We used to have similar discussion on the list in December of 2020. At that time there was suggestion to simply use different Flex-Algo IDs with different data planes participation, or we may need to define per data plane Flex-Algo participation mechanisms for IPv4, IPv6, SR-MPLS and SRv6 respectively.

Per Flex-Algo SPF computation is straightforward for implementation and inter-operation, and also easy to manage and troubleshoot for operators. Actually a Flex-Algo ID can be seen as the identifier of the combination of the rules/constraints defined in FAD, and the set of nodes which participate in the Flex-Algo. But if one Flex-Algo can correspond to multiple topologies in the same network, we would need some additional identifiers for each of these topologies.

Thus my suggestion is also to make per Flex-Algo computation the default behavior. Per Flex-Algo per data plane computation could be optional.

Best regards,
Jie

From: Lsr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar
Sent: Wednesday, April 13, 2022 4:53 PM
To: Peter Psenak <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Peter,

I will not press this point further if I am the only one that finds this complexity without any benefit. :-)

On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

##PP3

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?

##PP3

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?

##PP3

##PP3

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?

Thanks,
Ketan

thanks,
Peter

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 15 Apr 2022 17:30:58 -0400

Hi Peter

My understanding is that the main goal of this draft is to be able to use
flex algo over IPv4 or IPv6 data plane as that is not possible with
existing Flex Algo which can only be used on SR data plane.

Is that correct or am I missing something?

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo

Abstract

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-19

Abstract

   IGP protocols traditionally compute best paths over the network based
   on the IGP metric assigned to the links.  Many network deployments
   use RSVP-TE based or Segment Routing based Traffic Engineering to
   steer traffic over a path that is computed using different metrics or
   constraints than the shortest IGP path.  This document proposes a
   solution that allows IGPs themselves to compute constraint-based
   paths over the network.  This document also specifies a way of using
   Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets
   along the constraint-based paths.

Kind Regards

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 15 Apr 2022 23:50:41 +0000

Gyan,

What is your point here? Is this a trick question?

Thanks,
Acee

From: Gyan Mishra <[email-masked]>
Date: Friday, April 15, 2022 at 5:31 PM
To: "Peter Psenak (ppsenak)" <[email-masked]>
Cc: Acee Lindem <[email-masked]>, Ketan Talaulikar <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Peter

My understanding is that the main goal of this draft is to be able to use flex algo over IPv4 or IPv6 data plane as that is not possible with existing Flex Algo which can only be used on SR data plane.

Abstract

Abstract

Kind Regards

Gyan

On Mon, Apr 11, 2022 at 3:37 AM Peter Psenak <ppsenak=[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

##PP

##PP
I strongly disagree.

##PP

##PP

##PP

thanks,
Peter

> <acee=[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 15 Apr 2022 22:34:44 -0400

Hi Acee

My question cane up from the list of questions posed by Ketan and Peter’s
response to question #3.

See excerpt below.

I am confused by what Ketan stated in his question below and also Peter’s
response which is why I am asking the question again.

I believe the goal of the draft is for Flex Ago to be deployed
independently of SR filling the gap of IGP Flex Algo providing that
solution.  So based on what Ketan stated in his question that IGP Flex Algo
is data plane agnostic and can be used with IP data plane then there is no
gap to be filled by this draft.

Maybe I am misreading Ketan’s question.

So this is a very important point made by Ketan that if IGP Flex Algo is
open to usage outside Flex Algo then it is very important to restate the
goal of this draft, removing assertions in the draft that this draft is for
non SR IP data planes, as that can be accomplished today by IGP Flex Algo,
and the gap or new solution being filled by this draft is for IP prefix
based Flex Algo with Native IP Forwarding.

This as well is quite confusing to me as if IGP Flex Algo can be used
outside of SR then can do everything that this draft is supposed to
accomplish.

So what then is the purpose of this draft?

In Peter’s response is stated that each Flex Algo data plane / app can be
deployed independently meaning this draft and IGP flex Algo can act as 2
ships in the night.  Also confusing.

##PP

On Fri, Apr 15, 2022 at 7:51 PM Acee Lindem (acee) <[email-masked]> wrote:

> *From: *Gyan Mishra <[email-masked]>
> *Date: *Friday, April 15, 2022 at 5:31 PM
> *To: *"Peter Psenak (ppsenak)" <[email-masked]>
> *Cc: *Acee Lindem <[email-masked]>, Ketan Talaulikar <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [Lsr] Working Group Last Call for
> draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm)
> In IP Networks"
>
>
>
>
>
> Hi Peter
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 15 Apr 2022 22:37:40 -0400

Hi Acee

Fixing a typo

On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra <[email-masked]> wrote:

> open to usage “outside of SR”,  then it is very important to restate the
>> range
>> other

*Gyan Mishra*

*M 301 502-1347*

---

From: Ketan Talaulikar <[email-masked]>
Date: Sat, 16 Apr 2022 09:50:49 +0530

Hi Gyan,

I am not sure what the confusion is here. The following is how Peter and I
concluded this point. My comment was of editorial nature.

Thanks,
Ketan

##PP2
ok

On Sat, Apr 16, 2022 at 8:07 AM Gyan Mishra <[email-masked]> wrote:

>>> My understanding is that the main goal of this draft is to be able to
>>> use flex algo over IPv4 or IPv6 data plane as that is not possible with

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 Apr 2022 03:20:57 -0400

Hi Ketan

My understanding was that IGP Flex Algo could only be used with SR-MPLS or SRv6 data plane using prefix SID or SRv6 locator to steer packets.  

So it was my understanding that the IP Flex Algo draft was providing a solution for IP based networks ( Non SR-MPLS or SRv6) networks which was valuable gap to be filled.

However your editorial comments shed some light that IGP Flex Algo may be used in  IP based ( Non SR-MPLD or SRv6) based networks.  This is confusing to me however below paragraph makes it more clear to me as to why you stated IGP Flex Algo is open to beyond SR ( even though not yet developed).

IGP Flex Algo draft Section 14 describes forwarding plane use cases for Flex Algo which are SR-MPLS and SRv6 and 14.3 mentions that any application that wants to use Flex Algo can use it but that application needs to be developed to install the Flex Algo entires into the forwarding plane such as for RSVP-TE or native IPv4 or IPv6 forwarding plane.

I think if IGP Flex Algo was developed as part of the draft to support other applications such as RSVP-TE and native IPv4 or IPv6 forwarding plane I think we could say that IGP Flex Algo can be used outside of SR data plane but that development has not been done even though it maybe possible in the future once developed or it may never be developed based on industry demand.  So I think it’s safe to say at this time IGP Flex Algo only supports SR-MPLS and SRv6 forwarding planes only.  However now once IP Flex Algo is published and implemented we can safely say that it has been extended beyond SR data plane.

I would change the verbiage slightly to make it more clear.  You mention that the IGP Flex Algo draft is the base Flex Algo draft but I disagree as if it were then the IP Flex Algo draft or any other application of Flex Algo with a new data plane would be an update to the base Flex Algo draft but here in this case I don’t think so and even for any other application.  Each data plane instance of Flex Algo starting with the IP Flex Algo draft and then maybe future RSVP Flex Algo draft would be their own independent “base” Flex Algo draft onto themselves.  That is one option, to keep each data plane specification of Flex Algo independent specifications.

 If we think that IP Flex Algo and future data plane applications such as RSVP-TE and beyond will be extensions of the IGP Base specification, so then will be updates to the base specification, then I think we can call IP Flex Algo an extension to the base specification.

This is what I think the verbiage should state which is a hybrid of yours and Peter’s verbiage.

This is if each application is standalone per data plane  and is not an extension and so IGP Flex Algo would not be a base specification.

NEW

> >     An IGP Flexible Algorithm (Flex-Algorithm) allows the IGP to compute
> >     constraint-based paths. The  IGP Flex-Algorithm specification 
> >     currently only supports the application Segment Routing with (SR) data planes - SR MPLS and
> >     SRv6.
> >
> >     This document specifies IGP Flex-Algorithm, so that it can be used  in any IP network 
> >     for native  IPv4 and IPv6 forwarding in the absence of SR.

Verbiage if IGP Flex Algo is a base and this draft is an extension and updates the base.  We don’t have to say IGP Flex Algo currently only supports dropping the word currently as we are now extending with IP Flex Algo.

> > NEW
> >
> >     An IGP Flexible Algorithm (Flex-Algorithm) allows the IGP to compute
> >     constraint-based paths. The base IGP Flex-Algorithm specification only supports the application Segment Routing with (SR) data planes - SR MPLS and SRv6.
> >
> >     This document extends IGP Flex-Algorithm, so that it can be used 
> >     natively with IPv4 and IPv6 forwarding.

Kind Regards 

Gyan

Sent from my iPhone

> On Apr 16, 2022, at 12:21 AM, Ketan Talaulikar <[email-masked]> wrote:
> 
> 
> Hi Gyan,
> 
> I am not sure what the confusion is here. The following is how Peter and I concluded this point. My comment was of editorial nature.
> 
> Thanks,
> Ketan
> 
>>> My question cane up from the list of questions posed by Ketan and Peter’s response to question #3.
>>> 
>>> See excerpt below.
>>> 
>>> I am confused by what Ketan stated in his question below and also Peter’s response which is why I am asking the question again.  
>>> 
>>> I believe the goal of the draft is for Flex Ago to be deployed independently of SR filling the gap of IGP Flex Algo providing that solution.  So based on what Ketan stated in his question that IGP Flex Algo is data plane agnostic and can be used with IP data plane then there is no gap to be filled by this draft. 
>>> 
>>> So this is a very important point made by Ketan that if IGP Flex Algo is open to usage “outside of SR”,  then it is very important to restate the goal of this draft, removing assertions in the draft that this draft is for non SR IP data planes, as that can be accomplished today by IGP Flex Algo, and the gap or new solution being filled by this draft is for IP prefix based Flex Algo with Native IP Forwarding.  
>>> 
>>> This as well is quite confusing to me as if IGP Flex Algo can be used outside of SR then can do everything that this draft is supposed to accomplish.
>>> 
>>> In Peter’s response is stated that each Flex Algo data plane / app can be deployed independently meaning this draft and IGP flex Algo can act as 2 ships in the night.  Also confusing.
>>>

---

From: Ketan Talaulikar <[email-masked]>
Date: Sat, 16 Apr 2022 19:31:23 +0530

Hi Gyan,

Your proposal looks ok to me. Note though that we seem to be converging
towards using an alternate term instead of "application" in this context.

Thanks,
Ketan

On Sat, Apr 16, 2022 at 12:50 PM Gyan Mishra <[email-masked]> wrote:

>
> Hi Ketan
>
> My understanding was that IGP Flex Algo could only be used with SR-MPLS or
> SRv6 data plane using prefix SID or SRv6 locator to steer packets.
>
> So it was my understanding that the IP Flex Algo draft was providing a
> solution for IP based networks ( Non SR-MPLS or SRv6) networks which was
> valuable gap to be filled.
>
> However your editorial comments shed some light that IGP Flex Algo may be
> used in  IP based ( Non SR-MPLD or SRv6) based networks.  This is confusing
> to me however below paragraph makes it more clear to me as to why you
> stated IGP Flex Algo is open to beyond SR ( even though not yet developed).
>
> IGP Flex Algo draft Section 14 describes forwarding plane use cases for
> Flex Algo which are SR-MPLS and SRv6 and 14.3 mentions that any application
> that wants to use Flex Algo can use it but that application needs to be
> developed to install the Flex Algo entires into the forwarding plane such
> as for RSVP-TE or native IPv4 or IPv6 forwarding plane.
>
> I think if IGP Flex Algo was developed as part of the draft to support
> other applications such as RSVP-TE and native IPv4 or IPv6 forwarding plane
> I think we could say that IGP Flex Algo can be used outside of SR data
> plane but that development has not been done even though it maybe possible
> in the future once developed or it may never be developed based on industry
> demand.  So I think it’s safe to say at this time IGP Flex Algo only
> supports SR-MPLS and SRv6 forwarding planes only.  However now once IP Flex
> Algo is published and implemented we can safely say that it has been
> extended beyond SR data plane.
>
> I would change the verbiage slightly to make it more clear.  You mention
> that the IGP Flex Algo draft is the base Flex Algo draft but I disagree as
> if it were then the IP Flex Algo draft or any other application of Flex
> Algo with a new data plane would be an update to the base Flex Algo draft
> but here in this case I don’t think so and even for any other application.
> Each data plane instance of Flex Algo starting with the IP Flex Algo draft
> and then maybe future RSVP Flex Algo draft would be their own independent
> “base” Flex Algo draft onto themselves.  That is one option, to keep each
> data plane specification of Flex Algo independent specifications.
>
>  If we think that IP Flex Algo and future data plane applications such as
> RSVP-TE and beyond will be extensions of the IGP Base specification, so
> then will be updates to the base specification, then I think we can call IP
> Flex Algo an extension to the base specification.
>
> This is if each application is standalone per data plane  and is not an
> extension and so IGP Flex Algo would not be a base specification.
>
> NEW
>
> Verbiage if IGP Flex Algo is a base and this draft is an extension and
> updates the base.  We don’t have to say IGP Flex Algo currently only
> supports dropping the word currently as we are now extending with IP Flex
> Algo.
>
> > NEW
> >
> >     constraint-based paths. The base IGP Flex-Algorithm specification
> only supports the application Segment Routing with (SR) data planes - SR
> MPLS and SRv6.
> >
>>> I am confused by what Ketan stated in his question below and also
>>> Peter’s response which is why I am asking the question again.
>>>
>>> In Peter’s response is stated that each Flex Algo data plane / app can
>>> be deployed independently meaning this draft and IGP flex Algo can act as 2

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 Apr 2022 11:45:45 -0400

Thank you Ketan.

Ack on convergence on new term for application.😃

Thanks

Gyan

On Sat, Apr 16, 2022 at 10:01 AM Ketan Talaulikar <[email-masked]>
wrote:

>> My understanding was that IGP Flex Algo could only be used with SR-MPLS
>> or SRv6 data plane using prefix SID or SRv6 locator to steer packets.
>>
>> I am not sure what the confusion is here. The following is how Peter and
>> I concluded this point. My comment was of editorial nature.
>>
>> Thanks,
>> Ketan
>>
>>>> So this is a very important point made by Ketan that if IGP Flex Algo
>>>> is open to usage “outside of SR”,  then it is very important to restate the

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 Apr 2022 12:16:38 -0400

I support WG adoption of IP Flex Algo as an extension to the base IGP Flex
Algo.

This is a highly valuable extension for operators that can now apply to any
IP based networks.

One of the major benefits to migrating SR is being  able to use Flex Algo
for network slicing capabilities.

Now with IP Flex Algo you don’t need SR and this has great applicability
for DC NVO constraint based steering capabilities as well as maybe other IP
environments where steering capabilities is desired but you don’t want the
MPLS or SR complexity.

 One follow on question for authors is if IP Flex Algo is used on the same
link with IGP Flex Algo  are there any compatibility issues?

The IP Flex Algo draft I believe should mirror all the sections in the IGP
Flex Algo draft with new Sub TLV defined for IP Flex Algo.  I see the Admin
group coloring sections omitted.  I don’t see why you cannot have admin
group for include and exclude links which I think should apply to IP Flex
Algo as well.

Peter

>From the discussion point #3 with Ketan, Ketan is Ok with the two options
of updates below.

As IP Flex Algo would be an extension to the base IGP Flex Algo please use
update Option #2.

Option #1 This is if each application is standalone per data plane  and is
not an extension and so IGP Flex Algo would not be a base specification.

NEW

>     currently only supports Segment Routing with (SR) data planes - SR
MPLS and
>     for native  IPv4 and IPv6 forwarding in the absence of SR.

Option #2 Verbiage if IGP Flex Algo is a base and this draft is an
extension and updates the base.  We don’t have to say IGP Flex Algo
currently only supports dropping the word currently as we are now extending
with IP Flex Algo.

>     constraint-based paths. The base IGP Flex-Algorithm specification
only supports the  Segment Routing with (SR) data planes - SR MPLS and SRv6.

Kind Regards

Gyan

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 16 Apr 2022 21:45:08 +0000

Speaking as WG member and document shepherd:

Hi Gyan,

Thanks for the explanation. My position is that the initial draft, draft-ietf-lsr-flex-algo,  and the encodings with their attendant constraints on those encodings were targeted towards MPLS and SRv6. Given that the draft has been in progress for a couple years and that there are implementations, we don’t really gain anything by generalizing this draft. This can come with draft-ietf-lsr-ip-flexalgo. Am I missing anything here?  This question is for Ketan as well…
Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Friday, April 15, 2022 at 10:38 PM
To: Acee Lindem <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Ketan Talaulikar <[email-masked]>, "[email-masked]" <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Acee

Fixing a typo

On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Hi Acee

See excerpt below.

##PP

On Fri, Apr 15, 2022 at 7:51 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

Thanks,
Acee

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 15, 2022 at 5:31 PM
To: "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Ketan Talaulikar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Peter

Abstract

Abstract

Kind Regards

Gyan

##PP

##PP
I strongly disagree.

##PP

##PP

##PP

thanks,
Peter

Error! Filename not specified.<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 16 Apr 2022 21:53:54 +0000

Again, speaking as WG member:
Hi Gyan, Ketan,
I agree since for the IGPs we’ve traditionally used “application” for control plane routing applications (shortest-path, RSVP TE, SR, etc.). I know Robert suggested “logical data plane”… What are the thoughts on this?

Thanks,
Acee

From: Gyan Mishra <[email-masked]>
Date: Saturday, April 16, 2022 at 11:46 AM
To: Ketan Talaulikar <[email-masked]>
Cc: Acee Lindem <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>, "[email-masked]" <[email-masked]>, lsr <[email-masked]>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Thank you Ketan.

Thanks

Gyan

On Sat, Apr 16, 2022 at 10:01 AM Ketan Talaulikar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Your proposal looks ok to me. Note though that we seem to be converging towards using an alternate term instead of "application" in this context.

Thanks,
Ketan

On Sat, Apr 16, 2022 at 12:50 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ketan

NEW

Kind Regards

Gyan

Sent from my iPhone

On Apr 16, 2022, at 12:21 AM, Ketan Talaulikar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Thanks,
Ketan

##PP2
ok

On Sat, Apr 16, 2022 at 8:07 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Hi Acee

Fixing a typo

Hi Acee

See excerpt below.

##PP

Thanks,
Acee

Hi Peter

Abstract

Abstract

Kind Regards

Gyan

--

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 Apr 2022 18:28:27 -0400

Hi Acee

Responses in-line

On Sat, Apr 16, 2022 at 5:45 PM Acee Lindem (acee) <[email-masked]> wrote:

> Thanks for the explanation. My position is that the initial draft,
> draft-ietf-lsr-flex-algo,  and the encodings with their attendant
> constraints on those encodings were targeted towards MPLS and SRv6. Given
> that the draft has been in progress for a couple years and that there are
> implementations, we don’t really gain anything by generalizing this draft.
>
    Gyan> Agreed.  I don’t think should  change anything in IGP Flex Algo
draft.  The current IGP Flex Algo draft is generic in terms of data planes
in section 14 that is supports SR data plane SR-MPLS and SRv6 and as stated
in 14.3 that it can support extensibility for other future data planes
which does not need any update as now we are seeing a new application with
this IP Flex Algo draft.

So net-net no change to the IGP Flex Algo draft.

This can come with draft-ietf-lsr-ip-flexalgo.
   Gyan> The changes proposed is in the verbiage is for the IP Flex Algo
draft authors to update which would I think be the Option 2 verbiage that
IGP Flex Algo is the base specification and IP Flex Algo is an extension of
the base and an update on top of the base specification.  In the future if
RSVP-TE or any other application comes along they would follow suit and be
extensions of the base as well.

Am I missing anything here?
    Nope.  All set.  We just need the IP Flex Algo authors to concur with
the Option 2 verbiage I proposed.

> This question is for Ketan as well…
>
> Thanks,
>
> Acee
>
>
>
>
>
> *From: *Lsr <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Friday, April 15, 2022 at 10:38 PM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Ketan Talaulikar <
> [email-masked]>, "Peter Psenak (ppsenak)" <
> [email-masked]>
> *Error! Filename not specified.* <http://www.verizon.com/>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 Apr 2022 18:36:57 -0400

Hi Acee

Responses in-line

On Sat, Apr 16, 2022 at 5:53 PM Acee Lindem (acee) <[email-masked]> wrote:

> I agree since for the IGPs we’ve traditionally used “application” for
> control plane routing applications (shortest-path, RSVP TE, SR, etc.). I
> know Robert suggested “logical data plane”… What are the thoughts on this?
>
> Gyan> I read through the comments on the thread related to ASLA and
> confusion with the word application defining a data plane which I and I
> think most in the WG agree the term application being applied to a data
> plane is no doubt confusing.
>
    I am good with “logical data plane”.   Data plane instance, identifier,
slice or transport would work as well.

> *Date: *Saturday, April 16, 2022 at 11:46 AM
> *To: *Ketan Talaulikar <[email-masked]>
> *Cc: *Acee Lindem <[email-masked]>, "Peter Psenak (ppsenak)" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, lsr <[email-masked]>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 17 Apr 2022 22:32:55 +0530

Hi Acee,

Regarding the draft-ietf-lsr-flex-algo, there are two aspects that I had
brought up as part of the discussion on the IP FlexAlgo draft:

1) A purely editorial thing: the suggestion to use a term other than
"application" for the data plane or forwarding mechanism related to
FlexAlgo. Peter has suggested "data plane" and I am ok with that or a
similar term (something other than "application" so it doesn't get mixed up
with "application" as in ASLA).

2) The clarification on a per algo per "forwarding plane" computation
requirement. This is not something specified clearly in
draft-ietf-lsr-flex-algo and it is important that we do so using normative
language since that document forms the flex algo base.

Apart from the above, I do not have any other concerns or comments on that
draft.

Thanks,
Ketan

On Sun, Apr 17, 2022 at 3:15 AM Acee Lindem (acee) <[email-masked]> wrote:

> This can come with draft-ietf-lsr-ip-flexalgo. Am I missing anything here?