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

[Ketan Talaulikar <[e-mail]>]

Hi Peter,

Thanks for your updates to the draft and your responses below.

I would like to point out a few remaining points to be fixed/addressed.

a) There is a discrepancy regarding the size of the Metric field for the
OSPFv2 IP Algo Reachability sub-TLV between the figure and the text
description. The text needs to be fixed to reflect 4 octets size.

b) For the OSPFv3 IP Algo Prefix Reachability sub-TLV the Type should be 2
octets and the discrepancy in the sub-TLV name in the Figure needs to be
corrected. Length should now become 8.

c) The references to the sections of draft-lsr-flex-algo in this document
need corrections in Sec 7 ? In general, I think the references to the base
draft sections 11, 12, and 13 (except that M-flag is always used) would be
helpful.

Thanks,
Ketan

On Wed, May 11, 2022 at 3:20 PM Peter Psenak <[e-mail]> wrote:

> Hi Ketan,
>
>
> please see 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
> Done
>
> >
> > 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
> this has been discussed previously in this thread.
>
>
> >
> > 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
> Done
>
> >
> > 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.
>
>
> ##PP
> Done
>
> >
> > 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.
>
>
> ##PP
> Done
>
>
> >
> > 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.
>
>
> ##PP
> Done. For section 6, I would prefer to keep it in the protocol specific
> sections.
>
> >
> > 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.
>
> ##PP
> I prefer to keep the MUSTs there
>
> >
> > 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.
>
> ##PP
> Done.
>
> >
> >
> > 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.
>
> ##PP
> Done
>
> >
> >
> > 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.
>
> ##PP
> Done
>
> >
> >
> > 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.
>
> ##PP
> Done
>
> >
> > 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.
>
> ##PP
>
> Why? We have a text that says:
>
> "This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236
> and 237."
>
> Why do we need to describe the usage of the specific sub-TLV?
>
> >
> >
> > 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.
>
> ##PP
> Done
>
> >
> >
> > 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.
>
> ##PP
> Done
>
> >
> >
> > 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.
>
> ##PP
> Done
>
> >
> >
> > 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?
>
> ##PP
> Done
>
>
> >
> >
> > 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" ?
>
> ##PP
> Done
>
> >
> >
> > 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.
>
> ##PP
> I don't see the relationship to BIER IPA here.
>
> >
> >
> > 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.
>
> ##PP
> nothing prevents someone to advertise LDP label for the IP algo-prefix
> and use it with the labeled forwarding. I don't see a problem. But this
> specification does not specify any of it.
>
> >
> >
> > 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
> Done.
>
> thanks,
> Peter
> >
> >
> > Thanks,
> >
> > Ketan
> >
> >
> >
> > On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee)
> > <acee=[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]>
> >     https://www.ietf.org/mailman/listinfo/lsr
> >     <https://www.ietf.org/mailman/listinfo/lsr>
> >
>
>