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

[Peter Psenak <[e-mail]>]

Hi Ketan,

please see inline (##PP2):


On 11/04/2022 16:02, Ketan Talaulikar wrote:
> Hi Peter,
> 
> Please check inline below.
> 
> 
> On Mon, Apr 11, 2022 at 1:06 PM Peter Psenak <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi Ketan,
> 
>     please responses to some of your comments inline (##PP):
> 
>     On 11/04/2022 08:25, Ketan Talaulikar wrote:
>      > 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.
> 
>     ##PP
>     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.

##PP2
sure

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

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.


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



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

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

##PP2
ok

> 
> 
>      >
>      > 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
>     <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
>     <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?
> 
>     ##PP
>     what is the relationship? I see none.
> 
> 
> 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.

##PP2
I let some BIER knowledgeable folks to respond to that.
> 
> 
> 
>      >
>      > 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.
> 
> 
>     ##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.
> 
> 
> KT> I am suggesting that clarifying that we are talking about different 
> prefixes here would be helpful.
> 

##PP2
absolutely.

thanks,
Peter


> Thanks,
> Ketan
> 
> 
>     thanks,
>     Peter
> 
>      >
>      >
>      > Thanks,
>      >
>      > Ketan
>      >
>      >
>      >
>      > On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee)
>      > <acee=[e-mail]
>     <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>> 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____
>      >
>      >     _______________________________________________
>      >     Lsr mailing list
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
>      >     <https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>>
>      >
>